I am attempting to enable multiple light tracking by inserting code into Kevin’s. How should I do this? I have read the code over multiple times and I am aware at how it all works, but I am unsure where I should set the poll mode to 1 and also what I should do when I send the VirtualWindow commands. Do I wait for an ACK and new T-Data for each? (And after receiving, set the new VW, so on and so forth?)
It sounds like what you are planning will work. However, I’m not going to put the effort in. After looking at the field, I can’t see many situations where you’d actually see two lights. And in my case, if I did, I’d make sure that the camera was in position on one of the lights for a moment, save that position (with some of my magic code…I’ll probably explain later but not yet) and then move the camera on–continue the search pattern–and find the other light and save its position.
I don’t see that many chances to see two lights at once, though.
I was also wondering the usefulness of implementing multiple light tracking…but I thought I’d try it out since most other things are finished.
I am having a problem which is very strange… I am just going to go ahead and post the C here. This is the function to set the camera to poll mode. Just to test it, I’m actually setting it in STATE_TWO of the camera initialization since nothing is happening there. Is this okay? Furthermore, I am not receiving an ACK or NCK, leading me to believe the way I am setting PM to 1 is incorrrect.
From what I understand, no, not if the camera is in poll mode. You send at least 4 characters: two for the command, one for the number of arguments, and one for each argument. That’s why there are 2 "1"s being sent. One of them is an argument count, and the other is the actual argument. In poll mode no carriage returns are sent.
Nope–Kevin’s code by default sets the camera to “Raw mode”–see the command RM in the CMUcam manual. His code sends a “RM 5” command; 5 = 101; that means input and output are in raw bytes instead of the normal “XX 1 2 3\r” style. As you can see, “XX 1 2 3\r” is 9 bytes, “XX3123” is only 6. Raw mode is there to trim the fat out of the communications. Just a quote from the manual:
If bit 2 is set, input will be read as raw byte values, too. In this mode, after the two command byte values are sent, send 1 byte telling how many arguments are to follow. (i.e. DF followed by the raw byte value 0 for no arguments) No \r character is required.
It’s not explained very well, but basically, you send the two-byte command, a byte with the number of arguments, and each argument after that is sent as a single byte.
EDIT: John, it has nothing to do with when the camera is in poll mode, rather, if it is in raw mode, it will act as I described above. If it is in poll mode, TC (track color) sends 1 T packet, if not, it sends them repeatedly until interrupted by a \r.