Bypass Disable Switch

[jakep]

We are making a robot over the summer using the 2004 RC. However, this is a fully automous robot, and doesn't need to be hooked up via radio (but it can be). We want to be able to let the robot run, with full control of the motors without any OI turned on or anything. However, if you do decide to turn on the OI, the robot should still accept input from it.

My question: Is there anyway to let the RC output to the motors even without an OI plugged in?

Thanks!

[Matt Krass]

If you set the team number to 0, I believe the RC runs entirely autonomous, I don't have access to confirm this. However I also believe that prevents you from establishing a successful radio link, so this might not help you at all.

[bear24rw]

If you set the team number to 0, I believe the RC runs entirely autonomous, I don't have access to confirm this. However I also believe that prevents you from establishing a successful radio link, so this might not help you at all.
I thought it was the last bit down on the dip switch

[Matt Krass]

I thought it was the last bit down on the dip switch

If by last bit down you mean the left most, that's the MSB (Most Significant Bit) and that was used to unlock extra radio channels on pre-2005 controllers I think.

EDIT: The above statement needs to be amended, I left it there for clarity. Pre-2005 controllers needed a dongle to switch radio channels, as well as the team number change, newer ones only need the team number change. I forgot about the dongle but I remember something about newer controllers was less complicated.

[Andrew Blair]

I wasn't sure there was a way to enable this type of operation, short of an IFI code change. I thought I read somewhere that the code required an OI be communicating with the RC for any robot operation to take place, so that you can't easily be killed right as you turn on the robot. Kind of like an out of range disable with RC.

Or maybe not...

[KenWittlief]

there is no auton mode switch on the robot controller. You must have the OI on for the RC to operate

think about this for a minute: if the OI is not on then how in the world would the RC know what the switches on the OI are set to?!

[CmptrGk]

if you happen to have an extra vex controller and the ablility to make cable converters, the vex controller can function without its OI. it even has a #define line in its code to enable only auton mode. i also belive that the edubot controller can function without and OI (this wouldnt need a cable conversion).

[Pat Fairbank]

The robot controller CAN function without the operator interface. To enable this, the team number dipswitch on the OI must be set to 0, then the OI must be tethered to the RC to download the team number setting to it. Once the tether is disconnected and the RC is reset, the autonomous loop will execute forever and the RC will ignore any radio signals, until the team number is changed back to a non-zero value using the tether method.

However, it would be impossible to switch back and forth between OI and non-OI mode on the fly - the team number must be changed each time with the tether cable.

If by last bit down you mean the left most, that's the MSB (Most Significant Bit) and that was used to unlock extra radio channels on pre-2005 controllers I think.
Just to clarify, setting the MSB enables the extra radio channels on the 2005 and later controllers, while the pre-2005 controllers required you to ground a specific pin on the Competition port in order to do so.

[Matt Krass]

Just to clarify, setting the MSB enables the extra radio channels on the 2005 and later controllers, while the pre-2005 controllers required you to ground a specific pin on the Competition port in order to do so.

You're right, I already edited my previous post, but thanks for catching my slip anyway.

[Andy A.]

PBasic type educontrollers can also be run autonomously, by setting the team number to 0 and cycling power. If there is a user defined auto mode program, it will execute until power is turned off.

Another option might be to keep the OI on the robot, connected by a tether and enable automode with a dongle switch. Add a short pause at the start of the program to allow you to flip the switch and extract you're hand before it takes off. This would save you from having to set the team number back and forth, and also allow you a quick and easy way to put the robot under manual control. Just connect a joystick and disable automode and away you go. No radio, external power supply and the only range limit is the length of the joystick cable.

I would be a little leery about a large scale robot running in autonomous mode with out any remote way of turning it off though. But I am not the computer trusting sort...

[KenWittlief]

I would be a little leery about a large scale robot running in autonomous mode with out any remote way of turning it off though. But I am not the computer trusting sort...

