View Single Post
  #24   Spotlight this post!  
Unread 21-01-2009, 17:43
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,082
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: 2009 - Live camera feed to drivers during a match?

This can lead to an interesting thought experiment.

* To be most useful, the images sent to the driver should be sent at reasonable video speeds (say 10 Hz or so)

* This means we need to be able to compress a single frame down to 5*984 bytes = 4920 bytes

* At 640x480x24 bits per pixel (standard RGB color), a single uncompressed image is 921,600 bytes.

* At 160x120 at 1 bit per pixel (binary black and white), a single uncompressed image still needs 2400 bytes. Hmm... We could even have 2 bits per pixel (4 shades of gray) and still fit under the limit.

Think about this one possible implementation: We have 5 different types of 984-byte packets. Each packet needs a header telling the dashboard PC which type it is, along with a frame number (to correlate out-of-order packets and drop old ones). It would also be helpful to have target positions (for, say, up to 3 targets we are tracking). Then comes the payload of raw image data (I want to avoid compression for now).

Implementation:

Packet 1:
1 byte for correlation (high 4 bits are the packet id (1); low 4 bits are the frame number that rolls over ever second and a half or so)

3 bytes for target #1:
+1 byte indicating which type of target, and whether or not it is visible
+1 byte indicating Y position in the frame
+1 byte indicating X position in the frame

3 bytes for target #2:
+1 byte indicating which type of target, and whether or not it is visible
+1 byte indicating Y position in the frame
+1 byte indicating X position in the frame

3 bytes for target #3:
+1 byte indicating which type of target, and whether or not it is visible
+1 byte indicating Y position in the frame
+1 byte indicating X position in the frame

974 bytes left over for payload data (first 1948 pixels of the image)...

Packets 2-5 would only need the 1 byte ID/frame #, and would have plenty of room left for the rest of the raw image data.

There are various methods for generating your 2-bit thresholded image; many are fairly inexpensive in terms of processing time.

---

I'm not sure about the utility of it, but I think that this shows that you might be able to get away with some "video" this year.