|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools |
Rating:
|
Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: pic: Team 341 presents Miss Daisy XI
How did you solve the potential networking issues and latency? Do you have some interpolation for delayed frames? Do you have timestamps on the frames to know how long they took to trasmit... when you computed your position, and transmit this back to the robot does it take into account the latency on this end. How did you work around or simulate the FMS locked stress, and did you test against a typical network traffic of a match.
All of these questions scared me away from this kind of solution. I hope you have some good answers for them. ![]() I guess you can always set still for a few seconds and that should solve that. |
|
#2
|
|||||
|
|||||
|
Re: pic: Team 341 presents Miss Daisy XI
The short answer is that if we discover network latency/dropout to be a significant problem, we will move our image processing application to an onboard laptop. Failing that, our next fallback is to reduce resolution and/or framerate. To be frank, we auto target just fine at 5 fps (because the gyro loop is closed at 200Hz); we do 30 because we can
![]() However, I do not expect this to be a major concern. In past seasons, teams have streamed live camera data directly to their dashboards with few problems. The only difference is now we are cutting out the cRIO altogether. While we haven't run simulations against an "FRC network simulator" (but if you know of a tool that could be used for this purpose I would be interested in trying it), in theory there is PLENTY of bandwidth to go around. With reasonable compression settings these images are only on the order of 10-20 kilobytes a piece. We don't timestamp the images, but we do transmit our heading synchronously with new camera images being available. That way, the results returned by the vision application do not go "out of date" if they are received late. Out of order packets would be a bigger problem (it's UDP under the hood). But absolute worst case - like you said - this would be a transient problem and would straighten itself out within a second or two. EDIT: Forgot to add, we also do low pass filtering of both outputs from the vision system to help smoothness (and to reject momentary disturbances like when we occlude the vision target with a flying basketball ). This should help with occasional frame drops as well.Last edited by Jared Russell : 22-02-2012 at 12:56. |
|
#3
|
|||||
|
|||||
|
Re: pic: Team 341 presents Miss Daisy XI
Clean looking machine!
It's nice to see another robot with a wide pickup! :-) See you at Chestnut Hill! |
|
#4
|
||||
|
||||
|
Re: pic: Team 341 presents Miss Daisy XI
Nice job there Jared and Al!
|
|
#5
|
||||
|
||||
|
Re: pic: Team 341 presents Miss Daisy XI
Awesome. Can't wait to play with 341 at Hatboro-Horsham. I'd volunteer to use your opposite-loader, but I'm thinking we want to shoot our balls in auto.
![]() |
|
#6
|
||||
|
||||
|
Re: pic: Team 341 presents Miss Daisy XI
What part number did you use for the optical photosensor / tachometer ?
Ed |
|
#7
|
|||||
|
|||||
|
Re: pic: Team 341 presents Miss Daisy XI
It is the Allen Bradley 42EF-D1MNAK-A2 from last years' Kit of Parts.
|
|
#8
|
||||
|
||||
|
Re: pic: Team 341 presents Miss Daisy XI
Wonderful bot.
A couple of questions: 1> when your manipulator flips out it looks like it breaks the front plane of the bot in more than 1 location. Are you concerned that it might be ruled 2 appendeges? 2> when your manipulator is deployed it appears to obscure your numbers. Is that just the angle of the picture? Otherwise, the bot looks gorgeous. |
|
#9
|
||||||
|
||||||
|
Re: pic: Team 341 presents Miss Daisy XI
Quote:
Quote:
Last edited by Joe Ross : 23-02-2012 at 14:44. |
|
#10
|
|||||
|
|||||
|
Re: pic: Team 341 presents Miss Daisy XI
Quote:
As for numbers: from a full frontal view, you can actually read them just fine when your intake is deployed. The intake is mostly air ![]() |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|