Hi Patrik

I went on your blog http://www.x-firm.com/?cat=6
nice job, I will have to jump in Processing some days  :

I have started with the GUI and I want it widget based some please tell me what type of widget you want to have in the GUI.

Those are the parameter I did have to adjust or monitor:

 - STD_LOOP_TIME           adjustable
 - lastLoopUsefulTime        read only
 - lastLoopTime                read only
 - ACC_X, _Y, GYR_Y        read only or trending
 - actAngle, ACC_angle     trending
 - setPoint                        adjustable
 - K, P, I, D                      adjustable
 - pTerm, iTerm, dTerm     trending
 - drive                            trending

More to come with encoder and RC implementations

Code:

Heres the code from the example above...

Sketch for Processing IDE:

Download and unzip the folder in your sketch directory. Change the serial port to the corresponding for you computer...

Complete sketch

Your links are dead  

@Patrik
I am not really familiar with Java/Processing,  :-[
Building a GUI is a great idea, please post ASAP

I just finished a much simpler version, using the IDE serial monitor:

Code:

int getTuning() {
  if(!Serial.available())    return 0;
  delay(10);                  
  char param = Serial.read();                            // get parameter byte
  if(!Serial.available())    return 0;
  char cmd = Serial.read();                              // get command byte
  Serial.flush();
  switch (param) {
    case 'p':
      if(cmd=='+')    Kp++;
      if(cmd=='-')    Kp--;
      break;
    case 'i':
      if(cmd=='+')    Ki++;
      if(cmd=='-')    Ki--;
      break;
    case 'd':
      if(cmd=='+')    Kd++;
      if(cmd=='-')    Kd--;
      break;
    case 'k':
      if(cmd=='+')    K +=0.2;
      if(cmd=='-')    K -=0.2;
      break;
    default:
      Serial.print("?");           Serial.print(param);
      Serial.print(" ?");          Serial.println(cmd);
    }
  Serial.println();
  Serial.print("K:");           Serial.print(K);
  Serial.print("   Kp:");       Serial.print(Kp);
  Serial.print("   Ki:");       Serial.print(Ki);
  Serial.print("   Kd:");       Serial.println(Kd);
}

Usage:
to increase Kp: type "p", then "+" then "enter"
to decrease Kp: type "p", then "-" then "enter"
same procedure for Ki: "i" , for Kd: "d" and for K: "k"

In post 1 , I found that this code don't have the Ki term.

Code:

int updatePid(int command, int targetValue, int currentValue)   {             // compute PWM value
float pidTerm = 0;                                                            // PID correction
int error=0;
static int last_error=0;
  error = abs(targetValue) - abs(currentValue);
  pidTerm = (Kp * error) + (Kd * (error - last_error));
  last_error = error;
  return constrain(command + int(pidTerm), 0, 255);
}

The first code snippet was created as a stand alone PID motor control application.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1282384853/0
It allows to run a DC motor at very low speed while retaining normal torque.
For this type of application, Integral parameter is generally not required.

After I search for two posts I found something useful in post 2 =>Part four: PID control
But while I study your code Code:

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;
  return -constrain(K*(pTerm + iTerm + dTerm), -255, 255);}

I got confuse why the first post's code "updatePID" you got three input variables but second one you got 2 inputs:int targetPosition, int

currentPosition.

For a balancing robot targetPosition should always be "zero"
I chose to create this variable to allow fine tuning and later for RC control

Code:

PWM_val= updatePid(PWM_val, speed_req, speed_act);                        // compute PWM value

PWM_val parameter is not actually modified in updatePid and my original code was:

Code:

 PWM_val= PWM_val + updatePid(speed_req, speed_act);                        // compute PWM value
  PWM_val = constrain(PWM_val + int(pidTerm), 0, 255);

I decided to pass PWM_val as a parameter to allow constrain(XXX, 0, 255) to sit in the updatePid function.
Both implementations are equivalent.

Maybe I am not familiar with PID, would you please tell me that what is the value for -GUARD_GAIN and GUARD_GAIN?
Also, What is the K means?

