NXTMMX is causing a crash?

[Rickz2020]

Hey,

I have my robot fully controllable via Android and decided to get the NXTMMX so that I could use an external battery.
I think it might be the battery pack I am using. It's only 6v @ 700mA and I know the unit requires 7.2v or 9v, but I wanted to check and make sure it is not my code before I run out and buy a new battery pack.

Also, I tested it with:

Code: Select all

public static void main(String[] args) {
      NXTMMX mux = new NXTMMX(SensorPort.S1);

      MMXRegulatedMotor cat = new MMXRegulatedMotor(mux, NXTMMX.MMX_MOTOR_1);
      MMXRegulatedMotor dog = new MMXRegulatedMotor(mux, NXTMMX.MMX_MOTOR_2);

      while (!Button.ESCAPE.isPressed()) {
         if (Button.LEFT.isPressed()) {
            dog.backward();
         }
         if (Button.RIGHT.isPressed()) {
            cat.forward();
         }
         if (Button.ENTER.isPressed())
            mux.stopMotors();
      }
   }

And it works perfectly(with my current battery pack), but not on my robot.

This is how the code looked prior to installing the NXTMMX:

Code: Select all

   public void takeControl(DataInputStream input, DataOutputStream output) throws IOException {
       int command = input.readInt();
        int speed = input.readInt();
        LCD.clear();
        LCD.drawString("command: " + command, 0, 1);
        LCD.drawString("speed : " + speed , 0, 2);
        LCD.refresh();
        switch (command) {
            case MOTOR_A_LEFT:
               Motor.A.setSpeed(speed );
              Motor.A.forward();             
                break;
            case MOTOR_A_RIGHT:
               Motor.A.setSpeed(speed );
               Motor.A.backward();   
                break;
            case MOTOR_B_FORWARD:
                Motor.B.setSpeed(speed );
               Motor.B.backward();   
                break;
            case MOTOR_B_BACKWARD:
                Motor.B.setSpeed(speed );
               Motor.B.backward();   
                break;
            case DISCONNECT:
                input.close();
                output.close();
                break;
            case MOTOR_A_STOP:
               Motor.A.stop();
                break;
            case MOTOR_B_STOP:
             Motor.B.stop();
                break;                       
        }
    }

Everything there worked 100% and was very responsive. Then I added the NXTMMX and adjusted the code. replaced the motor commands with:

Code: Select all

   private NXTMMX mux = new NXTMMX(SensorPort.S1);
   private MMXRegulatedMotor forwardOrBackward = new MMXRegulatedMotor(mux, NXTMMX.MMX_MOTOR_1);
   private MMXRegulatedMotor leftOrRight = new MMXRegulatedMotor(mux, NXTMMX.MMX_MOTOR_2);   

And added these to the switch method(I did this for backward() and the other motor on MMX_MOTOR_1)

Code: Select all

                leftOrRight.setSpeed(value);
               leftOrRight.forward(); 

Now, when I run my code and try control the robot via Android, the motors behave erratically. They start and stop and there seems to be a delay somewhere in the connection, although I'm not entirely sure. Eventually it crashes and prints out some error messages on the NXT LCD.

Where might I find a list to all the error meanings?
Any idea's what the problem might be or a clue for me so that I might find it on my own?

I have 2 NXTMMX units and have tested on both of them(seperately) and it's the same problem.
I am using a 6v battery pack. (might be too low)
I am currently testing using normal NXT motors.
Firmware 0.9.0
IDE: Eclipse

Any other info needed, just ask.

Thanks,

Rich.

[gloomyandy]

See this section in the tutorial for how to interpret the leJOS exception data...
http://lejos.sourceforge.net/nxt/nxj/tu ... ugging.htm

Andy

[skoehler]

Now, when I run my code and try control the robot via Android, the motors behave erratically. They start and stop and there seems to be a delay somewhere in the connection, although I'm not entirely sure. Eventually it crashes and prints out some error messages on the NXT LCD.

It is possible by any chance, that the NXT receives many commands in very short time? Because each time you call setSpeed(), you might actually reset the internal speed regulation algorithm of the NXTMMX.
The speed regulation algorithm for the NXT Motor which is implemented in leJOS itself deals much better with this. But when using the NXTMMX, the NXTMMX itself performs the speed regulation of the motors.

Also, if you send more commands per seconds than the NXT can receive, several buffer (in you android phone and inside the NXT) will run full with commands. This will increase latency. It's similar to when you internet connection becomes slow because you have a fast download running in parallel (congestion basically).

Where might I find a list to all the error meanings?

There is no static list of error code. Instead, once you translated the number, the number tell you what exception happened where in the code.
I hope he link Andy provided help you translation the numbers on the screen.

[kirkpthompson]

Every method used by the MMX classes basically issues multiple I2C commands. How "tight" is your control loop? Are you issuing motor commands very quickly? If so, there is a substantial amount of CPU cycles used to do all the I2C management and that is what could be causing your latency. Local motors are "fast" in that they do not have the overhead of the I2C communication cycles (since they are not a sensor). Think about where you plug in the NXTMMX to the brick...

Best,
-K

[Rickz2020]

I think guys are right about there being too many commands sent.

I am sending commands to the NXT brick via Android phone using the tilt sensors. It seems to be sending the data every time the tilt sensor registers a new value. I'm not sure how to overcome this, though. I could use standard buttons but I want something a little more fancy.

