Robot Disabled, yet I can still actuate a Cylinder- HELP!

[purduephotog]

All-

I witnessed something very scary last night- I was demonstrating to a student how to trigger the actuator and the cylinder fired. I then checked the disable switch, and it was set correctly. I enabled, disabled, and it STILL fired.

I'm very confused- here's the relevant code section:

(global variable)
unsigned char ucGripperPosition = 1; //currently actuated meaning CLOSED

     //ucGripperPosition = 0 is NON actuated, meaning OPEN
     //Confirm double switch state to toggle the gripper position
     if (   (1 == p2_sw_trig) && (1 == p2_sw_top ) && (1 == ucGripperLatch ) ) {
               if ( 1 == ucGripperPosition) { //Gripper is actuated, so open it
                    ucGripperPosition = 0;
                    ucGripperLatch  = 0;
               } else {
                    ucGripperPosition = 1;
                    ucGripperLatch  = 0;
               } //endifelse gripper position
     } else if ( (0 == p2_sw_trig) && (0 == p2_sw_top ) ) {
               ucGripperLatch = 1;
               //printf("     De-Latching Switch\r\n");
     }  //endif -      ignore the current state of the sw_trigs because they both
                    //werent enabled at the same time

     GRIPPERTOGGLE = ucGripperPosition;      //Set the position of the gripper

As you can see we require both buttons to be depressed to fire the cylinder, and both buttons to be released before you can fire the cylinder again. It's an 'oopsy' prevention that hasn't dropped a tube yet...

Suggestions? This code runs inline with the rest of our code.

[Dave Scheck]

My response is under the assumption that the piston fired when enabled and then retracted when you disabled. If all movement took place while disabled, then you have a far more serious problem.

I don't know your level of expertise so I will explain this completely so that others may learn from it.

When the robot is disabled, all OI inputs get to the RC and are processed by your code. However, in that situation, the RC sets all of the outputs to neutral. What it doesn't do is clear any internal variables.

So with your code, you initialize position to closed. With the robot disabled, you press both trigger and top. Your internal variables are now set to the open position, but nothing moves because you're disabled. Now if you enable, you will open because your internal state variable (currently open) is getting mapped to an output.

The way to fix this is to clear your state when you're disabled. Something like this should be what you want.

if(disabled_mode == ROBOT_DISABLED)
{
  ucGripperPosition = 1; //Closed
  ucGripperLatch  = 1; // de-latched
}

We have run into this a few times over the years. Luckily we caught this each time in testing so that there was no physical danger.

Hope that helps.

[Alan Anderson]

Originally Posted by purduephotog

All-

I witnessed something very scary last night- I was demonstrating to a student how to trigger the actuator and the cylinder fired. I then checked the disable switch, and it was set correctly. I enabled, disabled, and it STILL fired.

Did you check the disable light on the OI? I suspect your disable switch was not actually making the connection. Look for loose wiring or connectors.

[purduephotog]

Originally Posted by Alan Anderson

Did you check the disable light on the OI? I suspect your disable switch was not actually making the connection. Look for loose wiring or connectors.

Alan, Dave-

All movement of the robot is disabled and the victors are flashing their 0.5hz flicker (neutral blink).

The OI shows a solid orange 'disabled' LED, and the robot's controller is flickering "disabled'.

I can move the joysticks around and no movement occurs. If I hit the two buttons to fire the claw, the claw actuates. I can continuously open and close the claw while still not being able to drive the robot.

I'll review the code some more... I think the compressor runs automatically too but I'm not certain.

[buddy.smith]

Can you show us how you have this wired? What inputs and outputs are you using for the one that is still moving when the robot is disabled?

Is it one of the PWM / Relay ports? If not, that's the first part of your problem. I'm pretty sure everything that moves has to be on one of those ports, and not an I/O line.

ttyl,

--buddy

[Dave Flowerday]

Originally Posted by purduephotog

I can move the joysticks around and no movement occurs. If I hit the two buttons to fire the claw, the claw actuates. I can continuously open and close the claw while still not being able to drive the robot.

