Is it possible in RobotC to create a "Kill Switch" to cut power to all the motors?
maybe an if statement to set it to button 10... im not sure of what to do...

goteam327,
You should be able to check for such a disable button being pressed in an outer loop of a tele-op loop after getting the latest joystick state from a bluetooth packet:

You could assign such a kill switch to any button. For example, if you wanted to use button 10, you would check to see if the button was pressed using something along the lines of:

Inside if your if block you would either manually set all your motors to zero and set your servos to their current target... or call a separate function to do the same.

Note that you would have to define such a kill() function according to standard C rules prior to your main() function. Inside of this hypothetical kill() function you would manually set each actuator to an idle value.

Note that we did not set the servo targets to zero. This would have caused the servo to move to the far left position, not to stop. To stop it, we just set the target to the current position.

Now... we get to another question... the question I actually intended to post myself. When we set a motor's speed to zero, we are stopping it by apply breaking. There are some cases where we may not want to hold the break on a motor as it can be a real drain on the battery. An example of when I would want to stop the motors, but not continue to apply breaking is between autonomous and tele-op modes. My code may be running a single program and I may want to stop the robot when the stopbit becomes enabled, but not hold the breaks while the refs tally the scores from autonomous. Here I may want to leave the motors idle without applying power.
Looking at the robotC API, I see one possible answer to this. Since the motors use PWM, there is a function to set whether to float/coast when idle:

Can anyone confirm if this is the correct usage for this function and if there is a corresponding function for the servos?

Thanks,
l0jec

hi,
I suggest not to use a void but a task for this issue.

I did this in my lawn mower robot like



your 2nd question, first part:
yes, is the correct usage for switching to "floating/casting mode", but for Lego encoder motors it's working faulty (see different thread).
Concerning any usage for servos - I unfortunately don't know.

The simplest thing is to use a call to "StopAllTasks()" whenever the "kill" switch is pushed. This will abort the running program. Part of the cleanup process upon program termination is to stop all possible motors.

You have several choices for the "Kill" switch:

• It could be a touch sensor mounted somewhere on your program
• It could be one of the buttons on the PC game controller.
• It could be one of the buttons on the NXT front panel. But then of course, you could simply use the dark grey button to do the same.

Using a separate task to monitor the kill switch is a good idea because it helps protect against errors in main task that may prevent the "check for kill switch" condition from being reached.

To do a kill switch with the joystick I simply put an if statement in the loop for task main that breaks the loop.

As long as this thread has been resurrected... I thought I'd point on a problem with an earlier assumption I had made.
The code below will simply not work:

This is because ServoValue[] does not contain the actual position of the servo; but rather the last target set for the servo. Since the servo's target may not have been reached, setting the target equal to the previous target does nothing to stop the movement.

Does anyone know if they is another way to kill the servo movement/power? At best it seems the students will have to set a 'home' position for the servos, set that as the target in a kill function, and hope the robot can move to that position quickly enough when the stop bit is enabled by the FMS...

That should not be a problem. The current design of the FMS actually kills your program when your time is up. I'm pretty sure that killing the program will also immediately stop any motor and servo motion. You can test this easily enough yourself by starting a servo moving and then hitting the grey button the NXT to kill the program.

There is an option on the HiTechnic sdervo controller to stop sending updates to the servos. For some servos, this will disable the servo electronics and put it into "coast" mode where it stops moving. The servo controller starts up in this state.

IF there was real value for it, it would be possible to add a feature to ROBOTC to immediately enter this state. The way the hardware is implemented, it applies to all servos on a controller and not just a single servo.

I suggest testing what happens when you order a servo to move using NXT-G and then kill the app and see if the NXT-G firmware sets the servos to coast mode or not. The RobotC firmware should do the same thing as the NXT-G firmware. That way robots in competition will all behave the same regardless of the software platform.

Also, adding a RobotC API to give programmers access to this would be a nice addition for a future release.

Without testing, I have one concern with that. FIRST has stated that you could use dual or single program mode and from what you describe, wouldn't killing the program at the end of the autonomous match mess up any teams with a single program (they would have to reset/restart the program to get their tele-op code to work)?
I thought they were simply going to toggle the enable bit which the students need to check for in the code???

That was our original understanding as well. However, they seem to have changed their minds. The current behavior of the FMS as it has been described to me is that it will always kill your program at the end of the autonomous period and will either restart it (same as pressing the orange button again) or run the specified program if you have a dual program configuration.

The key thing to do in your single program code is to wait for the StopPgm flag to clear and then switch on the UserMode flag to run either your autonomous or your driver control function.

We created a template that looks like this:



Note that your driver control code doesn't need to keep polling the joystick because the main task will continue to update the global joystick structure in the background.

Jeff,
If that is the case... I wonder when was FIRST planning to share that bit of information. Our regional is this coming weekend (12/6) and it would be nice to know these things ahead of time.

I think my best bet is to take your template and ours, and merge the two. Your template example appears to work for restarting the program, but if the FMS simply changes the enable bit... your robot would be in trouble. The only safe bet at this time is to code it to be able to come up in either auto/tele mode, but also be able to switch between them/kill the actuators if the FMS does what FIRST originally said.

Also, just out of curiosity, do you know how StopTask() functions (ie, does in interrupt the target task/thread & if so, can that task/thread catch the interruption to do cleanup, etc.)? I haven't seen any documentation on that...

-l0jec

From the help file:

StopAllTasks();
Stops execution of the current program.

StopTask(TaskID);
Stops execution of a single task.


Note: TaskID is the name of the task.

I will post a question to the FTC Forum asking for final clarification about the behavior of the FMS.

If necessary, you can change the main task to look like this:

I received a reply to the question on the FTC Forum. Yes, the FMS will kill your program at the end of the autonomous period even in a single program configuration.