View Single Post
  #5   Spotlight this post!  
Unread 24-01-2009, 21:21
writchie writchie is offline
Engineering Mentor
AKA: Wally Ritchie
FRC #2152 (Team Daytona)
Team Role: Coach
 
Join Date: Dec 2007
Rookie Year: 2007
Location: Daytona Beach, Florida
Posts: 148
writchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond reputewritchie has a reputation beyond repute
Re: Using FRC dashboard w/ camera during competition?

By passing the mjpeg images to the DS you can probably get around 15 - 24 fps at 160x120 resolution. This is based on jpeg images of about 1.8KB after stripping out unnecessary header data. We are seeing 50 packets per second and you have 984 user bytes per packet for a net datarate of almost 400 kilobits per second.

There is a packet delay from camera to cRIO, processing in cRIO, packet delay cRIO to DS, processing in DS, packet delay to your Dashboard program and processing in your Dashboard program. I'm not sure that I would pronounce this as useless because it could be 100ms or less (1/10th second delay).

The dilemma ( at least for us) is that we like 640x480 for tracking/targeting as long as we can keep the processor load under 50%. So there is a tradeoff. If 160x120 is satisfactory for your tracking/targeting (and using the standard software this may be the realistic limit anyway) then it may be feasible to have 160x120 live video stream, which at a 24 fps frame is not all that useless.

In any case, this kind programming under FRC constraints is not for the feint of heart, although this year's rules give us a bit more time for programming.