SetSafetyEnabled() and SetExpiration()

[Batman]

During the beginning of the season, our robot had about a quarter to a half second of lag, which I thought was just caused by a bad wireless connection. Then I noticed that all of the motors in the code (there are about 7) were set as follows:

motor1->SetSafetyEnabled(true);
motor1->SetExpiration(0.1);

So just because I had some free time I changed these settings on all the motors to the following:

motor1->SetSafetyEnabled(false);
motor1->SetExpiration(0.5);

When I did this, the robot started to run without any lag at all. What exactly do these functions do, and does anyone have any idea on how they would cause lag with the previous settings?

[Mark McLeod]

If SetSafetyEnabled is false, then the SetExpiration doesn't matter.

These are safeties for the drive motors that shut them down if the code goes for too long (.1 second as specified by SetExpiration) without setting the motor power. It's there to protect you, from infinite code loops or usually during debugging when you could set the motor speed and have a breakpoint that allows the robot to keep running without stopping or responding to driver controls.

If that solved your issue, then it can mean your code is laggy and not running as fast as you want it to (doing too much or having delays in your code), or your code is structured so that you aren't revisiting the motor often enough (set and leave until a change is necessary). Check the Charts tab of the Driver Station to see what communication delays may be happening.

You can run on the field without the Safety, but make sure the robot's up on blocks if you're running in debug with breakpoints set.

[DjScribbles]

If you don't call the motor periodically to set the speed (even if you are setting it to the same value again), it will be stopped and throw an error to the dashboard.

My understanding is that the lag comes from the time it takes to throw that error constantly across the network.

You can resolve the error by ensuring all your motors are being set all the time to a value whenever they are in use and set to 0 when not in use; you can then re-enable the safety.

It's a good idea to use the safety for your drive system especially, so that the robot can't get stuck moving at full throttle if there are communication issues; the safety timer should automatically stop your robot if it's not under control.

[jfitz0807]

We're using java and we had the same problem. We tried:

motor1->SetSafetyEnabled(true);
motor1->SetExpiration(10.0);

Even with these settings, the motor was running jerkily. The jerks were occurring much more frequently than 10 seconds. I know this because the command was defined to run for 3 seconds.

If we disabled the SetSafetyEnabled, the motor ran smoothly.

Any thoughts on why the system seems to think it needs to shut down the motor before the code can get through a single loop of the teleopPeriodic?

[TeraViks]

Mark,

I'm interested in your comments "...it can mean your code is laggy and not running as fast as you want it to (doing too much or having delays in your code), or your code is structured so that you aren't revisiting the motor often enough (set and leave until a change is necessary)...".

We've had these same issues and I don't understand how to programatically affect timing to revisit the motor (or other object). Can you give some instruction or code snippet that might help? Thanks so much!

[bob.wolff68]

If you really have a laggy problem and are trying to figure out what is taking all the time, there are a number of tactics to take. One tactic that can be helpful is getting quantitative values that show "how much time does this part take?" Without a good professional profiler, you can use the 'old school' method of timing...usually you will have a good sense of what's taking all the time - like vision code processing takes a lot of time. Get a value...

I'd suggest something like:

int loopstart, loopend, videostart, videoend;
while (IsOperatorControl())
{
  loopstart = GetUsClock(); // microseconds since startup

 [ code code code ]
  // start of vision code
  videostart = GetUsClock(); // microseconds since startup
  ProcessImage();
  videoend = GetUsClock(); // microseconds since startup
[ code code code ]
  loopend = GetUsClock(); // microseconds since startup
  SmartDashboard::PutNumber("LoopTime-ms", (loopend-loopstart)/1000);
  SmartDashboard::PutNumber("VideoTime-ms", (videoend-videostart)/1000);
  
}

The gist here is to get an idea of at least two things -- how long does it take you to loop the loop and how long does your "big possible offender" take to run? In SmartDashboard, you can have these values plotted as a graph rather than as just numbers "flitting" on the dashboard. That helps to see if you have consistent results or if your processing is for some reason sporatic.