My motors behave strangely though. EG: I hold the mobile tilted at a constant angle, say, to the right. The robot should keep turning right for as long as I hold this position, but it doesn't. It appears to hold it, then stop, goes right and holds, then stops... it does this with left, forward and backwards and I'm not sure why. Even if I remove all .setSpeed() calls and have no .Stop() calls, I have the same problem. It's almost as if the motors are "hickuping".

hmmm....

[skoehler]

I think guys are right about there being too many commands sent.

I am sending commands to the NXT brick via Android phone using the tilt sensors. It seems to be sending the data every time the tilt sensor registers a new value. I'm not sure how to overcome this, though. I could use standard buttons but I want something a little more fancy.

You should limit the rate of the messages that you send to the NXT.
Probably, adding a Thread.sleep() in your Android app is the easiest way. However, if that Thread.sleep() is inside in a Listener, it might violate several best-practice recommendations, and it would be time to use another thread for sending the messages to the NXT.

[Rickz2020]

I thought about putting the data sent on a separate thread, but I'm a little nervous

I am using a single DataInputStream on my nxt. The first int read determines the case called in my switch statement and the next int read is the value for the .setPower();.

Do you think it might be an idea to have to separate DataInputStream's... one for the case and one for the values? Is this even possible?

I think that perhaps the cause of the "hiccuping" of the motors is because of the data being on the same stream. I think that maybe the value used to determine the case and the value used for .setPower(value) are getting mixed up and when that happens, the value passed to determine the case to call does not have a corresponding case, and so nothing happens. I'm not entirely sure though. Guess I'll have to try a few more approaches and see if I can come up with something.

However, if that Thread.sleep() is inside in a Listener

... Yeah, it would have to be inside a listener.

PS: Any idea what would cause the "hiccuping" of the motors?

Rich.

[skoehler]

I thought about putting the data sent on a separate thread, but I'm a little nervous

I am using a single DataInputStream on my nxt. The first int read determines the case called in my switch statement and the next int read is the value for the .setPower();.

Do you think it might be an idea to have to separate DataInputStream's... one for the case and one for the values? Is this even possible?

You can only have one DataInputStream per bluetooth connection - always.

I think that perhaps the cause of the "hiccuping" of the motors is because of the data being on the same stream. I think that maybe the value used to determine the case and the value used for .setPower(value) are getting mixed up

I don't think so. You should output the values on the LCD and see, whether they are what they shoud be.

PS: Any idea what would cause the "hiccuping" of the motors?

I posted my theory already. I suspect, that each time you send an I2C command to change the speed, the internal speed regulation algorithm of the NXTMMX resets. Since you send those I2C command all the time, the speed regulation algorithm inside the NXTMMX is reset over and over again and hence never enters normal operation.

[kirkpthompson]

You could also write some code (on the NXT) that emulates what your input device is doing (i.e. phone over BT) to determine if the behavior is communications-related. Put some series of "commands" in a loop with some delays and observe the behavior. If it remains the same, try increasing the delay to see if the "hickuping" decreases.

Best,
-K

[kirkpthompson]

A work-around could be: Keep track of the state of your forward(), backward(), setSpeed() calls [in your tight loop] and do not issue new ones if the state does not differ from the last. This should greatly reduce the effective number of I2C transactions made.

Best,
-K

[skoehler]

A work-around could be: Keep track of the state of your forward(), backward(), setSpeed() calls [in your tight loop] and do not issue new ones if the state does not differ from the last. This should greatly reduce the effective number of I2C transactions made.

I suspect, that the speed fluctuates. So the NXT receives values like 1 0 -1 0 1 -1 0 etc.
Another - maybe even simpler workaround - would be to ignore 9 out of 10 setSpeed commands.

[Rickz2020]

I posted my theory already. I suspect, that each time you send an I2C command to change the speed, the internal speed regulation algorithm of the NXTMMX resets. Since you send those I2C command all the time, the speed regulation algorithm inside the NXTMMX is reset over and over again and hence never enters normal operation.

Yes, but I have already tried without any .setSpeed() calls, as mentioned earlier.

I don't think so. You should output the values on the LCD and see, whether they are what they shoud be.

Yeah, I have done this and they do seem to be correct


This is happening regardless of whether I call .setSpeed(). It's almost as if the motors are "turning off" for a second and then switch back on.

It's driving me crazy xD

[skoehler]

This is happening regardless of whether I call .setSpeed().

And the call to forward() remained? In principle, what I said about setSpeed() might also apply to forward(). I'm not sure about the internals of the NXTMMX class, but it might be forward() which sends the I2C command, and not setSpeed() - or even both. Looking at the source of NXTMMX, it seems that each a call to forward() starts some ramp-up algorithm inside the NXTMMX.

[kirkpthompson]

Reviewing the posts for hints in trying to figure this out and came upon this at the very beginning:

It's only 6v @ 700mA and I know the unit requires 7.2v or 9v,

I would say all bets are off if you are operating the unit outside of its specifications. Hook up a 9V and see if the behavior changes.

Best,
-K

[Rickz2020]

Reviewing the posts for hints in trying to figure this out and came upon this at the very beginning:

It's only 6v @ 700mA and I know the unit requires 7.2v or 9v,

I would say all bets are off if you are operating the unit outside of its specifications. Hook up a 9V and see if the behavior changes.

Best,
-K

Thanks, I'll give it a go as soon as I get to the shops to buy a PSU and report back.

Rich.