Challenge problem: 'ladder of abstraction' iterative design in FRC

[Cel Skeggs]

Originally Posted by virtuald

That is exactly how PyFRC allows you to pause/step time, except that in python it's a bit easier to replace it out from underneath the program.

Ah, nice! I'll probably end up using it then, if it works for you.

Originally Posted by SoftwareBug2.0

I think not allowing calls to the built-in timing systems is reasonable and a custom "timing system" is not required to replace it. A single way to get the current time is sufficient. Other abstractions can be built on top of that.

I disagree that it's reasonable, at least for my purposes. I'm trying to have as few "gotchas" as possible, and if I avoid requiring usage of special timing mechanism, I avoid another location where users could be confused.

Well, at the very minimum two ways to interact with time are required: getting and sleeping (you cannot reasonably implement either in terms of the other), at which point a custom timing system might be the best bet. I'm probably going to use Java's java.lang.instrumentation.Instrumentation interface and define a custom Agent to allow me to rewrite calls to the core timing methods. (Probably using the ASM4 library, which I've worked with before.) Alternatively, I can define a custom ClassLoader that provides similar transformations and reload the emulator and all of its dependencies with that, although I'm not sure that it would work properly if I need to modify built-in classes.

It's a more complicated implementation, but a less complicated interface.

Originally Posted by SoftwareBug2.0

I know you've said that you've had your last release of CCRE to break compatibility but how many external users do you have?

Nine robots that I know of have used the CCRE, including seven on Team 1540 (four bunnybots, our 2014 prototype, 2014 competition, and 2013 competition although that was a post-season addition) and two from our school but not strictly within team 1540 (ScumBot & ScumBot control system test platform.) This means that we don't know of any external users. This makes sense, though, since it wouldn't be likely that anyone outside of our school would want to use a first-year tool, as it was for the last season.

The biggest reason that we know of that would make others not want to use the CCRE would be worrying about its stability. If it's unstable and it breaks during a competition, they'd need someone who understands it to fix it on the spot. By keeping it maximally stable, we do our best to minimize this concern. (Also, let's avoid clogging this thread up with anything unrelated to the topic at hand, so if you want to discuss this part about the CCRE more, let's move to the CCRE's thread or private messages.)

More on topic, I started implementing a basic prototype version of this:

Currently it's a system that graphs the actuator outputs of autonomous mode (or any other period of time). It doesn't yet fast-forward the execution, but it does run the exact same unrestricted code that we've previously been able to write. It's for the following autonomous mode:

protected void autonomousMain() throws AutonomousModeOverException, InterruptedException {
	moveForTime(-1, 5000);

	waitForTime(300);
	shifter.set(true);
	waitForTime(300);

	moveForTime(1, 1000);

	waitForTime(300);
	shifter.set(false);
}

private void moveForTime(float speed, int time) throws AutonomousModeOverException, InterruptedException {
	leftOut.set(speed);
	rightOut.set(speed);
	waitForTime(time);
	leftOut.set(0);
	rightOut.set(0);
}