You do have the pump and claw relays plugged into a relay output (and not a digital I/O), right? Sorry, I know it probably sounds like a stupid question, but if so it could explain why things work when disabled. If it is a relay output (and the OI disabled light is solid orange) then that's a scary situation indeed.

[Dave Scheck]

I agree with DaveF's suggestion to check the wiring.

The OI shows a solid orange 'disabled' LED, and the robot's controller is flickering "disabled'.

This really concerns me. Normally, solid at the OI means disabled, yet the flickering at the RC means autonomous. I find it really hard to believe that code that you've written was able to put the robot in this state since the master code is what handles the enable/disable state of the robot.

Is this reproducible? Were you using a radio or were you tethered when this happened?

[purduephotog]

Originally Posted by Dave Flowerday

You do have the pump and claw relays plugged into a relay output (and not a digital I/O), right? Sorry, I know it probably sounds like a stupid question, but if so it could explain why things work when disabled. If it is a relay output (and the OI disabled light is solid orange) then that's a scary situation indeed.

No Dave, it's not a stupid question- it IS plugged into a Digital I/O connector.

I swear the OI disabled light is solid orange. If the robot wasn't crated I'd put a video up.

Could you, uhhh, kindly relate why the IO might be triggering it this way?

(Wired, from memory, from the student that told me this is how:

Digital IO pin 16 to SPIKE relay, relay to valve, vale to cylinder.

[purduephotog]

Originally Posted by Dave Scheck

I agree with DaveF's suggestion to check the wiring.

This really concerns me. Normally, solid at the OI means disabled, yet the flickering at the RC means autonomous. I find it really hard to believe that code that you've written was able to put the robot in this state since the master code is what handles the enable/disable state of the robot.

Is this reproducible? Were you using a radio or were you tethered when this happened?

Ehhh, most people called the robot light solid, but I could see a hint of flicker. I think it was more of a packet issue than anything else.

The OI is solid. When I hit autonomous with the OI, it goes to a maybe 20hz flicker.

[6600gt]

Originally Posted by purduephotog

No Dave, it's not a stupid question- it IS plugged into a Digital I/O connector.

I swear the OI disabled light is solid orange. If the robot wasn't crated I'd put a video up.

Could you, uhhh, kindly relate why the IO might be triggering it this way?

(Wired, from memory, from the student that told me this is how:

Digital IO pin 16 to SPIKE relay, relay to valve, vale to cylinder.

Digital I/O are NOT for SPIKEs. There is a reason for the 8 relay outputs on RC...

Digital I/O are always active!

[Alan Anderson]

Originally Posted by purduephotog

No Dave, it's not a stupid question- it IS plugged into a Digital I/O connector...Could you, uhhh, kindly relate why the IO might be triggering it this way?

Digital outputs do not get disabled.

Your robot is wired illegally.

Move the Spike to a relay output NOW (or as soon as you get your robot out of its crate at a competition).

[Dave Flowerday]

Originally Posted by purduephotog

No Dave, it's not a stupid question- it IS plugged into a Digital I/O connector.

That would be your problem. As others have already pointed out, Spikes need to be on the relay outputs only. Digital I/Os are meant for inputs like sensors or benign outputs like LEDs.

[purduephotog]

Originally Posted by Dave Flowerday

That would be your problem. As others have already pointed out, Spikes need to be on the relay outputs only. Digital I/Os are meant for inputs like sensors or benign outputs like LEDs.

*ducks and hides*

Thanks all. I'm guessing that the compressor shouldn't be wired to the digital IO either... ?

Limit switches OK?

[esquared]

Limit switch good for Digital I/O.
Compressor bad for Digital I/O.

What is the Spike output wiring going to the compressor? The compressor is not fond of being driven in reverse...

[purduephotog]

Originally Posted by esquared

Limit switch good for Digital I/O.
Compressor bad for Digital I/O.

What is the Spike output wiring going to the compressor? The compressor is not fond of being driven in reverse...

Compressor runs forward correctly- we're careful like that....