Radio cuts out, student's foot run over

[grantf]

We had a somewhat scary incident with our robot yesterday.

Here's what we did:

1. Downloaded v14 firmware to the RC.
2. Drove the robot around for a while and experienced a few intermittent radio cutouts.
3. Disabled the robot at the OI via a "kill-switch"
4. Noticed that the Speed Controller LEDs were still solid orange (i.e. enabled)
5. Powered off the robot and changed the battery (we were about to do this anyway).
6. Powered on the robot and again noticed that the Speed Controller LEDs were solid orange.
7. After about 4 seconds (with 3 people standing around the robot) it took off at about full-speed without user input
8. The robot ran over one of my student's foot before I could get ahold of it and lift it off of it's wheels.

For the record:

• The RC radio was mounted high on the robot and perdendicular to the ground
• The OI radio was mounted high on a wall about 15 feet away from the robot, also perpendicular to the floor.
• The kill-switch on the OI was in the disabled position from step 3 above and was NEVER moved back to enabled.
• The "disable" LED on the OI was solid orange and the RC mode LED was yellow/orange.
• The kill-switch has worked for many weeks now, disabling/enabling without issue.

Has anyone else seen anything like this?
BTW, the student is fine.

[Robo_Coyote]

On your competition port however you wired it. There should be two switches for testing autonomous and disabled, at least that is the way we have it. Now if you flipped the autonomous that is probably why it did that. I know that when we first wired our we got confused as to which was autonomous and which was disable and had our robot take off once and almost take my had off in the process while I was working on the drive train.

[Alan Anderson]

Originally Posted by grantf

• The kill-switch has worked for many weeks now, disabling/enabling without issue.

Has anyone else seen anything like this?

Yes.

Our fancy dongle developed a loose connection last fall. If it had failed in a slightly different way, it could easily have thrown the robot into autonomous instead of disabling it. We of course repaired it.

[GBIT]

Originally Posted by Alan Anderson

Yes.

Our fancy dongle developed a loose connection last fall. If it had failed in a slightly different way, it could easily have thrown the robot into autonomous instead of disabling it. We of course repaired it.

we had the same problem more from bad wiring than anything else but ive seen it happen and i have been run over myself! but to be serious check the wiring on your dongle and make sure it is all good.also make sure the port is pluged in properly(also something weve done)

[grantf]

Suppose for a second that the wiring on the dongle is faulty and that the robot ran an autonomous program.
Here is our autonomous code that is called from the Autonomous() function in the competition template of EasyC - Pro:

void
tc_autonomousControl( void )
{
    // Call the appropriate installed autonomous program
}

Also, in the Initialization() method in the same competition template, we set all PWM outputs to 127. The Initialization() code gets run before both the Autonomous() and OperatorControl() functions have a chance to run.

I will check the wiring again... but I fail to see how the robot would take off in either of these cases.

Also, the student that had been driving the robot was asked multiple times what the state of the kill-switch was... He told me "disabled" every time I asked... I asked 3 times because I saw the LEDs on the speed controller were solid orange, enabled.

[Mike Betts]

Grant,

I strongly suggest that you report this to IFI.

Mike

[Alan Anderson]

Originally Posted by grantf

• After about 4 seconds (with 3 people standing around the robot) it took off at about full-speed without user input

Which pwm outputs control your drive motors? I don't know whether EasyC fixes the "glitchiness" of pwm13-16. The default code regularly extends the pulse width on those outputs when interrupts happen. That's "forward" to a Victor.

[Dave Flowerday]

Originally Posted by grantf

• The "disable" LED on the OI was solid orange and the RC mode LED was yellow/orange.

If you're certain that the disable LED on the OI was solid orange (and not blinking rapidly), then the control system was indeed disabled and your dongle was working. All the PWM outputs should have been tri-stated, including 13-16. Are you 100% sure that the disable LED on the OI was solid orange? If so then this is a pretty serious problem.

[MikeDubreuil]

If you feel certain that the robot was disabled at the Operator Interface, for the safety of all of us, please contact IFI immediately.

[pheadxdll]

We had to robot take off with no user input before with my laptop attached through the programming cable. My fault though. Laptops okay.

[eugenebrooks]

Problems with the robot not correctly disabling motors when the radio signal is corrupted have (hopefully) been addressed with new beta test versions of the master code. If you are running the latest master code, and still have these problems, make sure you report it to IFI. They are looking for these reports. It is a good idea to pay careful attention to your radio setup, even without these problems, in that radio glitches would normally cause intermittent robot disablement. Keep track of any posted updates to this master code and install them as they are available.

To minimize radio connection problems (hiding any remaining disablement glitches), make sure that:
1) Your radio is placed as high as you can.
2) Your radio is mounted on plastic about a half wavelength away (5 to 6 inches) from any metal structure on your robot.
3) Your radio will not be shadowed by any large metal panels or closely spaced wire grids. If it is shadowed, the reliability might suffer when the robot is oriented so that the metal panel is interposed between the OI and the RC radio modems.

On the OI end, if you mount the radio on a wall, make sure that this wall is not a conducting surface such as metal. The best place for this antenna is in "free space," well clear of metal surfaces (except for a table that it might be sitting on).

If you continue to have problems while on the radio, make sure that you report these problems to IFI and use the tether while testing your robot until the problems are resolved.

All of the interference effects involved when a metal surface is near the antenna is one of the wonders of nature, but you don't want to be exploring these with your robot.

Eugene

[UlTiMaTeP]

Originally Posted by eugenebrooks

Problems with the robot not correctly disabling motors when the radio signal is corrupted have (hopefully) been addressed with new beta test versions of the master code. If you are running the latest master code, and still have these problems, make sure you report it to IFI. They are looking for these reports. It is a good idea to pay careful attention to your radio setup, even without these problems, in that radio glitches would normally cause intermittent robot disablement. Keep track of any posted updates to this master code and install them as they are available.

To minimize radio connection problems (hiding any remaining disablement glitches), make sure that:
1) Your radio is placed as high as you can.
2) Your radio is mounted on plastic about a half wavelength away (5 to 6 inches) from any metal structure on your robot.
3) Your radio will not be shadowed by any large metal panels or closely spaced wire grids. If it is shadowed, the reliability might suffer when the robot is oriented so that the metal panel is interposed between the OI and the RC radio modems.

On the OI end, if you mount the radio on a wall, make sure that this wall is not a conducting surface such as metal. The best place for this antenna is in "free space," well clear of metal surfaces (except for a table that it might be sitting on).

If you continue to have problems while on the radio, make sure that you report these problems to IFI and use the tether while testing your robot until the problems are resolved.

All of the interference effects involved when a metal surface is near the antenna is one of the wonders of nature, but you don't want to be exploring these with your robot.

Eugene

He stated the radios were mounted correctly. The radios this year for many teams are defective. The radios need to get an RMA'ed and replaced chances are. You are not alone, the majority of the teams in my area are having the same radio cutting out problem.

[Eldarion]

Also, from our experience, this problem will only get worse in competition mode, not better! Apparently, at lower channel numbers, the radios are worst. (Our team ran through a testing procedure on almost all 40 channels; we have the results if anyone is interested.)

[UlTiMaTeP]

Originally Posted by Eldarion

Also, from our experience, this problem will only get worse in competition mode, not better! Apparently, at lower channel numbers, the radios are worst. (Our team ran through a testing procedure on almost all 40 channels; we have the results if anyone is interested.)

Very interested Please post

[Eldarion]

I will get the information from the students that ran the test and report back.