2006 CMUcam2 Code

[Bob22341]

I have tried working with the camera GUI's (java and labview programs) and neither of them work. The java program freezes when i try to change a setting, and it always fails when i try to do a frame grab. The labview program gives me a crash message on startup. I am totally lost!

If anyone could give me a hand, it would be a big help. Thanks.

[Mark McLeod]

No luck (questionable usage I suppose) duplicating your issues with our RC.

I did power cycles of each of the following variations with preset values through Port 1. Tests were split between using the as-is default frc_camera_s camera.hex and a version modified to include Default_Routine() and a dump of the rx packet. I usually cycled rather quickly, restarting after a 10-count, but tried some varying time spent powered up and resting afterwards.

• on tether (30 cycles)
• on radio (30 cycles)
• w/o backup battery (20 additional tests while on tether)

I have to think as Kevin does that the use of the camera code is just exposing a flaw or a timing issue in your particular RC that the IFI default code does not.

If you're up for a road trip Neil (maybe hard for the Alberta and Idaho folks) and think it could be beneficial you are welcome to try your code and tests on our 2006 RC and we can swap in various cameras as well. Try dropping by a nearby team and repeating your tests.

[nheft]

Here's what we found Thursday night

(1) Same observation on powering up with reset depressed. Doesn't seem to make a difference.

(2) Tracing program flow with printf statements sprinkled throughout Process_Data_From_Master_uP(), we see that it always executes successfully the first time through.

(a) In the no-fault case, Process_Data_From_Master_uP() continues to get called like clock work

