Virtual Window Function

[abrockhoff]

We've been working on splitting the view of the camera with the Virtual_Window() function that Kevin supplied. We haven't had much success, but I now have a few questions.

1. What we attempted to do was put the camera in Raw Mode by calling Raw_Mode(5); and then waiting for an ACK, but we never recieved a response from the camera. Does anyone have any idea why?

2. We checked for ACKs and NCKs by placing flags in the Camera_State_Machine. We saw that the flags were set during initialization, and we call Camera_Handler() in user_routines, why would it not step through the state machine and set the flag after initialization?

3. When calling the Virtual Window funtion, why does Kevin write VW and then 4 before sending out the coordinates? In the CMUcam documentation it simply tells you to write out the coordinates.

4. After writing out the Virtual_Window() function we also did not recieve an ACK or NCK, similar to the Raw_Mode problem stated above.

[jt250]

Originally Posted by abrockhoff

We've been working on splitting the view of the camera with the Virtual_Window() function that Kevin supplied. We haven't had much success, but I now have a few questions.

1. What we attempted to do was put the camera in Raw Mode by calling Raw_Mode(5); and then waiting for an ACK, but we never recieved a response from the camera. Does anyone have any idea why?

2. We checked for ACKs and NCKs by placing flags in the Camera_State_Machine. We saw that the flags were set during initialization, and we call Camera_Handler() in user_routines, why would it not step through the state machine and set the flag after initialization?

3. When calling the Virtual Window funtion, why does Kevin write VW and then 4 before sending out the coordinates? In the CMUcam documentation it simply tells you to write out the coordinates.

4. After writing out the Virtual_Window() function we also did not recieve an ACK or NCK, similar to the Raw_Mode problem stated above.

At least in v2.1 of the Stream Lined code, Raw_Mode(5) is run in the initialization routine anyways - you shouldn't have to run it yourself. Also, to answer #3, with the raw binary mode, instead of entering commands and arguments separated by spaces and ending with a \r, you simple send the command, then a number which specifies the number of parameters, and then the values for the parameters. In the case of Virtual Window, he sends 4 because it has 4 parameters. You'll notice the Raw_Mode command is the only one which sends any spaces or a \r.

A possible explanation for your lack of ACK's after Virtual_Window() is that it simply never gets there; you need to put the camera in Polled Mode (command "PM 1", see the sticky at the top of the forum) otherwise all outgoing commands seem to be flooded out by the stream of incoming T Packets. (I can't say for sure this is what happens, but it seems plausible based on what happened to us.)

Edit: by the way, I see you're one of the teams that sent us a request for our implementation. I sent it out to all teams today, however the email provided by your team was a gmail account, and Gmail bounced the attachment because it contained python scripts which had been compiled by py2exe. I'm working on finding an alternate means of sending the code to your team, but if you have another email address that would simplify things greatly.

[abrockhoff]

alright man, thanks for the response, i'll try that tomorrow.

just wondering though, after sending out your PM, VW, and TC commands to you wait for an ACK from the camera, or just delay a few loops.

if you do wait for an ack, do you check for them using camera handler and the state machine? i just rewrote my code, and after every command (PM, VW, TC) i wait to move on to the next case until a flag is set in the camera_state_machine under the "receiving ack" part.

thanks again