Tetrix motor controller reverses reliably every 33 seconds

[kirkpthompson]

The reversal thing still is not explained with the NTO bit though....

[zbuhman]

My understanding is if NTO is set, the controller should never turn off so that behavior to me seems weird.

I was surprised too. If it helps increase the credibility of my claim, I have that same NTO code I pasted, with a 1-minute timeout set: http://youtu.be/NdsM5u6Jobw I run my NTO program, it exits instantly, the menu program starts, and the shuts off the NXT 1 minute later, at which point controllers stop. Unplugging the cable doesn't seem to do the same thing, so I'm out of ideas on what happens when the NXT shuts off.

2-second ping: http://sprunge.us/ejeX?java

That code also does in fact not have the 33-second reversal symptoms. That code causes the robot to spin around in circles infinitely without any hiccups, just as one would expect.

[kirkpthompson]

Well, I guess I have some work to do on figuring out what is going on in the Tetrix classes since it seems that is where the problem lies. Thanks for all your debugging and if you have any ideas, please let us know.

-K

[skoehler]

(Kirks wrote the Tetrix driver)

Thanks again Kirks.

It's Kirk, not Kirks. (sorry for my bad typing).

will not send forward() commands to the controller if the motor is already turning forward(). I'm afraid, you have to modify the Tetrix driver to properly test what I suggested.

I wonder if I can manage to disable that check on my own... All I'd need to do to test changes would be to make a new classes.jar, or would I need to rebuild the firmware too? I thought we already established several months ago that the Tetrix driver was supposed to automagically keep sending keep-alives; does that also involve re-sending the state that the controller is supposed to be in?

The drivers are in Java. Just copy their sources to your project, and make sure to move them to another package, so that you don't accidentally use the ones from the classes.jar.
Also, a keep-alive can be any command. I don't think the drivers re-send the state.

What happens, if you do the backward() call after 30 seconds instead of 33 seconds?

Well the other thing is I think the controller firmware itself doesn't immediately respond to changes in forward/backward. e.g: if you say forward() and then backward() a second later, I've observed about another second delay after that before the controller actually reverses direction.

Something smells fishy. It sounds, like the motors cannot keep up with the speed that is specified. Can you try using a lower speed, and see whether that behavior goes away?
Maybe the 33 seconds problems is related.

[zbuhman]

It's Kirk, not Kirks. (sorry for my bad typing).

I thought that sounded funny; but I trusted your spelling.

The drivers are in Java. Just copy their sources to your project, and make sure to move them to another package, so that you don't accidentally use the ones from the classes.jar.

Now I feel silly because I didn't think of that.

Something smells fishy. It sounds, like the motors cannot keep up with the speed that is specified. Can you try using a lower speed, and see whether that behavior goes away?
Maybe the 33 seconds problems is related.

That gives me another idea. So I ran http://sprunge.us/biBH?java and the motors reversed instantaneously, as I would hope. Contrast to: http://sprunge.us/MLai?java . The motors just *barely* start to reverse during the last ~50ms of the second 2000ms delay period. That is, the motors *never* actually start going backwards, they just halfway stutter at the end of their 2-second delay, but are otherwise in fact spinning in one direction for the entire duration of the program's execution (I'm using the classes.jar provided in the lejos 0.9.1 binary release archive for these tests).

If I do http://sprunge.us/Deeg?java, things get even more interesting. The motors start out going forward, stop two seconds later, and then reverse two seconds after that (all fairly instantaneously), but after that first iteration, I didn't put a stop() call after the reverse, and the motors *never* go forward again. After the first iteration of the loop, instead they go backwards for four seconds, and stop for two. So then I tested with the classes.jar with this modification: http://sprunge.us/QJWg?diff, and motorGo() appears to be called for every time I call forward/backward; so I suspect there might be a problem somewhere in that method.

This does appear to be related to the 33 second-reversal problem.

Again: I've not been able to reproduce any of this craziness when I do the I2C commands myself.

