Thread: Camera Tracking
View Single Post
  #6   Spotlight this post!  
Unread 30-09-2013, 19:51
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,751
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Camera Tracking

If the motors are exclusively controlled by camera, unlikely and potentially unwise, then you could put the code in the vision loop. But more likely, you'll have a manual mode and/or only use the vision for specific tasks. This makes it much more common for the camera loop to update globals indicating the quality and state of its image processing. Then a parallel loop -- can be teleop, but more often periodic tasks -- will read the globals and update the motors.

Globals are actually quite easy to use correctly, but also quite easy to use incorrectly. The key is to limit the number of writers to the global. Ideally, only one piece of code would ever write to the global. It is quite common to have an initialization phase that breaks the rule but happens only at startup.

If you want to trigger something, you can also use events, notifiers, or even queues, but globals are quite capable for FRC robots.

Greg McKaskle
Reply With Quote