Review Tracking Code

Technical Java
1

We’re pretty new to Java target tracking - we’ve started to play around with it this year! Most of our code uses the FRC 2013 Vision sample code, but we figured that it would be fine to use and build upon the example. (Unfortunately, we have not tried using it yet, since the mechanical guys are still working on building the robot!)

We have two Netbeans projects - RobotSeeRobotDo (clever, eh?) and RobotSeeRobotDoLite. RobotSeeRobotDo handles all the corner cases, while RobotSeeRobotDoLite ignores corner cases and greatly simplifies the code. I would be grateful if anyone can review the source and provide feedback! :slight_smile:

http://code.google.com/p/frcbot4067/source/browse/RobotSeeRobotDo/src/org/riverhillrobotics/frc2013/RobotSeeRobotDo

http://code.google.com/p/frcbot4067/source/browse/RobotSeeRobotDoLite/src/org/riverhillrobotics/frc2013/RobotSeeRobotDoLite

Thanks in advance!

EDIT: RobotSeeRobotDo and RobotSeeRobotDoLite have been updated to fix a logic problem.

2

I didn’t do an in-depth review, but I’d recommend breaking your functions up a little more so they aren’t super-long. It also makes verifying the logic a lot easier. :slight_smile:

Also, I noted some Timer.delay() bits in there… keep in mind that if you delay, then nothing else can happen on your robot during that time (including feeding the watchdog, and driving), so you’ll end up with the robot freezing when doing certain things.

3

Thanks for taking a quick peek! I took your advice… and perhaps took it too much! I now have most of the code separated into a separate class, each with their own method. It’s making more logical sense in my head, and it’s much more readable! (To me, at least - don’t know if it’s readable to others…)

Again, I would appreciate it if you (or any other people) could review the vision code!

http://code.google.com/p/frcbot4067/...obotSeeRobotDo

http://code.google.com/p/frcbot4067/...SeeRobotDoLite

I know. The problem is that if I let the motors run without a delay to stop it (that is, keep it running in a loop, and only stop when the target is reached), there’s no way to guarantee a consistent rotation amount. If a particular image takes more time than another image, then the turret will rotate more than the previous rotation. The delays keep it consistent, barring variable friction.

One fix is to keep the delays, but have the shooter and alignment code run in a thread. I’m not sure if FRC Java supports it, nor whether this is safe or not. Plus it’s a tad bit more complex.

Another fix would be to use System.nanoTime(). I would take that function’s output and use it as a start time, then continuously take measurements until the difference meets a certain time. The issue with that is that I would have to check the difference everywhere, which leads to messy code.

At the moment, I don’t see this becoming too much of a problem. In autonomous, it would be advantageous to let the shooting code complete in case you are just about to shoot, the horn sounds, and you make that final autonomous shot. (Don’t know if that will score you any autonomous bonus points, but points are still points!) In teleop, we probably won’t be moving while shooting, so a controls lockup would be fine. (We’re not planning to do the “shooting while driving” trick like some teams have done! :yikes:)

Nevertheless, it is still a handicap, and I would appreciate any suggestions on how to fix this! :slight_smile:

4