I agree - even if the auton code is simple and the bot moves around slowly - thats how it operates when all on-board systems are operating within normal parameters.

what happens if a wire on a sensor breaks, or a connection to one motor fails - or a feedback sensor goes open loop?

On every piece of commercial robotic equipment, that is used in proximity with humans, there is a big red mushroom shaped KILL button where you can get to it without having to go near the robot.

[Rob2713g]

Note: I'm pretty new to programming and haven't tried this yet. While working on a different project I was told to use interrupts. So you could run autonomous until joystick pressed then jump to regular joystick code. Anyone know if this is possible?

[RoboMadi]

Lets not make it much complicated
Our team build a robot that completely runs on autonomous and uses sensors to interface with the environment around it.
heres a simple easy solution

If you set the operator interface to team 0, then tether it to the robot, it forces the robot into permanent autonomous mode. In this mode it does not look for the operator interface.

[KenWittlief]

Lets not make it much complicated...


Complicaitons: what your team will experience if you dont have a kill switch! :^)

[Matt Krass]

Complicaitons: what your team will experience if you dont have a kill switch! :^)

Ken actually I think the word is Lacerations :)

Setting it to 0 would work, but be sure to build in some way to disable it on the fly if necessary. Locally tethering the OI is still an option as you can make a competition port dongle that wires up to a toggle switch between tele-op and auton, with a big red disable button right on top of the robot.

[EHaskins]

On a vex controller this command will put the robot into autonomous,

txdata.user_cmd |= 0x02;

I don't know if it will work on the full sized RC, but it might. I place this in the User_Ini function.

[Noah Kleinberg]

On a vex controller this command will put the robot into autonomous,

txdata.user_cmd |= 0x02;

I don't know if it will work on the full sized RC, but it might. I place this in the User_Ini function.


From the tx_data_record struct in the 2006 frc code:

unsigned char user_cmd; /*reserved - for future use*/

The variable exists in the frc code at least, but there's only one way to find out if it works :p

[KenWittlief]

/*reserved - for future use*/

that means you are only allowed to use it if you are designing an autonomous time machine.

[jakep]

Wow, thanks for all your replies guys! This is a robot where a person rides on it, which is why we need to be without an OI. I was thinking of just leaving the OI and RC together, always tethered, but I think I will just set the team number to 0. We can do without a radio control mode or anything. There is also a deadman's switch on the robot itself, as well as a main breaker switch, and also a Start switch, so there are no worries about it taking off without a rider :P

[Dave Scheck]

This is a robot where a person rides on it, which is why we need to be without an OI.This confuses me. Having an OI doesn't necessarily mean lots of joysticks and controls.

It sounds like your best/easiest solution would be to have your start/stop, deadman's, and any other switches connected to the OI, then tether it to the RC. You could mount these side by side out of the way if you have the room.

Software-wise, you would just a simple state machine with the following transitions:
State Event New State
Off Start/Stop Button Tap On
On Start/Stop Button Tap Off
On Dead Man's Switch Open Off
Then your On state would simply run whatever autonomous actions you want.

[KenWittlief]

Wow, thanks for all your replies guys! This is a robot where a person rides on it, which is why we need to be without an OI. I was thinking of just leaving the OI and RC together, always tethered, but I think I will just set the team number to 0. We can do without a radio control mode or anything. There is also a deadman's switch on the robot itself, as well as a main breaker switch, and also a Start switch, so there are no worries about it taking off without a rider :P

this all depends on how your deadman switch is implemented. When everything is working correctly then the deadman switch will always work

but you need the kill switch for when everything is not working - when some type of failure has occurred - or your SW has jumped out of its loop

that is precisely what the disable switch on the OI is designed for, its outside the part of the design that you have access to, so there is no way you can inadvertantly mess up its functionality.

