Tetrix motor controller reverses reliably every 33 seconds

[zbuhman]

Perhaps I'm doing something wrong.

I'm using the 0.9.1 release.

My code: http://sprunge.us/ZUSV?java

Every ~33.3 seconds +/- 0.5 seconds (average of 10 consecutive reversals), both motors inexplicably reverse direction. I noticed this awhile ago viewtopic.php?f=7&t=3104 but for some reason I never got around to further testing (can't remember why).

I also tried http://sprunge.us/AWXZ?java ; identical results (with the servo controller physically unplugged, in case for whatever reason that makes some sort of difference).

FWIW: mc.getVoltage() returns a steady 12.3V (12V battery), and it doesn't make a difference whether apply a load to the motors or not (though the voltage does drop significantly when the motors are getting somewhat close to stalling).

[kirkpthompson]

Change Thread.yield(); to Delay.msDelay(50); and get back to us on the results.

-K

[kirkpthompson]

And add a setPower(xxx); line to set the power.

I no longer have access to the hardware so debugging this will be hard...
-K

[zbuhman]

http://sprunge.us/iJcS?java

Identical results; motors reverse direction every 33 seconds. Controller voltage is 12.66 V, no mechanical load.

I then tried http://sprunge.us/hKHY?java, which prints forward/backward every 33 seconds, and motor direction *never* flips (and I let that run for 10 minutes).

I then tried http://sprunge.us/JcQU?java, which works just fine as expected.

On the latter-most code, I then changed the first msDelay() call to 33 seconds, and it still worked just fine. Then I changed it to 66 seconds, and, right on queue, it reverses direction just after 33 seconds (before "stop"). So the motors will start out going in the false direction, then halfway through the msDelay(), they go in the true direction. They then stop. Then after the second dir flip, the motors resume going on the true direction, and then again flip to false halfway through the 66 second delay.

Somewhat unrelated: I also noticed from the original 3rd example, that m2 will reliably start and stop a few fractions of a second after m1 (and if I flip the order of the calls around, the behavior changes similarly), so the robot skids left/right about 2-5 degrees when it starts/stops. Is it possible to synchronously start/stop the motors?

[skoehler]

Can you try RobotC or nxjc or any other programming language? I start to believe, that this is a "bug" (or a feature?) of the Tetrix Motor controller.
Can you try to call forward() of the motor every 20 seconds. Does the motor turn in one direction longer than 33 seconds?
And if that doesn't work, can you try to find what makes the motor in one direction longer than 33 seconds?

[zbuhman]

Can you try RobotC or nxjc or any other programming language?

Works fine for me in LabView + Lego/Tetrix extensions.

Can you try to call forward() of the motor every 20 seconds.

Absolutely. http://sprunge.us/HYNH?java It still reverses every 33 seconds.

If that doesn't work, can you try to find what makes the motor in one direction longer than 33 seconds?

Already have: if I alternate between forward() and backward() every 33 seconds, it continues to go whatever direction I started with.

[skoehler]

Can you try RobotC or nxjc or any other programming language?

Works fine for me in LabView + Lego/Tetrix extensions.

LabView wasn't part in my list for a reason: I'm not whether we can actually have a look at the source code of the Tetrix extension. The Tetrix extension is a black box, of which I'd like to know what it is actually doing.

Can you try to call forward() of the motor every 20 seconds.

Absolutely. http://sprunge.us/HYNH?java It still reverses every 33 seconds.

I see.
Update: that was a stupid suggestion by me, since Kirk's code (Kirks wrote the Tetrix driver) 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.

If that doesn't work, can you try to find what makes the motor in one direction longer than 33 seconds?

Already have: if I alternate between forward() and backward() every 33 seconds, it continues to go whatever direction I started with.[/quote]
Well, but that's not a solution. I guess, that if the backward() call might be issued too early, the motor would actually go backward, which is something you don't want, right? And if the call to backward() is issues to late, the motor will already have run a few degrees in the wrong direction, right? So basically, that is not a solution we should implement. It's broken by design (basically a race condition).

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

[zbuhman]

LabView wasn't part in my list for a reason: I'm not whether we can actually have a look at the source code of the Tetrix extension. The Tetrix extension is a black box, of which I'd like to know what it is actually doing.

Well, you did say "any other programming language". I'll see if I can't dig up those nxc drivers and see if they work...

(Kirks wrote the Tetrix driver)

Thanks again Kirks.

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?

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. I'm not sure exactly what's going on beyond that, but I think that delay might actually be working to my advantage, allowing my 33-second reverse-direction guess to work reliably--contrast to if I were to separate the calls to forward() and backward() with a stop() and a 1-second delay between each: the motors would respond relatively instantaneously.

To actually answer your question: if the motor starts going by forward, I call backward() 30 seconds later, the motor would go backward, and then 33 seconds after that it would go forward. It seems to be 33 seconds from the last change in direction that the controller does the involuntary direction-flip.

[kirkpthompson]

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?

Yes, the code is in lejos.nxt.addon.tetrix.TetrixMotorController, method: synchronized int doCommand(int command, int operand, int channel), lInes 408 and 412:

Code: Select all

...
if (motorState[channel]==STATE_RUNNING_FWD) break;
...
if (motorState[channel]==STATE_RUNNING_BKWD) break;


LeJOS firmware changes not needed. Just comment those lines out.

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?

No. It just request the version which counts as an i2c transaction (because it is), keeping the controller active. The code is in the old thread you referenced.

-K

[kirkpthompson]

Hi.

This is a very strange and interesting problem. Have you sent an email to HiTechnic with a description of your problem? They may be able to shed some light on it.

I will try to acquire another controller and motor to see if I can duplicate the problem given the conditions you describe. It may be a few weeks though since my Professor is out of town for awhile and he has the controllers.

Best,
-K

[zbuhman]

Yes, the code is in lejos.nxt.addon.tetrix.TetrixMotorController, method: synchronized int doCommand(int command, int operand, int channel), lInes 408 and 412:

Code: Select all

...
if (motorState[channel]==STATE_RUNNING_FWD) break;
...
if (motorState[channel]==STATE_RUNNING_BKWD) break;


Awesome; thanks. So I did this: http://sprunge.us/QJWg?diff (added in the print calls just so I would know it was actually my modified class that it was linked against, not the original), and I used this code: http://sprunge.us/BjTH?java

So "fwd" prints every second, as expected, but it still reverses direction every 33 seconds to my surprise.

Have you sent an email to HiTechnic with a description of your problem? They may be able to shed some light on it.

I had never even considered that was a possibility. Somehow I doubt anything constructive will come from asking the manufacturer--why would they take someone like me seriously anyway? But it's worth a try I guess (can't hurt).

