[Mark McLeod]

Sorry, I've been sick and out of it for awhile.

Here's the re-initialization we're using that Matt referred to. Nothing fancy, it's only a simple check for dropped communications packets, followed by a reset and reinitialization of both the camera and Kevin Watson's camera.c state machine. We don't use the tracking code, so you might need more for that. A normal initialization takes 1.2 seconds, however, since we don't know how long power can be interrupted and because some states are funkier than others, we continue to periodically attempt to initialize the camera as long as it's not responding anyway.

Re-initializing doesn't help the roughly 1:30 chance the camera won't power up in any kind of state to communicate. For both that and the regular case we use rapidly blinking LEDs to indicate the camera has not (yet) initialized, because the camera LEDs can be in any state and aren't a good indicator of a hangup. The blinking LEDs are easier for the drive team to identify a camera initialization problem.

We tested this by repeatedly pulling the power connection for the camera, cycling the RC power, and mounting the camera on a jigsaw as a vibration source.

This file doesn't include checks we added for invalid and incomplete T packets we see periodically that can also affect results.

I forgot this was an rtf. Here's the true txt version.