Ah, nice! I’ll probably end up using it then, if it works for you.
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.
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:
https://i.imgur.com/h0ofKI3.png
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);
}
