TeleopPeriodic doesn't seem to iterate fast enough to smoothly run motors

[Tominator368]

Once we finished wiring our robot, we decided to quickly throw together a program which would allow us to test all of our motors. It was simply an iterative robot which instantiated motors controllers like

Victor motor = new Victor(0);

for each motor we wanted to test, and then in TeleopPeriodic, had code that looked like:

void teleopPeriodic() {
   motor.set(.5);
}

Just to see if they would run, if we hooked them up right. But when I ran this code on a motor, it behaved sluggishly and was jittery. My theory was that the set() function wasn't being called rapidly enough, so I decided to place the call in a while loop so that it would iterate faster (I know you're not supposed to do this, since it screws up the timing completely) as follows:

void teleropPeriodic() {
   while(true) {
      motor.set(.5)
   } 
}

Lo and behold, the motor ran perfectly. Isn't the iterative code supposed to iterate fast enough to run a motor? Obviously we don't want to use a while loop in our actual code, since that would literally bring the period to a halt. If you are supposed to be able to do this, what might be causing the problem for us? Thanks.

[RufflesRidge]

Originally Posted by Tominator368

If you are supposed to be able to do this, what might be causing the problem for us? Thanks.

Massive packet loss is the first thing that comes to mind. The TeleopPeriodic function runs once per received packet. Nominally, this is every 20ms, but if you have a bad WiFi signal or other cause of substantial packet loss, it could be much slower.

Have you looked at the DS charts tab while this was happening or the DS log after?

[Arhowk]

Your analysis of the cause of the problem is incorrect. Motors will continue to go at the rate that they were previously assigned. If you were to place that motor set out of the while true loop, the motor should behave (rather it be jittery or smooth)

Speaking remotely, there are a few probable causes for what you are experiencing. Since your code runs multiple motors in the first scenario, is it possible a typo caused you to set the same motor twice with two different values? Is there nothing else being done to the motors in that scenario?

Are your communications totally perfect with 2-10ms ping and no packet loss? You could just be blocking the code that checks for proper router communication in the while true loop

[Tominator368]

Originally Posted by Arhowk

Your analysis of the cause of the problem is incorrect. Motors will continue to go at the rate that they were previously assigned. If you were to place that motor set out of the while true loop, the motor should behave (rather it be jittery or smooth)

Could you explain this further? I'm quite sure motors will not keep their most recent value, at least, for instance, if I were to simply call a set() function in robotInit() so that it was only set once; the motor wouldn't run infinitely in this scenario. By outside the while true loop, do you mean before it so that it is set and then the while loop prevents another iteration?

Speaking remotely, there are a few probable causes for what you are experiencing. Since your code runs multiple motors in the first scenario, is it possible a typo caused you to set the same motor twice with two different values? Is there nothing else being done to the motors in that scenario?

Good point, but I tried with only one motor and came up with the same results.

Are your communications totally perfect with 2-10ms ping and no packet loss? You could just be blocking the code that checks for proper router communication in the while true loop

Quite possibly not. As the other comment mentioned, I'll need to check that tonight and post back. Thanks!

[virtuald]

It would be interesting if you calculated the average/min/max delay time between calls to teleopPeriodic.

Incidentally, the possible inconsistency of packet arrival times is why I tend to use SampleRobot instead of IterativeRobot.

[Mark McLeod]

Originally Posted by Tominator368

Could you explain this further? I'm quite sure motors will not keep their most recent value, at least, for instance, if I were to simply call a set() function in robotInit() so that it was only set once; the motor wouldn't run infinitely in this scenario.

Actually, the motor does keep the same value until your code changes it to something else.

The motor will however stop if there is a motor safety engaged. The motor safety times out if the motor isn't continuously set, because it assumes the code is locked up after ~.1 second or whatever time you set the motor exception to, and cuts off the PWM to prevent a runaway motor.
If your code disabled the motor safety then the motor would suddenly burst back to life at whatever speed was set however long ago.
The motor safety is optional, but is probably engaged by default.

[RufflesRidge]

Originally Posted by Mark McLeod

If your code disabled the motor safety then the motor would suddenly burst back to life at whatever speed was set however long ago.
The motor safety is optional, but is probably engaged by default.

I don't remember in LabVIEW, but in C++ and Java the motor will not restart unless you call Set(). Simply disabling motor safety after it has expired will not cause the motor to restart.

In all 3 languages, MotorSafety is on by default for RobotDrive and off by default for everything else.

[Mark McLeod]

Yep, because the safety turning the motor off was the last setting the motor saw.

[Tominator368]

if you have a bad WiFi signal or other cause of substantial packet loss, it could be much slower.

This is distinctly possible, I hadn't thought to check latency. I'll report back once I'm able to test again this evening. If it is latency, what might be causing it? The computer running the code was in the same room as the router. Come to think of it, the code was deployed from a computer which is not the classmate, and may have had a firewall, etc. Could that be the cause? Thanks.