Re: Benefits of "Periodic Tasks VI"?
 

Ok, this brings up another question I've been thinking about.

Greg, if a speed has not changed from the last loop, is there any reason to call the set speed command? Will not calling it result in a watchdog?

Re: Benefits of "Periodic Tasks VI"?
 

yes, it would if the delay was long enough. it used to be 100ms last I checked.

(safety measure to prevent runaway robots)

Re: Benefits of "Periodic Tasks VI"?
 

The motor safety will trigger if it isn't updated every 100ms (assuming that you didn't disable the motor safety or change the timeout limit). It will not affect the watchdog.

Re: Benefits of "Periodic Tasks VI"?
 

Shouldn't be 10ms, since setspeed commands in teleop aren't called that often.

Re: Benefits of "Periodic Tasks VI"?
 

yeah, it is 100ms. typo. fixing original

Re: Benefits of "Periodic Tasks VI"?
 

Thanks Joe. So - if you've disabled the motor safeties, what happens if set speed is not called for say, 2 or 3 seconds. Does the motor stay at the last set point?

I ask because some of the Beta teams saw a noticeable improvement in CPU usage by putting a simple if/then around their set speed and only calling it on a change.

Re: Benefits of "Periodic Tasks VI"?
 

I'm not Greg, but I know the answer. If a motor has its Motor Safety watchpup enabled, you must continue to set it at least as often as the safety configuration requires. Drive motors have the safety period set at 100 milliseconds. Other motors have the safety disabled by default. If you let a motor's safety timeout elapse without setting its output, that motor will be shut off.

If a motor's safety feature is not enabled, it will keep its last commanded output value indefinitely. That includes switching from autonomous to teleoperated mode (or vice versa, which can happen during testing), so you should make sure your motors are initialized to something reasonable when such things happen.

Re: Benefits of "Periodic Tasks VI"?
 

There are several watchdog and safety mechanisms in effect.

The system watchdog will shutdown the robot outputs when the DS communications is interrupted or an estop takes place. The 100ms timeout is controlled by the Robot Safety mechanism and it automatically zeroes configured robotDrive motors after 100ms. Not setting RobotDrive every 20ms will lower CPU usage, but I'm curious as to how much.

Greg McKaskle

Re: Benefits of "Periodic Tasks VI"?
 

What could cause Driver Station communications to be interrupted?

our team is using UDP to transmit between the Dashboard and the cRIO, which appears to be delaying the watchdog being fed, and interrupting robot communications. the port we're using for the socket isn't being used anywhere else in the code, from what we can see, so what could it be?

Re: Benefits of "Periodic Tasks VI"?
 

wireless failure on the robot, wireless failure of the field, loose cable at the robot, loose able on the field, loose cable at the driver's station, software/hardware glitch on the robot/field/driver's station, random acts of god, solar flares :D , etc.

Re: Benefits of "Periodic Tasks VI"?
 

Can you describe more? Perhaps post some code?

Greg Mckaskle