I'd withheld this because I thought I would ask it after we sorted out the problems with the motor controller, but I fear this is also related. I've noticed if I call TetrixServoController.setStepTime(), the changes to the setStepTime don't take effect until after setAngle() is called on one of the TetrixServos. This is illustrated by http://youtu.be/gj0SwlLActw . The code I used in that video was http://sprunge.us/MOLc?java . Notice how the first setAngle(60) call moves the servo so fast it slams in to the NXT, whereas the second setAngle(60) is much gentler, even though setStepTime didn't change between the two iterations.

I'd be happy to make more videos (in general) of the problems I'm observing if they help to illustrate the issues I'm describing.

[skoehler]

Again: I've not been able to reproduce any of this craziness when I do the I2C commands myself.

The one program does call setPower() - the other program merely contains the I2C commands for forward() and backward(). What do you expect?
Have you tried the TetrixRegulatedMotor and using setSpeed() instead of setPower()? Have you tried reduced power as I suggested?

[zbuhman]

The one program does call setPower() - the other program merely contains the I2C commands for forward() and backward(). What do you expect?

From what I can tell, the TetrixMotor methods aren't 1:1 with the equivalent I2C commands. What I mean by this, is according to the motor controller documentation, there isn't some kind of "forward/backward/brake/float" register; the register that's used for speed is the same register that's used for "forward/backward".

Have you tried the TetrixRegulatedMotor and using setSpeed() instead of setPower()?

Using TetrixRegulatedMotor would require those motor shaft encoders, which I don't have. Either way, TetrixMotor is clearly broken; which is without a doubt a problem (or at least it *should* be). Not sure why we're questioning this at this point.

Have you tried reduced power as I suggested?

To my surprise, the behavior is actually quite interesting. http://sprunge.us/DcJH?java . When backward() is called, the motors slowly ramp down to a full brake. At setPower(1) the brake period seems to last for ~1 second. I also tested power levels 5, 10, 20, and 50: the results are more or less identical. Acceleration seems to be constant regardless of power level, so the amount of time the motor spends at a complete stop or anything approaching a complete stop decreases as setPower() increases.

Also, I got a response from HT; the guy suggested I just start yanking out chunks of the source and try to find what part is broken (which I'll definitely give it a shot), and also noted that a signed 16-bit timer with millisecond resolution would overflow after 32.8 seconds, which would match my observations.

[kirkpthompson]

Ok, let me know what you find. I will be getting access to a MC in a few weeks and will start to debug then.

-K

[kirkpthompson]

Hi.

I finally got hold of a TEXTRIX MC and have reproduced the same problem. I will post more when I find more.

Best,
-K

[kirkpthompson]

Ok, I found and fixed the problem.

Polymorphism and not testing without an encoder has bit me. I also had some really bad threaded code implementation that I fixed.

The Problem: I used a class hierarchy: TextrixMotor => TetrixEncoderMotor => TetrixRegulatedMotor, and I return a TetrixRegulatedMotor instance from the TetrixMotorController.getBasicMotor() method which the return type is TextrixMotor. I did not turn off regulation before I returned the instance and if you have no encoder attached, it appears that the internal motor controller PID (or something) was overflowing some value every 33 seconds or so (or something like that as this is just a guess).

Since all of my testing during development of these classes was with the encoder attached, this problem never showed up for me. The fixed TETRIX motor controller classes have been committed to SVN.

zbuhman, just to help my sanity, were you using encoders with the motor(s) you were using? My guess is "No".

Best,
-K

** EDIT: ** I re-read the entire thread and found that you were not using encoders. (http://lejos.sourceforge.net/forum/viewtopic.php?f=7&t=3332&start=15#p16626). I am sane. Whew....

[zbuhman]

The Problem: I used a class hierarchy: TextrixMotor => TetrixEncoderMotor => TetrixRegulatedMotor, and I return a TetrixRegulatedMotor instance from the TetrixMotorController.getBasicMotor() method which the return type is TextrixMotor. I did not turn off regulation before I returned the instance and if you have no encoder attached, it appears that the internal motor controller PID (or something) was overflowing some value every 33 seconds or so (or something like that as this is just a guess).

Thank you very much; I will be able to test/confirm this on Monday.

zbuhman, just to help my sanity, were you using encoders with the motor(s) you were using? My guess is "No".

Correct.