Killswitch

Vex should make a kill switch. I think they should because when i am running autonomous all alone, i know they have a disable button, but they should make a killswitch that you can easily click, almost like a button you hold, that you have to program into your robot, but it is not connected by wire, it is wireless. Sometimes i overdrive shafts because of the lack of easily being able to turn off the robot.

You could slightly modify your code so that the joystick works as a kill switch.

The simplest way to add this feature would be if you could configure lack-of-link as a kill switch. That way you could just turn off your transmitter. It would have to be configurable, since there are times (non-competition) when you do want a robot to be able to operate without link.

You could write your code to behave that way today, but it would be nice if it were built into the firmware so a coding error wouldn’t prevent it from always working.

Cheers,

  • Dean

Thats why they invented threads! :slight_smile: I love using threads, they are my pets! cough cough anyway multi-threading your program is really useful, if a coding error happens in one thread it wont affect another thread (unless you use multi-thread variables but thats besides the point). So you could write your program in one thread and write the killswitch in another thread. The Vex Competition Template in RobotC uses this (sort-of), it checks for competition status, if the status is disabled then all motor ports are overridden to have a value of 0.

isnt that illegal?
since you may not have user input to the robot in autonomous mode

I use a kill switch concept when testing my robot code usually assign button 5up/dn or 6 up/dn to disable a dn re-enable the motors. I simply define a global variable (killSwitch) for example. fetch from the joystick to the variable (toggle logic can be used as well). and for every motor output command I test to ensure killSwitch is not set. - Works great to stop runaway robots. - Might be a good thing for entanglements ? I alos always provide a way to exit out of running some autonomous assist code (say to pre-position a part while the operator control drives) Putting ‘safe’ logic in is time consuming, but very valuable. - Cheers

either pull out the vexnet key or the tether and it will stop whatever you are doing

You could make the shake output a nice kill switch as it doesn’t seem to be a commonly used feature. Also as far as overdriving shafts goes you can and should put limits on your mechanisms in the form of a limit or bumper switch or by setting a stop value on a potentiometer. I great test to see if you have done this well is to ask yourself if you would feel ok with handing the controls over to an inexperienced driver, say, a four year old.

Although you may feel comfortable driving around in practice and visually ensuring you don’t overdrive anything in competition there are a million other factors to think about, there are nerves, you cant always see so well and on top of all that it is just one more thing for the drivers to have to think about. If they can think less about how long they hold the “Raise Arm” button down and more about the game and the next move they want to make the outcome will almost certainly be better.

~DK