CMU Camera kills robot controller if not found.

Technical Programming
1

We found an interesting problem today, that we can’t find a way to get around it. We would like to “code” around it but not sure how.

We have our camera tracking ok, and everything works great.

However, if we lose the backup battery and we powered down the robot. Our code goes through the camera initialization again, waiting about 3 seconds before it comes online (normal)…however it locks up the robot controller from executing code because the camera could not be found on power up. We studied this today when we put a simple PrintF statement in a while 1 loop in OperatorControl function that says: “Hi, I am in the OperatorControl Loop”. This was only printed to the screen once, and none of our code would execute any more. We did not get a code error LED, and we seemed to have all green lights on the robot controller.

If we had a good battery, and the camera was found on power up or during the initialization, then it would startup ok and track data. We could then unplug the TTL port “live”, folks don’t try this at home…but we had to do this to see what would happen…and we also unplugged the backup battery to kill the camera totally. Our code kept executing just fine after killing the RS-232 and power source to the camera live without powering down.

We are thinking about the what ifs. What if our camera becomes damaged by a poof ball and doesn’t work, the next time it powers up with a "Initialize Camera " function call, it’s going to LOCK UP, and we are going to be a sitting DUCK.

We could not see ANY WAY to code around this. Can we check for the camera somehow and not execute the Initialize if we don’t find the camera present so our robot will continue to initialize and execute the rest of our code?

Can anyone else replicate this?

Get your camera tracking working FIRST…good battery, put a printF statement in the main loop so you can see that your controller is executing on every loop.

Next, power down your robot. Unplug your camera TTL and backup battery, leave your code alone.

Now power up your robot and observe if your printF statement is still working. What we see is after the 3 seconds, the printF will print one time, and that’s all she wrote…no more looping…seems locked up.

2

Huh. Yesterday, we started with the camera, got it working well, and soon after, got our base driving. We put the electronics on the base, and didnot put the camera on, just incase it self-destructed or something. So, about 10 minutes after the power down and camera removal, it drove fine. No problems at all. So, in conclusion, we had none of the problems you described. However, we also had un-commented the default_routine function (yes, I know i’ve got to fix this before we try the camera again), and we left the backup battery in. I wonder what could be wrong? Maybe its actually the backup battery?

3

Run the camera off a analog port for power. The camera will be powered from
the 12v battery instead of the backup.

4

How will this help us if the camera is missing, broken? Then on power up, it locks up the code, because the robot controller can’t find it?

Maybe I didn’t explain the problem good enough above. The camera works great when it’s connected and the robot controller finds the camera on power up.

But if the camera code is still in the controller and you disconnect the camera from the controller, it acts like it searchs for the camera, never finds it, excutes one cycle enough to do one printF statement, then locks up.

If the robot controller finds the camera on power up, then the camera dies while the controller is powered up, it’s not a problem. The robot controller doesn’t care, it just doesn’t get any packet information.

5

One of the things that we would most certainly be doing is using a switch on the robot, and a switch on the OI, to control whether or not the any of the camera code is used. Using a switch on the OI would be a little trickier than one on the robot, in that you have to make sure that you get a packet through to read the switch before attempting any code related to the camera. This strategy is not quite automatic, but it can be used to get the job done and it is a good idea, in general, to place PID systems and such under conditional control in this manner.

I have not looked at the details of the camera initialization code yet, but it should be possible to run a simple handshake with the camera and detect that the handshake is taking too long. You can then set a variable indicating that the camera is off line.

Eugene

6

It is true that if you call the camera code to capture a packet, it waits for valid data to show up. If the camera is not running, then it waits forever. This is to handle case where you initialize the camera and immediately start reading data and the first packet hasn’t come in yet.

If we were to add a time out (maybe 500ms) so that it would return all zeros if valid camera data was never received (including 0 confidence) would that work for you?

7

The problem that we are experiencing is initializing the camera, when the camera is not found. In fact is does “wait forever” it seems to us.