(b) In the CODE ERROR case, Process_Data_From_Master_uP() only gets called once. (or possibly it continues to get called but the printf's stop because of a serial port hangup)

(c) In the garbled rxdata case, the first packet comes in OK but from the second packet forward the OI mappings are corrupted. Data fields are always mis-aligned in the same fashion but it's not as simple as a byte shift.

I have incorporated a trap that detects five consecutive packets with 127 in the packet_num field and goes into an infinite loop if this occurs. This forces a code error if the rx packets are corrupted so we know to re-cycle the power. I plan to further refine the logic to only enable the trap during the first few cycles; once we get off to a good start we seem to run OK till the next power-up.

Does your RC ever come up OK with proper OI mappings?

Neil

Originally Posted by drinkdhmo

We have explored the problem a little more fully today and have found a few more details:

Powering up the robot with the reset button depressed, then releasing it, still results in a code fault.

The processor results in a code fault only when the controller has been off for more than 5 seconds after running for more than a few minutes. We did some extensive testing and timing and a power cycle (with the breaker, not the reset button). When the processor has not been on as long, more time powered down is required to reproduce the code fault. We could not reproduce the code fault at all by holding down the reset button for an extended period of time (about a minute).

Along with joystick 1's y-axis being mapped to p1_x, we have also noticed that joystick 3's x-axis is being mapped to p1_y. We have not yet explored all of the oi input mappings, but we will post it when we do.

We also found that when we powered up the rc without a radio modem or tether connected, the program does not fault. When we reconnect the radio modem the program will fault again, but only after the processor has been powered down for a varrying period of time.

Whether the code faults on startup or not, the OI input mappings are still messed up.

This is all we have found so far. I will continue our exploration of the problem tomorrow and post anything new.

[nheft]

I tried holding the reset button while powering up. Still getting random code errors.

I sprinkled some printf's into Process_Data_From_Master_uP - one at the beginning of the module, one to print out the entire rxdata buffer, and one at the end of the module. When the code error occurs I am observing that Process_Data_From_Master_uP executes one time.

When the mis-aligned rx buffer problem occurs, it looks like it's happening from the second message on; the first rxbuffer received after initialization looks OK.

I also tried a simple delay loop before IFI_Initialization to give the oscillator a few tenths of a second to stabilize before trying to do anything. This did not help either.

Another programmer from Team 358 loaded frc_camera_s on his RC and could not find a problem. I tend to believe there is a marginal timing problem somewhere that just doesn't occur with all RC's and does not occur with IFI default code.

For now, my work-around is going to be: (1) if the LED's show a code error, cycle power and (2) if the packets get misaligned, trap on a lack of proper incrementation of packet_num and force a code error via an infinite loop, taking us back to step 1. This trap can be disabled after five consecutive good packets since the RC seems to behave OK once it gets off to a good start.

Originally Posted by Kevin Watson

I think we can go on the assumption that it's not caused by the camera code directly. The only thing that immediately comes to mind is some kind of race condition where the processor comes out of reset before the oscillator is stabilized. If I get a chance, I'll call IFI today and see what can be done about this. As an experiment, you might try holding the processor in a reset state while powering up. Do it enough times to get real statistics.

-Kevin

[drinkdhmo]

ELATION!

The whole time we were trying to get the drive system working, we did not have the camera hooked up. Today I finally tried hooking up the camera while controlling drive. It worked. Silly me, I didn't realize that this code requires the camrea be connected...

Once we hooked up the camera, we reduced our fault frequency to about 1 in 5 powerups as opposed to almost every time. To fix this, we connected a SPST bat-handle toggle switch in series with the power connection to the RC. After doing that, we have not had the processor fault at all.

Hopefully this information can help any of you in fixing your problems.

[nheft]

Thanks for the tests and the offer to let us try our code on your RC.

Looks like I we're going to use the RC the way it is. IFI looked at it and said they can't find anything wrong. So whatever I find from this point looking forward, I'm stuck with it the way it is.

I agree that it's a subtle timing flaw that does not manifest itself with the default code. I don't even think it happens on all RC's. (yours does not seem to have the problem)

I came up with a test that waits for the first 16 packets to come in, verifies that the packet_num increments for the 11th through the 16th consecutive packets. (I noticed that on startup, with the OI getting its power through the tether cable, the packets don't start incrementing regularly until after the tenth packet.) Once this test passes, I never see a failure in the RC. If the test fails, I go into a trap that forces a code error. Now we always get either a good start or a code error, never a bad start that looks like everything is fine.

Originally Posted by Mark McLeod

No luck (questionable usage I suppose) duplicating your issues with our RC.

I have to think as Kevin does that the use of the camera code is just exposing a flaw or a timing issue in your particular RC that the IFI default code does not.

If you're up for a road trip Neil (maybe hard for the Alberta and Idaho folks) and think it could be beneficial you are welcome to try your code and tests on our 2006 RC and we can swap in various cameras as well. Try dropping by a nearby team and repeating your tests.

[charrisTTI]

Programmers from our team have reported similar observations.

I have not yet had a chance to help them investigate.

This is a real shot from the hip, but here goes anyway.

Default code does not turn on interrupt handling for serial communications to/from the camera.

What about an interrupt processing issue?
Does the UART have a funny state on power up (only some of the time)?
Does the power up of the camera enter into the problem?
Camera first then RC. RC first then Camera. Does this change the situation?

How does data get from the master microprocessor to the user microprocessor? DMA, Dual ported ram, serial ????

How can the camera code affect this?

[kc8nod]

Hi There,

We seem to be having the same problem.

Originally Posted by drinkdhmo

Along with joystick 1's y-axis being mapped to p1_x, we have also noticed that joystick 3's x-axis is being mapped to p1_y.

Yup, we have confirmed the same behavior.

Originally Posted by nheft

I came up with a test that waits for the first 16 packets to come in, verifies that the packet_num increments for the 11th through the 16th consecutive packets.

We plan to implement the same workaround.

[nheft]

I agree that your observations on interrupt enables and UART state on power-up are on target.

We saw pretty much the same results with or without the camera connected. The camera gets power from one of the PWM outputs so it has to come up after the RC does.

According to IFI the user uP gets data from the Master via a serial SPI interface. I don't know if there is any error checking in the user uP but I suspect not.

Six weeks was not going to be enough time to run this investigation into the ground and still be able to perform our remaining tasks, so I elected to work around the problem as I described in my last post.

[X-Istence]

My RC has been behaving. However, I don't know what you guys have done to get this error to come up. I however have only used it with the Tether cable plugged in.

If someone could give me a rundown as to how this problem should be occurring, and what I should do to get it to show up, I will gladly help out, from previous posts I was unable to get exactly what I had to do to get this error to possibly show up.

[X-Istence]

Originally Posted by nheft

The first error is the "Code Error", similar to that reported by team 1216. The Code error only occurs at power-up, not after hitting a reset. When we see a Code Error, a robot reset clears the error.

The second error, far more disturbing than the "Code Error" condition, is one in which there is no code error but the data the user uP receives from the master is corrupted - for example Joystick 1 X and Y data fields are reversed. The disturbing thing about this condition is that everything looks normal on the RC LED's so we would not know the problem is happening until the match starts. Also, the RC does not recover from this case by pressing the reset button. Only cycling power (and waiting another 5 seconds if the backup battery is connected) clears the problem.
I disabled Tracking_Info_Terminal(), Camera_Handler() and Servo_Track() in Process_Data_From_Master_uP() and still get the startup errors.

I know my last question was for more info, but I now know what the problem looks like. We have the exact same problems. The first case happens sporadically, as does the second, the second however was easy to find, just turn our belt system on, and then try to turn it back off. The robot would jump all over the place, as would the camera's servo's.

I am going to redo my electrical, and will look through the entire code for possible things that could be going wrong. Ours probably does not have this problem with the default code either. However, what I have noticed, is that turning off the OI and then turning it back on, will ALSO solve the problem for me (unless it says code error).

For now I am going to keep going with what I have, after we ship I am going to see what I can get done, possibly even trade in last years RC for a new one with $150 down (I believe this is what IFI has a deal going for or something, correct me if I am wrong, in which case we may purchase an entirely new one).

[Kevin Watson]

I've posted updated "bells and whistles" camera software here: http://kevin.org/frc. These are the changes:

tracking.c/.h:
Provided two new functions to set the pan and tilt servo position.
This was done to provide a level of indirection so that the servos
could be controlled from the robot controller or the CMUcam2.

Fixed bug in search initialization code where temp_pan_servo was
initialized to zero instead of Tracking_Config_Data.Pan_Min_PWM.

Altered tracking algorithm to use the t-packet confidence value to
determine whether the code should track or search.

Added Get_Tracking_State() function, which can be used to determine
if the camera is pointing at the target.

tracking_menu.c/.h:
Added the ability to set the confidence threshold via the tracking
menu.

terminal.c:
Added "no camera data" diagnostic information.

user_routines.c:
Added code to send tracking state information to the user LEDs on
the operator interface.

-Kevin

[gnirts]

Originally Posted by Kevin Watson

I've posted updated "bells and whistles" camera software here: http://kevin.org/frc. These are the changes:
-Kevin

Can these changes be replicated in the streamlined version as well?

[Kevin Watson]

Originally Posted by gnirts

Can these changes be replicated in the streamlined version as well?

Yes, I'm working on it.

-Kevin

[Fritz]

We are currently experiencing a problem getting the 2005 RC to accept any code that uses the current default camera code. It won't accept, at all, and the hex is no larger than any of our other working code... infact, the hex is smaller! If anyone can help, it'd be muuuuch appreciated.

ps. we have set it up with the old linker and even the new ones to see if it will work...