Enabling Multiple Light Tracking Using Kevin's Code

[Mitch]

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?)

Thank you

[Mitch]

After thinking about this more... this is my plan, feedback would be appreciated. It is not implemented yet, I am currently in the process.

1. "extern" the camera_acks and ncks variables in camera.c so that they are global (so I can put all the multi-light tracking in another file). Also globalize the camera_initialized variable.

2. I create a function which is run every loop from main. This function will first check if the camera is initialized and if so, set the camera to poll mode (once).

3. Wait for a T-Packet

4. If the bounds received are too large, designating itself as a "blob" we now do what team 250 has said (split the window in two and retrack each side to receive two bounds)

5. Rinse and repeat.

[JBotAlan]

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.

JBot

[Mitch]

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.

void Set_Poll_Mode(void)
{
	Write_Camera_Serial_Port('P');
	Write_Camera_Serial_Port('M');
	Write_Camera_Serial_Port(' ');
	Write_Camera_Serial_Port('1');
	Write_Camera_Serial_Port('\r');
}

[DanDon]

void Set_Poll_Mode(void)
{
Write_Camera_Serial_Port('P');
Write_Camera_Serial_Port('M');
Write_Camera_Serial_Port(1);
Write_Camera_Serial_Port(1);
}

That should set the camera into poll mode if the camera was set into raw mode before this function call.

[Mitch]

Originally Posted by dhoizner

That should set the camera into poll mode if the camera was set into raw mode before this function call.

Thank you, I'll try this. I thought every command needed to be ended with a carriage return? No?

[JohnC]

Originally Posted by Mitch

Thank you, I'll try this. I thought every command needed to be ended with a carriage return? No?

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.

[JBotAlan]

Originally Posted by Mitch

Thank you, I'll try this. I thought every command needed to be ended with a carriage return? No?

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.

Good luck,
JBot

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.