We understand that if data is never received that we could write a time out code, in fact that is what we want to do. But how do we write a timeout in EasyC when the initialize of the camera is a function block that we can’t edit or interface to? It seems to go into that function and never come back out, (the CPU pointer, aka scan)

If the cpu went into the initialize function and never comes out, how are we suppose to write a timeout function for it?

8

So no one has any other suggestions on this issue?

9

As it stands now, everything should work properly as long as the camera remains powered and connected. We are working on a better method for situations where the camera loses power during a match, so that the code will not wait forever for a response from the camera.

10

Ok no problems. I was asking because I didn’t know if we are doing something wrong, or if we could write something to handle it. But sounds like we can’t at this point.

What we are going to try is program a button on the OI, if the button is pressed (and held) during a power up in the Initiazation, we aren’t going to excute any of the camera stuff.

If we get in a match and our camera dies, we have a robot reset on the OI, we will hold down our programmed “bypass” button, press robot reset, reboot the robot, and hope it forgets about the camera and comes back to life to finish the match…

That’s our work around for now, do you think that would work?

11

That is a really good idea!

I will let you know if I hear of any other solutions. As long as the code you execute when you hold the ‘bypass’ button doesn’t contain any camera calls, your work around should work perfectly.

12

how about running a counter in the initialization loop, and if the counter hits such and such a number, then break out of the loop and forget the camera. takes a little bit of knowledge of loops and the like. shouldn’t be hard. only an idea. =P good luck with it all.

13

what analog port?

14

It doesn’t matter just pick one. They are all 5v.

15

Sorry I couldn’t get to this sooner, but there is a new version of WPILib that you can try that has one second timeouts on receiving camera data. If no camera data has been received before the timeout, then zeros are returned for all values. So if your code starts seeing zeros coming back for everything, including confidence, servo values, etc. then you know that the camera is not working.

This only happens for the first time. After that, the camera will always return the last value it received.

This should be fixed in an upcoming release of EasyC, but to try it for now, you can download the library from my web site, unpack the .zip file and replace the copy of WPILIb.lib inside of the EasyC directory C:\Program Files\Intelitek\easyC for FRC\Frc\18F8722 with the copy of WPILib2k6.lib from the .zip file.

It has been tested, but bugs do happen, and I’d suggest keeping a copy of the old file that you are replacing.

Please post a message or send mail if you run into any problems.

16

Will this version of the WPILIB.lib work for the 18F8520 as well?

17

Yes, there are two directories - one for the 2k5 controllers and one for the 2k6.

18

Thanks Brad!

Just to be Clear: copy the same version of the new WPILib to both :
C:\Program Files\Intelitek\easyC for FRC\Frc\18F8722

AND

C:\Program Files\Intelitek\easyC for FRC\Frc\18F8520

so the update for the camera can be used on the 2006 & 2005/4 RC units.

19

Hmmm…I’ll tell you what I did:

Unpack the .zip file and replace the copy of WPILIb.lib inside of the EasyC directory C:\Program Files\Intelitek\easyC for FRC\Frc\18F8722 with the copy of WPILib2k6.lib from the .zip file. (You’ll need to rename WPILib2k6.lib to WPILIb.lib and over write the OLD “WPILIb.lib” file. Backup the old one FIRST. You need to do this for both 2005 controller and 2006 sub directories.

18F8722 = 2006 controller
18F8520 = 2005 controller

These two files need updated:
C:\Program Files\Intelitek\easyC for FRC\Frc\18F8722\WPILIb.lib
with
WPILib2k6.lib (rename this to WPILIb.lib, copy over the top of the old after backing it up)

and

C:\Program Files\Intelitek\easyC for FRC\Frc\18F8520\WPILIb.lib
with
WPILib2k5.lib (rename this to WPILIb.lib, copy over the top of the old after backing it up)

That should take care of you.

20

Be careful… there are two version of WPILib. One is for the 2k6 robot controller and the other is for 2k4-5. If you copy the same version to both directories, one will not work.