the only problem I can see is that the initial position (when the sensors are zeroed) does affect a lot the behaviour of the robot.

Is there any way to fix it ?

Kas said that the initial position is not so important because of the feedback of the encoders, but my expirience is different.

Yes, I have the same question, I don't see how the encoder based solution can help with self calibration as it doesn't adjust the setpoint.

Hi there, I'm hoping to start a home brew style collaborative robotics club in Nortern ireland, I'm in Belfast to be precise.

If you're from around here and interested plaese let me know,

Ta! Richard.

So, how do we get these muppets to port the posts in from the old forum?

Anyway, I have a question from this old thread: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1284738418/210

The OP asked:
(1) in the setup, with the function calibrateSensors(); you have to put the robot (each time you switch it on) exactly in the static equilibrium position in order to evaluate zero values (exept for z).
is this a little bit boring and could produce errors (if it is not perfectly perpendicular)?
If during the calibrateSensors() i'll give a tilt, the Robot will work to keep the tilt!
And KAS answered:
No No...
If you tilt the bot forward before calibrateSensors(), it will move forward and find a vertical equilibrium
This will happen only with encoder(s) implementation, look here ...

I don't understand this, hoping someone can explain it to me.
As far as I can see, adding the wheel position and speed into the equation as demonstated will only serve to try to bring the bot's position back to where it started. It doesn't change the angle setpoint, so if the setpoint is off from vertical surely it's still never going to find it's own equilibrium? i.e it will always work to achive the state of the original tilt.
I imagine I'm just wrong but would like to understand why?


 
 
 
 

Thanks all for your help, working now! In case it helps anyone else here's what I've learnt about this device:
The I2C address for the MD25 is indeed 0xBO however the Wire Library only uses 7 bit addresses so you need to shift that one bit to the right i.e. 0x58
You don't need pull up resistors if just using one close by I2C device from the duemilanove or mega.
You don't need to enable the internal pull up resistors by setting the I2C pins HIGH if using the Wire library as this is done for you by calling Wire.begin().
All the wiring you need is to connect the arduino to MD25 sda, scl and ground.
You can just power the arduino by usb and the MD25 by a 12V battery, no 5V battery required anywhere.
 

Excellent! thanks, I'll give that a go.

Although, just read somewhere else that using the Wire library (which I am) automatically enables the internal pull ups on SDA and SCL lines.

Thanks for the tips:
Make sure:-
1) You are using analogue pins 4 & 5 not the digital ones for the I2C bus lines.
I used analogue in 4 and 5 on the duemilanove but the mega has dedicated I2C pins so I used those on there.
2) Use a 4k7 pull up resistor on each line.
I've read several places that this is not necessary for a single I2C device as the arduino's internal pullups suffice. is this not the case? Is there some way I need to activate the internal pullups?
3) Get the address right, use the address format where the read / write bit is not the least significant bit. That is just the address.
Address is 0xBO which is flashed out by the MD25 on power on for verifiaction. Does that sound sensible?
4) Make sure the grounds are connected together.
Yep, did that.

By the way, I should mention that I've got this working using the MD25's serial interface, it's jsut the I2C I can't get to work. So I don't htink there are any hardware faults.

Does anyone have a working sketch for interfacing the MD25 motor controller using I2C with an Arduino Mega or Duemilanove?

I've tried the one mentioned elsewhere on this forum but it hangs while waiting for a reply from the MD25.

I've connected grounds, SCL and SDA lines, the Arduino is powered via USB and the MD25 with a 12V battery, no other connections.

What is the frequency on the SCL of the Arduinos? the MD25 says it will work with up to 100KHz.

Thanks, Richard.

On the sending data to the gui question, would it be any quicker to put the strings into a buffer using sprintf and then send it in one Serial.println?
Other than that, I can only think of usng a fixed format that the GUI understands and sending bytes as you say.

Ah, excellent Patrik, thanks, that's that sorted.

My robot's actually working a bit better now, balancing, kind of ...

Going to work on the encoder parts now.
I also put a couple of "emergency wheels" on the bottom that swing down and are also supposed to hold it steady while it does zero calibration at the start, then swing up out of the way to let it balance. Only problem is, the servos only have the torque to hold the robot up when it's near vertical!

Oh well, back to the drawing board ...

Hopefully a quick one folks, in the v2 code for the serial GUI it has this function:

Code:

int getGyroRate()
{                                             // ARef=3.3V, Gyro sensitivity=2mV/(deg/sec)
  return int((sensorValue[GYR_Y] * 0.88888888889)*-1);
}

Where does the 0.88888888889 constant come from? it doesn't seem to match any ref voltage etc.

Thanks!

Thanks! I'll give those ideas a go and let you know how I get on.

Folks, hoping for some tips. I've built a balancing robot using an IMU 5DOF, the MD25 motor controller and EMG30s but the motors simply don't seem to respond quickly enough.
I've pretty much used the code being discussed on this thread with a few exceptions -
I'm using an arduino mega so have used the internal ref voltage of 2.56V and the amplified gyro outputs on the IDG500 so my gyro conversion looks like this:

Code:

int getGyroRate()
{    
    return int(sensorValue[GYR_Y] * 0.781440781);  // in quid/sec:(1024/360)/1024 * 2.56/0.0091)
}

I'm using I2C for the motor controller which needs a 0 to 255 where 128=stopped so to get my drive value I do:

Code:

int updatePid(int targetPosition, int currentPosition)  
{  
    int error = targetPosition - currentPosition;
    pTerm = Kp * error;
    integrated_error += error;
    iTerm = Ki * constrain(integrated_error, -GUARD_GAIN, GUARD_GAIN);
    dTerm = Kd * (error - last_error);
    last_error = error;
    
    int x = -constrain(K*(pTerm + iTerm + dTerm), -255, 255);
    x /= 2;
    x += 128;  
    return x;
}

When calibrating my sensors and getting readings I disregarded any outliers:

Code:

int compare (const void * a, const void * b)
{
    return ( *(int*)a - *(int*)b );
}

void calibrateSensors()
{
    int allVals[50];  
    long v;
    
    for(int n=0; n<3; ++n)
    {
        v = 0;
        for(int i=0; i<50; ++i)      
        {
            allVals[i] = readSensor(n);          
        }
        qsort(allVals, 50, sizeof(int), compare);
        
        for(int i=5; i<45; ++i)
        {
            v+= allVals[i];
        }
        sensorZero[n] = v/40;
    }
    sensorZero[ACC_Z] -= 137;
}

void updateSensors()
{
    int allVals[5];
    long v;
    for(int n=0; n<3; ++n)
    {
        v = 0;
        for(int i=0; i<5; ++i)      
        {
            allVals[i] = readSensor(n);
        }
        qsort(allVals, 5, sizeof(int), compare);
        
        for(int i=1; i<4; ++i)
        {
            v+= allVals[i];
        }
        sensorValue[n] = v/3 - sensorZero[n];
    }
}

I also timed my loop over 1000 iterations and found it took about 3.5ms per iteration so I've tried setting the STD_LOOP_TIME to 5 but it didn't help.

My angles look pretty good and if I print out the time, angle and drive as they change they look ok though the time is slowed down by the printing.
However, if I let the robot go from vertical I can see it's almost beyond the point of no return before the motors kick into life.
If I stop it falling too far on each side by hand I can see that the motors are doing the right thing, just not quick enough.
I've mainly just tried increasing the P val for pid so far, I and D are 0, though I've tinkered there too with no joy.

I don't know much about I2C, could it be just to slow for this task? Surely the EMG30s are up to it?

Appreciate any advice!