We have a 12V motor connected to HiTechnic motor controller.

We command it to go full speed until 50 encoder ticks go by, then stop, then go backward to the original position.

We find that sometimes 100 ms elapses after passing 50 ticks before stopping or reversing.

It might be even longer than that, because it hits a hard stop at 140 ticks.

What is the "expected" update rate on the HiTechnic motor controller?

What are the factors that affect it?

Can it be configured?

I have attached the program and a spreadsheet of the Datalog containing 6 cycles from 0 to (hopefully) 50 ticks, showing the variation.
(in xls and open office format).

(Note: I can make it worse by only wait1ms(1) in the main task, and waiting 10 ms is what produced the attached data (thus the X axis is in 10 ms units), and making it bigger than 10 didn't seem to help further, and we can't really wait 10 ms anyway.)

(another Note: I also tried using the nEncoderTarget feature, but it moved only a very short distance before declaring it was done.)


Thoughts?

Thanks,
David

[edit: 14 dec 2009 - swapped excel xml file for excel .xls file]

There's several things that can contribute to this

• HiTechnic motor controllers update motor speed on a 50 millisecond (it might be 25 millisecond, I can't remember) basis. The changes are not immediate. If you send multiple command updates within a single clock pulse, only the last one is actually processed.
• Many servo and motor controllers may share the same sensor port. They have to share I2C message bandwidth so a speed update (or encoder upload) command can be postponed for anywhere from 5 to 50 (or more) milliseconds to take impact.,
• Motor controller implements a speed ramping function. Your changes do not take effect immediately. I recall that it takes either 500 or 250 milliseconds to transition from +100 to =100 speed. Smaller changes in speed would be proportional to this. The speed ramping also occurs on the 25/50 millisecond internal clock "tick" within the controller. There is no option to disable the speed ramping.
• I also recall that if you set the speed to zero it takes effect immediately on the next clock tick without the speed ramping. But I don't remember if this is correct.
• I also can't remember whether the controller uses 'float' or 'brake' mode on the inactive side of the PWM pulse. If it is "float" mode then the speed adjustments are slower than with "brake".

Considering all of the above, for your example:

• 5 to 50 (or more) milliseconds to get the encoder count up to the NXT from the HiTechnic controller.
• 5 to 50 (or more) milliseconds to get the adjusted motor speed back down to the controller.
• Up to 50 milliseconds for the controller to recognize the speed adjustment.
• Up to 250 milliseconds for the controller to ramp the speed. [Assuming a non-zero speed setting.]

These are all worst case scenarios. Real-life is probably better.

Temporarily try the following to see if you get better response:

• ONly configure a single motor controller on sensor port.
• Make speed adjustment from powered to zero to avoid the ramping.

If you get much better performance, then you know the factors that added to the delay.

Program source code is not in the attachments.

Source code Attached.

I'll try the suggestions.

I'm curious to understand the mechanism that results in Encoder updates arriving in the 10 ms range, but motor output commands taking up to 150 ms.

I would have expected that response would comparable on reading the encoders from a Motor Controller and writing the new motor commands.

I don't know where you get the 10 msec and 150 msec.

Encoders are polled immediatatley and return valid results.

Motor speed updates need to wait for the internal "clock tick" within the HiTechnic firmware. And then they are subject to the speed ramping function within the firmware. This is on top of the I2C messaging delays.

ROBOTC firmware can transmit I2C messages at a speed of 1 to 5 bytes per millisecond. HiTechnic controllers, on their recommendation, use the slowest 1 msec rate. This is the same (and only) rate found in the NXT-G firmware.

• 12 bytes to read two motor encoders from a controller -- 8 bytes of data and four bytes of overhead
• Eight bytes or so to update the settings for motor speed.
• 10 bytes of so to update servo settings.
• 1 or 2 milliseconds between messages.
• Stick three or four controllers on a single sensor port and the delays can add up.

In the chart attached on the original post, I see a "different" encoder value on every save to the Datalog. In the source code attached on the previous post, the main task runs once every 10 ms, and thus a Datalog entry is made every 10 seconds.

The reason I think the encoder reading is happening at least every 10 ms is that on most every datapoint, the value is different. I see some where the same value is sampled twice, so perhaps the updates are between 10 and 20 ms.

The reason I think the motor outputs are not happening that frequently is that the encoder positions are still accelerating for 100 ms after encoder position was reported as beyond the point (50) where the 0 or -50 command is sent. For a specific example, take a look at
point 307: encoder=53
point 320: encoder=151
Since points are being put in the Datalog every 10 ms, that is a time span of 130 ms.
I haven't actually calculated the slope through that section, but just eyeballing it, I don't think it has even started to slow down when it hits the mechanical stop at 150, and it certainly isn't decelerating at the rate I know it is capable of, for example in points 32 through 46, where it is slowing and reversing at encoder position 100, which is not yet into the mechanical stop (so the deceleration is all attributed to the motor torque, not smacking into a bracket).


Not sure I understand what Polled Immediately means. I would think it means that "on reference" to the encoder value, the Task stops, sends an I2C message, waits for the response, then goes on. e.g. when the program says:
if (nMotorEncoder > 50) { ....
right at that point the I2C message is sent.

Is that what you mean? (if so, I am surprised by that implementation).



So, perhaps a thing to experiment with is whether an intermediate value of 0, that is held long enough to assure the HiTechnic controller receives it before following with the -50, changes the ramp function. i.e. If your recollection about commands to 0 having the ramp suppressed is correct, then perhaps more crisp reversal can be achieved by writing the value to 0 first, holding it until stopped, then reversing, will be more consistent. It is possible that on some cycles, both the 0 and the -50 are seen by the HiTechnic controller, and on other cycles, the 0 is overwritten by the -50 before the HiTechnic controller sees it (resulting in a ramp, instead of step). I thought we tried this, but the results may have been masked by other issues like brake/coast and lack of delay in task main allowing other tasks to run.

I'll try to
- same test, with other HiTechnic controllers removed
- stop before reversing

The parts needed for the test are all at school, so will have to wait until Wednesday.

No. That is not what I meant.

The ROBOTC firmware does all the I2C transactions to the motor controllers in "background" transparent to user programs. The firmware cycles through all the controllers on a sensor port in round robin fashion looking for work to do.

• Updating motor speeds and servo positions take priority over reading encoder values.
• Battery levels are also polled. I think this may be combined with the encoder read but I can't remember.
• And periodically, if needed, it puts in a dummy "write motor to current setting" value to prevent a two-second watchdog from timing out and shutting down the motors.

My reference to "polling" was about the above background firmware processing. Internally the HiTechnic controllers update the motor encoders "instantaneously" and not on the internal 50 (25?) clock tick.

The background processing in the ROBOTC firmware is not the way the NXT-G (and LabVIEW) implementations work. They do inline I2C transactions. So when your program changes a motor speed or servo value, it is "stalled" for the several milliseconds that it takes to do the updates. Similarily, when a NXT-G program reads the encoder values I recall that it also does a I2C read to get the value from the controller.