I will try to acquire another controller and motor to see if I can duplicate the problem given the conditions you describe. It may be a few weeks though since my Professor is out of town for awhile and he has the controllers.

If this goes nowhere in the next few days, I do have access to at least a dozen more of these; I could probably get you one if it wouldn't be too much trouble.

[kirkpthompson]

If you want to take a go at it, my plan is to create a class that just sets up the i2c sensor and sends the forward command (and any other prerequisites) to see if the 33 sec reversal still manifests. If it does, it is most likely a controller issue (at least not the TetrixMotorController class) or possible other software issue. If not, I will be busy...

The controller docs I have can be found @ http://bit.ly/NJ0LZz.

-K

[zbuhman]

If you want to take a go at it, my plan is to create a class that just sets up the i2c sensor and sends the forward command (and any other prerequisites) to see if the 33 sec reversal still manifests.

Sure, I'll take a crack at this... got it. Hmm this is fun; I think I want to attach this thing to my atmega1284p and see if I can make it go doing the I2C all by myself (first I'll have to devise a makeshift connector for these silly cables; would be nice if everything just used those 2.54mm pitch headers).

My code: http://sprunge.us/TMYC?java

That no-time-out bit is pretty handy. So the program returns almost instantly, and the motors keep going and never stop. Well, actually they don't stop in 33 seconds. Instead they stop only when the NXT turns itself off from idling too long. Is that supposed to happen?

But again, to make this absolutely clear: the 33-second reversal most definitely doesn't happen with the code I pasted.

Any suggestions on what I should test next? Perhaps not setting the NTO bit and doing a random I2C command every ~1-2 seconds?

[zbuhman]

I was just thinking; though I obviously have no idea what's going on, perhaps whatever mechanism that's making the motor controller shut off when the NXT shuts off (perhaps IPOWERA going low does this? do we have control over that?) can be used to gracefully shut off the motor controller--and anything else that behaves similarly--on program exit, rather than running a thread that sends a random I2C command behind the scenes to keep the controller awake, which would make it "safe" to set NTO.

[kirkpthompson]

Well, I don't use the NTO in the TetrixMotorController class (safety thing: TETRIX motors are pretty torquey and bad code could cause a robot/mechanism to go haywire so it is best to let the controller shut them off if no "ping") so that is a definite implementation delta. Try to do the "ping" every 2 seconds with the NTO off.

NXT turns itself off from idling too long. Is that supposed to happen?

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

-K