Tetrix motor controller reversing direction randomly

[zbuhman]

I now have access to a tetrix kit again, and I've been very much wanting to play with the tetrix code I saw in the trunk a few months ago; I'm using the snapshot that I checked out from svn yesterday.

However, I'm not understanding how it's supposed to work; I'd read that these controllers were supposed to timeout after a few seconds of lack of communication from the NXT; and that had been my experience using the Labview stuff.

So I first tried http://sprunge.us/QjAZ?java . Provided I remember to power the controller, the motor spins like it should... for awhile. It seems that every so often the motor appears to randomly and abruptly reverse direction. Out of curiosity, I then tried http://sprunge.us/TSgC?java which seems to cause the motor to rotate indefinitely (until I press ENTER of course).

TetrixMotorController.java gave me the impression that a new i2c command is not sent anyway if the motor is already supposed to be going forward. I can't seem to find where you magically prevent the controller from timing out otherwise.

Is this related to the i2c issues kirkpthompson briefly mentioned halfway down in viewtopic.php?f=6&t=2854&p=14719 and is that experimental firmware still relevant/useful compared to the snapshot?

[skoehler]

So I first tried http://sprunge.us/QjAZ?java . Provided I remember to power the controller, the motor spins like it should... for awhile. It seems that every so often the motor appears to randomly and abruptly reverse direction. Out of curiosity, I then tried http://sprunge.us/TSgC?java which seems to cause the motor to rotate indefinitely (until I press ENTER of course).

For the record: calling forward() in a loop doesn't make sense. It's a popular beginners mistake though. Your second code snippet is pretty much what the first one should have been like.

From what I've read in TetrixMotorController.java , you don't even send the controller a new i2c command if the motor is already supposed to be going forward anyway, so what's going on? I can't seem to find where you magically prevent the controller from timing out either.

I'm not aware of such a timeout mechanism. I hope kirk will comment on that soon.

[kirkpthompson]

Hi.

re: Experimental Firmware => This was referring to a firmware version that Andy was working on to fix some I2C issues to work with the TETRIX controllers. The current version in the snapshot should be used.

Like Sven said, don't put the forward() in a loop. Use your second snippet.

re: Erratic operation from first snippet: The

I can't seem to find where you magically prevent the controller from timing out either.

"keep-alive" is

Code: Select all

        // This thread will keep the controller active. Without I2C activity within 2.5 seconds, it times out.
        // We could use the NTO bit of mode (MODEBIT_NTO) to keep the controller from timing
        // out but the motors would still run if the NXT faulted, was shutdown, etc. which could be unsafe with big,
        // metal robots with sharp slicing attachments.
        Thread t1 = new Thread(new Runnable(){
            public void run() {
                byte[] buf1 = new byte[1];
                for (;;){
                    getData(REG_VERSION, buf1, 0);
                    Delay.msDelay(KEEPALIVE_PING_INTERVAL);
                    // let the thread die if we are constantly getting tachocounts as this will keep the contoller active instead
                    if (tachoMonitorAlive()) break;
                }
            }
        });
        t1.setDaemon(true);
        t1.start();


I'm guessing that since you called forward() as fast as possible in your loop, there was some thread starvation going on and the Runnable couldn't execute in time to prevent the controller from shutting down the motor. Or maybe, the super-fast continual I2C zero-length reads (still an I2C transaction though...) issued against the controller caused it to freak out a little since it needs time to do it's "thing" to keep motors running, etc.

Bottom line: Use your second snippet and it should work fine. Let us know how you get on.

Best,
-K

[zbuhman]

That without a doubt answers my question; thank you both!

[zbuhman]

I've also toyed with the servo controller classes.

I have a pair of "Hitech HS475HB" servos; I read here http://www.servodatabase.com/servo/hitec/hs-475hb that the servo pulse width is not exactly the same as the defaults. When I use setRange with those values, and then setAngle to 0 and 200, it appears to rotate just slightly under 180 degrees, and I can turn the shaft at least 5 degrees more in each direction.

The defaults, however, appear to be absolutely perfect. Is this intentional?

[kirkpthompson]

Hi.

The default PWM range "Default at instantiation is 750 & 2250 microseconds" is used at instantiation and represent the full PWM output range of the controller so...

I would say it is intentional.

Best,
-K