Go to Post I'll admit that the events at Epcot were pretty nice, but they too had their problems. . . You were at the mercy of the weather, and Disney hasn't figured out how to control that yet. - Kevin Sevcik [more]
Home
Go Back   Chief Delphi > Technical > Programming > Java
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #3   Spotlight this post!  
Unread 02-10-2013, 01:51 PM
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
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 07:41 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi