End to end response times.

[Philbot]

Hi All.

Since I first reported (and got verification) of the small Driver Station App latency, I’ve been hoping there’d be an update (or patch) that would enable me to test the full system end-end latency without incurring this delay, but since it’s been 6 weeks, I thought it I better do the test anyway, using the current release.

Back-story... When I first saw the new control system at Worlds, I thought the response was lackluster.
My estimate was 200-250ms (from joystick to motor) with the legacy hardware, and about half this for the new electronics. This was met with skepticism, but I’ve built a test setup and it’s interesting to see what the scope shows.

My test setup involved cannibalizing a Logitech Controller by adding two wires to the Left Bumper switch so I can attach an oscilloscope and trigger on the Button press action.

I then put a high wattage 10 Ohm resistor (thanks for that tip Steve) across a CORE Motor Controller output and attached the second scope channel across the load.

I produced a new OpMode that simply sets the motor to full power (RUN_WITHOUT_ENCODERS) when the Left Bumper is pressed.

I then sat there repeatedly pressing the Button on the game controller looking for the shortest and longest latencies I could find.
My results are shown below. Note: I was getting a 2mS ping while this was happening.

The Yellow trace shows the falling edge of the button press, and the Blue trace shows the Motor voltage response.
The time scale is 25mS per division, so you can see that the latency runs from about 75ms to 125ms from the time the button is pressed, to the time the first voltage is applied to the motor.

An interesting thing that showed up during this test was that even though the S/W is requesting full power, the Controller steps the motor up to full power in a sequence of ~25mS steps.. 33% power, 66% power 99% power. I’m guessing this is a precaution to prevent excess back EMF on the motor when changing directions suddenly, but, it will also have the effect of delaying the motor response to a start from stopped situation.

So, based on these tests I think my initial guesstimates were pretty close.

It will be interesting to see how this looks when we have a Driver Station without the excess screen updates that are delaying the button/joystick changes.

[Cheer4FTC]

Cool work, Phil!

Could you run the same test with the Legacy Motor Controller to see if there are differences? Or better yet, could you run them at the same time (i.e., push a button on the joystick that causes BOTH a motor connected to the Legacy controller to turn on AND a motor connected to the Core controller to turn on)? That way any trace could show both motor outputs for the same run.

And I suppose it would be really neat to see the same data for the Legacy controller on the old NXT-based system just to see exactly how much things are changing this season.

For what it's worth, this week I set up a Rangerbot with a legacy controlled-motor on the left wheel and a core controlled-motor on the right wheel. When we tried driving straight from a stopped position, it always seemed to start straight: there was not a noticeable delay in one wheel vs. the other that would have resulted in a brief turn before going straight ahead.

[Philbot]

Hi

Yeah, I will do the legacy controller I get my competition kit. I still haven't received either team's kits.

I'm doing these tests using the spares I ordered directly through MR, and I didn't order a Legacy Module.

I may do this for a 2014 system, although my spidy sense tells me it will be about the same for a similarly configured NXT (given that the NXT would only have one controller attached).

And I would expect a heavily configured (several controllers) NXT system would be slower than a heavily configured Android CORE one.

Phil.

[FTC3805]

Does the falling edge correspond to the press or the release of the button? I think the timing should be from the press of the button because that is when people expect to see something start to happen. I'm guessing the minimum time for a button press is 10's of milliseconds. The K9TeleOp example program doesn't debounce the switch press for the servo commands and the minimum number of servo delta events sent to the servo was I believe around 3 for my kids, most often more.

[Philbot]

Does the falling edge correspond to the press or the release of the button? I think the timing should be from the press of the button because that is when people expect to see something start to happen. I'm guessing the minimum time for a button press is 10's of milliseconds. The K9TeleOp example program doesn't debounce the switch press for the servo commands and the minimum number of servo delta events sent to the servo was I believe around 3 for my kids, most often more.

The falling edge is the moment the switch is pressed. This is what is seen by the Game Controller as a PRESS, and this event/state is sent to the Android Phone.

Rather than "Debouncing" (which these switches don't need) I guess you mean that the k9TeleOp code doesn't look for press "events", but instead, sends events as long as the button is pressed.

I did some tests and the shortest button press I could produce was 50 mS with a sharp tap. A typical press (keeping finger on the button) was about 100 mS. Lots of variation in between.

Phil.

[Philbot]

the k9TeleOp code doesn't look for press "events", but instead, sends events as long as the button is pressed.

I meant: the k9TeleOp code doesn't look for press events (state changes), but instead, sends "servo delta events" as long as the button is pressed.

I was reusing your terminology, but the meaning was confused.

Phil.

[FTC3805]

I shouldn't have used debounce, that was wrong. I'll work on terminology.

John

[archimedespi]

The PWMing rampup of motor power might be for back EMF, but I think that's probably not what it's for.
If you want to deal with back EMF, you do it in hardware, with a flyback diode.

[Philbot]

The PWMing rampup of motor power might be for back EMF, but I think that's probably not what it's for.
If you want to deal with back EMF, you do it in hardware, with a flyback diode.

I was only supposing, and quite possibly got my terminology wrong (again).

I was referring to the EMF generated by the rotating motor rather than the collapse of a current in an inductor.
When rapidly changing direction from full forward to full reverse motor speed, I've seen large current spikes due to this Generator effect
of the spinning motor adding to the quickly applied reverse voltage. (there seems to be a voltage doubling effect going on here somewhere)

I've seen this effect fry electronics not rated for the combined voltage.

By slowing down the motor reversal this can be eliminated. But as I said... it was just a supposition.

What is interesting is that this there is no similar graceful reduction in power at the end of the full power sequence.
The Output voltage drops instantly to 0V with no apparent intermediate partial PWM cycles.

Just interesting, that's all.

Phil.

[Philbot]

I Just re-ran the tests with the new Driver station and Robot controller.

I used a simple LinearOpMode control which turns one motor on FULL when the Left Bumper button is pressed.

Again, the Yellow trace is the Button. It drops down when the button is pressed.
The Blue Trace is the voltage being applied to a dummy motor load.

The take away is that the new code is definitely faster, but not by a huge amount.

The minimum latency was 50mS (although the trace I captured was more like 55mS)
And the biggest latency I captured was 120 mSec.

MOST responses fell in the 50-100 mSec, so about 25mS faster than before

The better the absolute response gets, the more significant that ramped up power becomes.