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]

Originally Posted by 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.

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

[Matt Krass]

Originally Posted by bear24rw

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.

Originally Posted by Matt Krass

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]

Originally Posted by Pat Fairbank

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]

Originally Posted by Andy A.

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.

[Robert Flanagan]

Originally Posted by 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!

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.

[JBotAlan]

Originally Posted by Robert Flanagan

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...

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]

Originally Posted by JBotAlan

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.