Having access to the main breaker right off the battery is a good 2nd choice - but even that, if you have to look to find the breaker and get your hand on the level and think about which way to push it, while the robot is carrying you or someone else in a nasty direction..

The kill switch has to be a no-brainer to use - you hit a big red button, the robot stops (no matter what).

[KenWittlief]

This confuses me. Having an OI doesn't necessarily mean lots of joysticks and controls.

It sounds like your best/easiest solution would be to have your start/stop, deadman's, and any other switches connected to the OI, ...

if the dead man switch is not wired to the OI comp-port disable function then you cannot guarantee it will work when needed.

if your SW gets stuck in a loop or does not operate as designed, then it may not read your deadman input switch, or respond to it correctly. And that is when you will need it, when your SW has bugs and your bot goes open-loop.

The real issue goes to the title of this thread: Bypass disable switch. :ahh:

Go into any engineering lab and you will find thousands of dollars invested in test equipment that is used to test and debug new projects, to get them working the way we want them to.

Nobody can design complex systems like robots and get them working perfectly the first time. Thats why the Disable switch is designed into the FIRST control system, and designed in a way that its fool proof. No matter what you put in your code, when you close the disable switch all the outputs on the robot are disabled.

Dont get your mind into a place where you think you dont need it. Its not a bad thing, its a normal and necessary part of every engineered system - a fail safe way to 'pull the plug' when you need it.

[jakep]

Well, we got everything working software-wise without an OI.

KenWittlief, about bypassing the disable switch, yes, not having one is a terrible idea. However, instead of the FIRST disable switch, which would make us attach the OI to the RC at all times to get the robot running, we implemented our own. We actually used a jetski deadman's switch, which works excellent.

[JBotAlan]

Yes, you have a deadman switch, but is it read by software, or is it actually opening the circuit to the motors? I hope it is the second one--these RCs have a tendency to do odd things when you expect them to do something right. For instance--our (team 68) autonomous in the IRI quarterfinals, first match was supposed to drive for .5 sec then shift to low gear. For those of you watching, it very obviously didn't do so. I still don't know why. So, for me, trusting the software is one thing I will never, ever do. We're human, and when we need things to work right, that's when we make the fatal mistakes. Please, for the love of (insert biblical figure here), put a hardware kill switch in--so when it has been activated, even if the software is still outputting full speed, the thing isn't going anywhere.

On a side note, how do you plan to power this power-sled? I thought about doing this, but when I thought it through I realized that our Exide match battery lasts about 2 minutes...then it's pretty dead. That isn't a very useful lifetime. And if you put the batteries in series, 6 of them would deliver 12 minutes. Still not very useful.

Good luck,
JBot

[Not2B]

I have yet to see IT, but I do know they have limited packaging space for the controller. I'll have to see how they (geekTeam) implimented the dead man's switch on .... this thing.

I will say they they are normally pretty good about these things. Our robot dongle for auto mode is a dead man's switch - if someone let's go of the dongle, the robot stops.

I will also add that if the kill switch ISN'T hard wired, it will be easy to add that feature. Soon as you fall off, get off, or let go, IT should stop.

[KenWittlief]

Yes, you have a deadman switch, but is it read by software, or is it actually opening the circuit to the motors?

now you got me wondering too. When I read they were using a deadman switch from a jetski I thought "wow thats clever"

but after more thought, devices like that are designed to cut the power to the ignition circuit, or possibly to short the spark to ground so the gas engine will cutoff. I dont think they are designed for 100A continuous service, therefor it could not be in series with the main breaker, right?

so how exactly is the jet ski kill switch wired into the robot?

[KenWittlief]

Yes, you have a deadman switch, but is it read by software, or is it actually opening the circuit to the motors?

now you got me wondering too. When I read they were using a deadman switch from a jetski I thought "wow thats clever"

but after more thought, devices like that are designed to cut the power to the ignition circuit, or possibly to short the spark to ground so the gas engine will cutoff. I dont think they are designed for 100A continuous service, therefor it could not be in series with the main breaker, right?

