Tetrix and NXC

[mattallen37]

of course!
But it's not multiple writing what my code does, every i2c function waits until the bus is ready before it sends a new command.

And do you know how it checks if the I2C bus is available? It uses mutex's.

The program is simple and just uses 2 tasks:
One task (main task) does the following in an endless loop:
- it starts the motors, runs them for 2sec by a Wait(2000), then stops them, starts them again reverse, again runs them for 2sec by a Wait(2000), then stops them.

The 2nd task just reads the encoders in an endless loop about every 20 ms and shows them on the screen, nothing else.

I'm curious if your functions have anyhow different internal functionalities and won't crash like mine.

I was actually referring more to your robot program, not the example.

I'm not sure if mine would be any better. I'm having issues with it crashing as well. It seems to only be an issue when I attempt to read and write in the same program. If I only write, it seems to do really well.

Now I'm really curious how ROBOTC FW does it. Maybe I can someday use a logic analyzer on the I2C lines to look for the "magic touch".

[HaWe]

ok, thx, I see, I misunderstood what you wrote.
As I already wrote before, I can't use mutexes on the subsumption-tasks-level, but if the HT-Tetrix library itself uses mutexes already on the i2c device driver level it's fine of course.

[HaWe]

as I watched are you using the mode byte for setting motors to inverse.
But you are usually commanding 2 motors at once.
For what will the reverse byte be used? for the left or the right? How can you choose which motor of both will be set to reverse?
Normally the 1st motor is the left one and the 2nd is the right one.

e.g., if I have a direct drive, then motor left may be regular forward and motor right has to be set to inverse for driving direction and encoder counting.
But if I have indirect drive, then motor left has to be inverse and motor right is regular forward.
(or maybe both issues other way round)
In other cases for specific constructions (e.g. a 3 DOF robot arm) more than 1 motor has to be set to inverse.

My own approach would be to set a global variable for each single motor which one has to be set to inverse or not (once set by an init procedure). These variables are used by the motor driver internally (and not passed as a variable to the function)

So how do you adjust these settings?

[mattallen37]

There is an options field for each motor. Like I said (I think in a PM), the reverse bit is bit 3 (0x08). Normally, I want a + number to mean it drives forward, and a - to drive backwards. So, I can use a command like this:

Code: Select all

TetrixMotors(TetrixPort, TETRIX_ADDRESS_1, Motor1, Motor2, 0x00, TETRIX_MOTOR_REV);

This will set motor 2 to reverse.

If I want to reverse the other motor, I can use this command:

Code: Select all

TetrixMotors(TetrixPort, TETRIX_ADDRESS_1, Motor1, Motor2, TETRIX_MOTOR_REV, 0x00);

And you're right, you definitely don't need to use the reverse bit; you can just invert the speed variable. Like I said in the blog post, you don't even need to specify the last two parameters. You can use the motor control command like this:

Code: Select all

TetrixMotors(TetrixPort, TETRIX_ADDRESS_1, Motor1, Motor2);

It automatically defaults the options fields to 0, 0.

[HaWe]

ah, ok, now I - very slowly - begin to understand... ;)

[mightor]

ah, ok, now I - very slowly - begin to understand...

Doc, next thing you'll be telling us you're going to write your own I2C device drivers! *grin*

- Xander

[HaWe]

I'll do my very best... ;)

@matt,
I tried your code using different tasks for encoder polling and motor controlling.
It's the same as with my /Xander's code:
the program hangs up or breaks/aborts after a few seconds :(

Code: Select all

    #include "mattTetrixlib.nxc"

    #define TETRIX_PORT S1

    char Motor1;
    char Motor2;
    long Motor1Enc;
    long Motor2Enc;

    int i=-100;
    
    task DisplayValues() {
      while(true) {
        TetrixEncoders(TETRIX_PORT, TETRIX_ADDRESS_1, Motor1Enc, Motor2Enc);

        ClearScreen();

        NumOut(0, LCD_LINE1, Motor1);
        NumOut(50, LCD_LINE1, Motor2);

        NumOut(0, LCD_LINE2, Motor1Enc);
        NumOut(50, LCD_LINE2, Motor2Enc);

        Wait(25);
      }
    }

    task main(){
      TetrixSetup(TETRIX_PORT);
      Wait(15);
      SetLongAbort(true);
      start  DisplayValues;
      
      while(true){

        Motor1=i;
        Motor2=i;

        TetrixMotors(TETRIX_PORT, TETRIX_ADDRESS_1, Motor1, Motor2, 0x00, TETRIX_MOTOR_REV);
        Wait(25);

        if(ButtonPressed(BTNEXIT, false)){                               //Exit the program safely
          TetrixMotors(TETRIX_PORT, TETRIX_ADDRESS_1, -128, -128, 0, 0);
          break;                                       //Jump out of the while(true) loop so the program ends
        }
        i+=5;
        if(i>100)i=-100;
      }
    }

so it's probably a hardware resp. firmware failure of the Hitechnic controller.
There is no use of the controller if one needs the encoder values frequently and continuously for odometry reasons.

[mattallen37]

...so it's probably a hardware resp. firmware failure of the Hitechnic controller...

I'm beginning to see what you mean. Somehow though, ROBOTC doesn't have a problem with it (or does it?). Maybe the controller suffers from an inability to handle slow I2C speeds. I would need to get a logic analyzer, and ROBOTC to be able to continue developing drivers.

Until there are complete NXC drivers available, you really do have options for your robot.

[HaWe]

IIRC there was a report that also RobotC users had the such issues with that Hitechnic controller.