View Single Post
  #16   Spotlight this post!  
Unread 12-01-2012, 08:07
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,756
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: How to run vison processing code on classmate during matches?

Not knowing much about this situation, I can't say for sure what their framerate was on and off the field, but if they used the default dashboard and the M1011, then the framerate would have been single digits to start with.

The default dashboard, along with the cRIO camera communications moved from SW timed requests of individual JPEGs to HW camera timed MJPG stream this year once it was discovered that the M1011 had poor performance with the JPEG route. Both options are still in the LV palette, but the default is now MJPG. The initial decision was somewhat arbitrary, and C and therefore Java, were already using MJPGs. Depending on the setup, other factors could have played a part. It is easy to chalk it up to the "field", but I have never witnessed this and it doesn't feel like the actual culprit.

As mentioned, it is somewhat difficult to simulate a match in your shop, but on the network you have, you can look at utilization and latency. You can look at how/if it changes when a second robot is added. You can also do some back-of-envelope calculations to see how much of the N speed network you are using.

My final advice is to look at the elements being measured and use those requirements to determine the rates and resolutions needed, as well as the appropriate sensor to use.

Due to slow speeds (30 Hz) max, somewhat high latency (>60ms, often 150ms), and variable jitter, cameras are not necessarily a good sensor to close a loop with. It is far better to calculate where the target is and use an encoder or pot to turn the turret. If the robot is to be turned, use a gyro. More CPU does little to improve the numbers. Higher speed cameras exist, but they are not in the kit, their cost is pretty high, and it may be difficult to integrate them.

I think the camera is a very valuable sensor, but it all depends on how it is used.

To the original topic, the laptop allows you to bring more CPU to the table, to process images more thoroughly, at a higher resolution, and perhaps at a faster rate. Once you have an algorithm that demands more CPU, this seems like a good step. Until then, ...

Greg McKaskle