so how exactly is the jet ski kill switch wired into the robot?

On a side note, how do you plan to power this power-sled? I thought about doing this, but when I thought it through I realized that our Exide match battery lasts about 2 minutes...then it's pretty dead. ...

if your bot is sucking the battery dead in 2 minutes your drive train is constantly fighting against itself. A smooth running, well conceived FIRST robot drive train will only draw maybe 10 to 15 amps while the robot is running around (average current) - which would give you about 40 minutes on one of the supplied Exide batterys.

[Cuog]

Kill switches are your frineds. our team has been building a powered dolly to carry driver and robot around. We currently have 3 kill switches planned all wired in series witht he diable port on the OI. we have the OI hard tethered into the RC and it stays like that.

We also built a robot that charges after the light and is supposed to stop when it gets too close. it does this in the defualt routine via a button on the OI which will enable charge! or human steering. Our OI for this demo bot also has a kill switch wired right to the competition port incase the code crashes while charging and simply setting it to human control wont stop it.

[jakep]

Ahh yes, the jetski switch handles practically NO AMPERAGE. It is just a signal strength current. It is currently software based, which will be improved soon. However, our drive system is currently so under powered, that you almost don't need a kill switch! (Just let it go, let the motors stall, and let the breakers handle it :P)

In our next revision, we will have some HIGH amp relays hooked up to it. This way, with a small signal current going through the switch, it can cut battery power to the whole device.

[Kingofl337]

You only need to kill power to the RC for an effective deadman switch. If you cut power to the backup battery and the 12v source the robot will stop dead. The RC draws very little power.

[John Gutmann]

On a side note, how do you plan to power this power-sled? I thought about doing this, but when I thought it through I realized that our Exide match battery lasts about 2 minutes...then it's pretty dead. That isn't a very useful lifetime. And if you put the batteries in series, 6 of them would deliver 12 minutes. Still not very useful.
.
If you wire them in series you will just have more voltage. IF you wire them in parallel though, it will last longer.

[Al Skierkiewicz]

On a side note, how do you plan to power this power-sled? I thought about doing this, but when I thought it through I realized that our Exide match battery lasts about 2 minutes...then it's pretty dead. That isn't a very useful lifetime. And if you put the batteries in series, 6 of them would deliver 12 minutes. Still not very useful.

Good luck,
JBot

I hate to pile on here but six batteries in series will output 72 volts. Can you say "WOW that was a huge fireball! Where did the top of the RC go?" You will not get any greater current out of the batteries in this configuration. You can get longer run time with robot batteries in parallel (as above) but these need some steering diodes to keep from self-discharging via the other batteries. Dual battery diodes can be purchased at RV centers but are not cheap. A diode in series with the positive lead of each battery can then be tied in parallel. A simpler solution is to install a larger battery. A car battery or boat battery would work great. If you keep the same breakers, you should have no problem running for a much longer time. Be careful, car batteries can only be used in the upright position!

Back to the death in a two minute match, a well designed robot should be able to run several matches without killing the battery. When teams test their designs, they should monitor individual currents in order to determine whether the design is efficient. Often times, tank style steering with sticky wheels produce the greatest demand on the electrical system. I have experienced near stall currents on robots I have been called to look at. On a four Chalupa drive, that is well over 400 amps. A simple calculation will show that 400 amps flowing through the .011 ohms of internal resistance on the battery (full charge) will drop the battery terminal voltage to 7.6 volts. That is 0.4 volts below the point at which the RC drops out and goes to backup battery. If the drop lasts long enough, the RC will stop controlling your robot. When that occurs, motor current stops, the terminal voltage rises to normal and the robot continues. Watch some matches and when you see a robot hesitate or pause, it is often going into protect mode and disabling the PWM outputs.

[JBotAlan]

"WOW that was a huge fireball! Where did the top of the RC go?"

