View Single Post
  #3   Spotlight this post!  
Unread 10-02-2013, 13:51
alberth alberth is offline
Programmer and Engineer
FRC #4067 (The Incredible Hawk)
Team Role: Programmer
 
Join Date: Jan 2012
Rookie Year: 2011
Location: Maryland
Posts: 9
alberth is an unknown quantity at this point
Re: Review Tracking Code

Quote:
Originally Posted by virtuald View Post
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.
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

Quote:
Originally Posted by virtuald View Post
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.
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! )

Nevertheless, it is still a handicap, and I would appreciate any suggestions on how to fix this!
__________________
Team #4067 - The Incredible Hawk
Role: Lead Programmer
Team Website

2012 Rookie Inspiration Award (Chesapeake Regional)

"You can't warm up by standing still in the frigid cold. Get moving!"
Reply With Quote