Integral is the only term that keeps changing no matter how small the error remains
GUARD_GAIN sets up a limit for iTerm. It is standard procedure to clip Integral.
K, Kp, Ki and Kd are parameters to be adjusted purely on experimentation

 

"Hi"

carefully ready the two threads and come back if you didn't find your answers

"Thank you"

Hi Ro-Bot-X
Thanks for the nice comments

...Wish me luck!

I do!!!  

[** Balancing robot for dummies **]

                           [size=14] ** Balancing robot for dummies **[/size]


  [size=14]Part five (final): DC motor control and V1 code[/size]

The updatePid function (see part 4) returns a -255 +255 range value for the motors commands
     0        stop (bot is vertical)
+255      fast forward
-255       fast backward

Motor controllers only understand 0 +255 range values
This is taken care of in the Drive_Motor code

Code:

int Drive_Motor(int torque)  {
  if (torque >= 0)  {                                        // drive motors forward
    digitalWrite(InA_R, LOW);                        
    digitalWrite(InB_R, HIGH);
    digitalWrite(InA_L, LOW);                    
    digitalWrite(InB_L, HIGH);
  }  else {                                                  // drive motors backward
    digitalWrite(InA_R, HIGH);                      
    digitalWrite(InB_R, LOW);
    digitalWrite(InA_L, HIGH);                      
    digitalWrite(InB_L, LOW);
    torque = abs(torque);
  }
  analogWrite(PWM_R,torque);
  analogWrite(PWM_L,torque * 0.9);                           // motors are not built equal...

Please refer to http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1282384853/0
for additional informations

The first part of this tutorial is now terminated (finally...  :-X :-X :-X)
I am impressed by the number of time this thread has been viewed, I hope the info was clear and detailed enough
If you started your own project or intend to do so in the near future, please jump in now and just leave a comment here


KasBot V1 complete code file:
** EDIT **  can't find the trick to upload a file   any hint ???

KasBot V1 is fully functional and should balance for ever
Just modify the code according to your own gyro sensitivity

Code:

int getGyroRate() {                                          // ARef=3.3V, Gyro sensitivity=2mV/(deg/sec)
  return int(sensorValue[GYR_Y] * 4.583333333);              // in quid/sec:(1024/360)/1024 * 3.3/0.002)  
}

My gyro (IDG300) is 2mV/deg/sec
For Accelerators, adjust gravity offset in calibrateSensors()
PID parameters should also be tuned according to your own bot geometry and weight

More to come:
V1.5 will bring "utilities" for live tuning without re uploading the code
V1.7 will replace Arduino 10 bit ADC with MPC3208 12 bit ADC (increased resolution)
V2.0 should combine encoders info in PID to suppress potential forward/backward drifting
V3.0 should bring RC remote control features (Xbee technology)
V4.0 will add IR Ping))) sensor for obstacle avoidance
V5.0 will add...    your own ideas  

Long (probably endless) roadmap  :

you may experiment with the encoders, but I strongly advise not to implemente them in the bot yet.
You can balance pretty well w/o encoders
Encoders will reduce potential forward/backward drifting

Good luck  

I used the greyed sensor inputs like in the image below is that correct:

Nice drawing  , my setup is actually as per your drawing

I recalculated the zero value for Acc_Z
440/3300*1024 = 136

I looked at the MMA7341L Accelerometer datasheet:



Please keep in mind that quoted sensitivity (440 mV/g) is a typical value. Your specific sensor may be as low as 413, or as high as 466.
I suggest you calculate Acc_Z zero value using the experimental way as described above

What I don't really understand is why I didn't need to change the sign of the ACC_X  value to get it like your values.
Why do you enter the values as negative in to the function arctan2 and why adding 256?
Quote:

(arctan2(-sensorValue[ACC_Z], -sensorValue[ACC_X]) + 256)

Signs are related to axis orientation.
Just adjust the signs by experimenting and make sure you get data format as described in reply #7.
256 is an offset (90°) to get a 0 angle value when the bot is vertical