Oopsie. :ahh: :o
I really need to put a disclaimer in my sig...

I don't understand why you need extra circuitry when using them in parallel. Why would they self-discharge if you tie the positive of each battery together and the negative and draw from that? Time for me to learn something...it's a good reminder that I do not know everything. ;)

"Often times, tank style steering with sticky wheels produce the greatest demand on the electrical system."

Yes, that's out 'bot. I know it won't last more than one match, but then again, I know we are really heavy and do a lot of pushing. I guess it totally depends on how efficient whatever it is you are powering is. A great, heavy pusher = lots of drain on the battery (right? I was pretty confident 'series' was the right word, and now I don't know how much I really know...).

Thanks,
JBot

[Robert Flanagan]

We are making a robot over the summer using the 2004 RC. However, this is a fully automous robot, and doesn't need to be hooked up via radio (but it can be). We want to be able to let the robot run, with full control of the motors without any OI turned on or anything. However, if you do decide to turn on the OI, the robot should still accept input from it.

My question: Is there anyway to let the RC output to the motors even without an OI plugged in?

Thanks!

This is a theory but should work. Go into main.c. You should see something like this.

if(autonomous_mode)
{
User_Autonomous_Code;
}

It seems that if u delete this if statement to just read out

User_Autonomous_Code;

It should just run Autonomous entirely.

[Al Skierkiewicz]

"WOW that was a huge fireball! Where did the top of the RC go?"

Oopsie. :ahh: :o
I really need to put a disclaimer in my sig...

I don't understand why you need extra circuitry when using them in parallel. Why would they self-discharge if you tie the positive of each battery together and the negative and draw from that? Time for me to learn something...it's a good reminder that I do not know everything. ;)

"Often times, tank style steering with sticky wheels produce the greatest demand on the electrical system."

Yes, that's out 'bot. I know it won't last more than one match, but then again, I know we are really heavy and do a lot of pushing. I guess it totally depends on how efficient whatever it is you are powering is. A great, heavy pusher = lots of drain on the battery (right? I was pretty confident 'series' was the right word, and now I don't know how much I really know...).

Thanks,
JBot

Batteries in parallel will naturally not all be at the same terminal voltage. Variables in production will make the output voltage vary due to the internal resistance, the absolute surface area of individual plates, the concentrations of the acid within each cell, even the resistance of the bars that connect each cell internally. That being said, some of the batteries will have slightly higher or lower values. The batteries with the higher terminal voltage will attempt to pass current to the lower battery to keep it at the same voltage. After it has done that for while, it's terminal voltage will drop and the other battery will try to pass current to it. Think domino effect and eventually, the batteries run themselves down to zero volts. All of the current having gone into heat along the way. By placing a diode in series with each battery, it can only supply current it cannot accept current. All current will only flow out of each battery and into the common (all cathodes tied together) of all the diodes. Regular power diodes will exhibit a voltage drop of at least 0.6 volts and increasing as more current is drawn out of the battery pack. Although that works, it is not ideal when you are already taking the terminal voltage down with a high current demand. The diodes at the RV shops are Schottky ( or should be) and they have a much lower voltage drop.
Heavy pushers need not be high current robots. However, a motor in stall is still a motor in stall is still a motor that is not moving. Many designers will take this into account and choose wheels that will eventually break the friction with the floor so as not to stall the drivetrain. In tank steering, a turn will produce the same high currents unless there is modification. Omni wheels are an ideal solution.
Note to all: When a designer sees a such a need in this competition to go into manufacture to make parts that teams need, that is a red flag. Take a look at the Andymark website or the IFI website and see parts designed to solve the particular problems we face in robot design. These people are not going to design and market items that no one will buy. Like selling refrigerators to Eskimos. Native people in Alaska and Canada do not need refrigeration when the ground outside their door is permanently frozen.

Keep asking questions. A person who recognizes they do not know it all will continue to progress and be successful.

