Combined Camera and PID/Encoder Code

I’ve been trying to get quadrature encoder code and the provided camera code working together. What I am experiecing is that the PID code that is called on every 26.2ms loop is not always occuring. It seems that this is happening because the camera code sits and waits alot for the serial port. In particular there is a function called: wait_for_data(). This function will sit and spin for quite some time and probably alone causes us to miss out 26.2ms deadline.

If that alone isn’t enough this function is called eveytime a camera command is done (camera_track_update(), camera_getACK() [which is called by camera_const_cmd(), camera_buffer_cmd(), camera_stop(), & camera_reset()]).

I think the equivalent to a event driven system needs to be thought out to be able to let the camera code send out serial data and wait for responses but not hold up the rest of the system while it is waiting. If the camera code is needed to be run then it doesn’t seem that the normal 26.2ms timing is maintained and all code that depends on that timing (PID, command script timing, etc) is unreliable at best.

Has anyone else encountered this, and if so have you come up with a good way to handle it? I’d like to talk over some ideas with some of you if possible.


I wish I’d seen your post earlier, I’m just now figuring this out. I think we’re getting interference from our motors on our camera lines making us miss ACKs and then the code runs too long resulting in a code error.

My first suggestion is to make sure you’re not calling too many commands that require ACKs during one 26.2ms cycle. This may require breaking up the camera initialization code into several states, each occuring in a separate 26.2ms cycle.

My second suggestion is to only allow one failed ACK per 26.2ms cycle. After seeing one failed ACK you would force all other calls to the wait_for_data() function to immediately return a 0 until the end of the 26.2ms cycle when you would reset the flag. This method basically assumes that if you miss one ACK during a cycle, that any other camera command will likely fail too, you just want to complete the 26.2ms cycle safely so you can retry that state during the next iteration.

I hope that helps. We won’t get a chance to test the code until nationals, so if you get a chance to test it and have any success please let me know.