@patrick
If your are still looking for a 12V battery, look at this one
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=150447448378
3800 mAh, 22 bucks shipped

Very clean signal   8-) 8-)
Also check signal quality when sensor is upside down
My sensor combo gives poor result when inversed and couldn't be positioned as per your photo

For ACC_Z, gravity correction = (0° value - 180° value)/2

Quids are nice for integer math
Those are basic 10 bits Quids (360° = 1204 Quids)
For better resolution, we may use Quids12 (360° = 4096 Quids)  

Reply #46 - Today at 02:51:56

beautifulsmall, on which side of the Atlantic ocean are you living ??
Should you live on the "wrong side"  , I hope you have another life for sleeping    

Thanks for you coreless motor description, I was confusing "coreless" and "brushless" motors (the ones with separate ESC controllers)

ive ordered some 120rpm, 6v from china

Depending on wheels size and bot weight, you may find 120rpm a bit slow for proper operation

Planetary geared motor are supposed to have no mecanical backlash
Still trying to identify adequate units with attached encoders

@beautifulsmall

Thanks for the information  
I will study the code and come back to you soon

Please post a link to the motors you are using and possibly a close up photo of your bot. Seems that this gearless setup should solve the backlash problem.

I want to ask you guys also what you think should be the best settings for my accelerometer and may gyro.
LPR510AL Dual-Axis (Pitch and Roll or XY) Gyro with ±100°/s and 400°/s Ranges
MMA7341L 3-Axis Accelerometer ±3/11g with Voltage Regulator      
3g or 11g
100 degrees/s or 400 degrees/s

I would definitly go for the shortest range (3g and 100°/s)
Mines are 3g 500°/s and I would appreciate more resolution for the gyro

Ok I have one more question just to clarify something for me. The X-axis of the accelerometer should be in the rotational axis of the wheels. But should the axis from the gyro be a perpendicular axis to the X-axis of the accelerometer like an Y-axis?
Should i use the Gyro Y-axis on the IMU? I'm cute sure I should use the Y-axis...

:-? :-?   Lets make it clear, you need:
 - one gyro
 - two accelerometers (could work with one)
The gyro should parallel to the rotational axis of the wheels
one Acc axis according to horizontal
one Acc axis according to vertical

I see to different things below, just to clarify this

Please elaborate

@Gibby623

The Accelerometer sense translational accelerations, not angular acceleration.

Hoops  :-[ I fully agree, the angular acceleration is obtained from two orthogonal accelererometers, using Arctg function.
Thanks for those very precise comments
What is the precise subject of your thesis ???

Looking at your video, your bot balances pretty well
You won't get much better without motor encoders

Care to share your code??
I will post the end of my tutorial and KasBot V1 code probably this week end

I have started thinking about how to build the robot and especialy where to place the accelerometer and the gyro,

What I understand I need to have the gyro X-axis in the rotation centre of the wheels but how is it with the accelerometer. when its reading acceleration couldn't I place it where ever I want on the robot?

Could someone please explain me why the gyro should be in the centre of rotation. As far is I understand gyro measures angular velocity, which is exactly the same in every point of a rigid body.

I think the average acceleration would be the same in every point of the robot. When the robot starts leaning to some direction the upper part of the robot accelerates slowly and when it corrects the position the lower part accelerates rapidly.

Interesting question  :

I tend to agree with TJL for Gyros
Gyros sense rotation only, not acceleration.
Rotation is a "system wide" variable for a rigid system
They can be placed anywhere you want, even at the very top of the bot

I have a different analysis for accelerometers
Accelerometers measure both static acceleration (gravity) and dynamic acceleration (movement). They are also very noisy.
Static acceleration is system wide, dynamic acceleration (as speed) is not
As we are interested only in gravity measurement, we want dynamic  acceleration as low as possible.
The best place for reducing rotational acceleration is near the the motor axis.

Others may jump in and correct me if I am wrong
For those who build or already built a bot, where did you decide to place the sensors ??

@Patrik:   I went on your blog, nice start!
Keep feeding it and report here your baby's first steps