[JBotAlan]

This is a theory but should work. Go into main.c. You should see something like this.

if(autonomous_mode)
{
User_Autonomous_Code;
}

It seems that if u delete this if statement to just read out

User_Autonomous_Code;

It should just run Autonomous entirely.
This I do know... :p

Your program won't run at all at first without an OI--that loop doesn't even execute when you power on the RC with no OI--and no outputs are generated even after an OI is connected and then disconnected, even though this loop is running. Follow the instructions of the person who posted earlier on making the RC run without an OI to make it run all the time, and Robert's modification will make the RC run whatever is in your User_Autonomous_Code function.

JBot

EDIT: Just out of curiosity, how did you learn how to do these calculations--the life of the battery? I really don't know any of this. I don't imagine it's that hard, but I just never learned it and I recognize this is some of the stuff I should know being that I'm dealing with electrical this coming season.

Thanks

[Al Skierkiewicz]

EDIT: Just out of curiosity, how did you learn how to do these calculations--the life of the battery? I really don't know any of this. I don't imagine it's that hard, but I just never learned it and I recognize this is some of the stuff I should know being that I'm dealing with electrical this coming season.
Thanks

A lot of this is not calculable. It comes from experience. There is so many variables from match to match and robot to robot it is almost impossible to take everything into account. A couple of rules of thumb help to analyze what is taking place.
1. Tank style steering will put the drive motors into stall when ever they turn unless something is done to reduce the drag (friction) of the side motion of the wheels. More turns in a match will draw stall currents more often, reducing terminal voltage, available battery power and overall battery life.
2. Drive trains that are optimized for pushing only will draw high currents when running flat out at their highest speeds. Making some trade offs in speed vs. pushing will help in current drain. Drivetrains that are designed for high speed (greater than 12 fps) will likely draw extreme currents when starting out from a dead stop and when pushing, bumping into field objects or driving up ramps. Most mechanical experts design for 8-12 fps.
3. Software modification of drive signals will help in current draw. Ramping up to full speed for instance will smooth out the current demands. Dual speed transmissions will also help by giving the designer two separate optimizations for the drive motors.
4. Six motor drives generally will be less effective electrically due to the additional friction of the extra gears, balancing of the loads, etc. Although they will be the greatest pushers if the wheels can couple to the floor, it has been rare that a robot would only push and do nothing else. If you are in stall every time you start a motor, then you are adding two more loads to the battery. Stall currents are listed in the motor spec sheet. 6 x 129 amps for Chalupa drives exceed the max current spec on the battery. Repetitive current demand near the max reduces battery life. I have seen six motor drives that were not able to move the robot if minor damage to the robot caused some additional friction in the drivetrain.
5. One only needs to observe robot operation during practice to recognize problems. An aggressive practice where the robot stalls, falters or halts for a few seconds, is drawing too much current. A tank style robot that "hops" when turning has too much side friction and can be expected to be at max current every time the robot hops up or down. Any odd problems in robot operation such as software failures, "no data radio", intermittent IO tally LED operation or other apparent failures can be attributed to electrical system failures due to low battery.
6. During practice, a robot driving without opponents ought to last at least 6-8 minutes and preferably 10-15 before the battery runs down. Any less, and your design is inefficient and you are reducing the life of the battery. Our batteries have about a 400 charge/discharge cycle life if used in the normal operating range. A robot that eats a battery in 2 minutes has likely cut that life to 100 cycles or less and no amount of charging is going to fix that. It is also going to fail without warning. Check your design by using a current probe or amp clamp to check overall currents while the robot is practicing and check each individual motor current. Keep a list of these currents. If during a competition something seems wrong, a quick check of motor current can identify bent mechanical systems or wheels that have been pushed out of alignment. Currents should be nearly identical from side to side. If they are not, you may have an electrical problem, bent parts or a bad motor.
Hope this helps.