Technology

Inverted Pendulum / Self-balancing robot

1. Introduction

This project grew out of an imperative to make a vehicle with a bit of intelligence, or a robot, if you like.

My conditions were: that I should not need to get boards printed, that it should use up the MEMS device and demonstrate it, and that it might be remotely controlled with the MRF89X I have been working with.

My first attempt was a four wheeled thing, with steppers on each wheel, in a rectangular box. But I found that it would not turn corners. As it is with the present robot, below, I simply placed the circuitry onto a prototyping board and cellotaped it to the base box. Because it would not turn adequately on carpet, I moved onto another idea.

I wanted to make an RHEX type robot, and thought that stepper motors, of which I had six, would be appropriate. I have found that steppers will not move an RHEX. The torque is not enough from them. DC motors are clearly required. See below for the photographs. I am deeply affected by the work of Boston Dynamics, and wanted to have something like theirs. I encourage the reader to have a look at their dog and human-like robots for what can currently be achieved. Boston Dynamics

For my own part, I had an idea of simply making a little toy.

My RHEX 1:

RHEX with steppers

My RHEX 2:

RHEX

2. The inverse pendulum

After the failure of the RHEX with steppers, and unwilling to buy DC motors, I realised the best idea would be to make a self-balancing robot. This would allow use of the steppers, the MEMS, and a robot which could turn corners. I had in mind the idea of giving it remote control through the MRF89X once the self-balancing was done.

The Pendulum robot:

RHEX

RHEX

RHEX

3. The demonstrations

But a self-balancing robot design should set out from the first to ensure that the robot tends to balance itself; that is, balance itself before any balancing forces should act on it. My design does not balance at all, and is unwieldy. The wheels are only partially underneath the mass. So it tends to fall over very quickly.

Therefore, my final product was always going to be unstable, and this can be seen in the video, below.

Photo: Here is a proof of life photograph showing the robot pendulum.

4. Explanatory

The steppers are continuously working to overcome the impetus of the body to fall over. The project actually took around 1 month to complete, as is. It has the very great advantages that it is not based on any Arduino boards, and is relatively rare because it uses the stepper motor. Any further development would need a custom pcb, a better battery pack, and a custom made body, so that the centre of gravity is in a more appropriate place relative to the wheels. I do not at this moment intend to proceed with this things.

Stepper wiring
Is not shown on the schematic. I have used the DRV modules for each motor; there is a simple way to find out which stepper terminal goes to which DRV pin, described on the schematic.

The DRV 8825
Set the module so that the potentiometer to ground potential difference is 0.9V.

PIC
There are two PICS. One with an LCD and connection to the stepper drivers, and which works on the Inclinometer readings. The other PIC is the master for the Inclinometer itself, and feeds the readings to the stepper PIC via I2C.

MEMS
The MEMS is the Microchip MM7150, and the PIC24 with which it communicates is loaded with a programming interface. My code leaves the programming interface intact, so in order to use the robot, you must first program the MEMS output with the four buttons on the board.

Inclinometer
I played around with the accelerometer and gyroscope which Arduino users are accustomed to, when they use the Arduino compatible MPU6050. But the output from the MPU6050 when fused together is the same as the output from the MM7150 Inclinometer, and so I have simply used the raw Inclinometer data.

Serial output
Although there is a serial output terminal on the board, it is not in use.

LCD screen
The LCD is used for debugging the various parts of the code, whether the raw Inclinometer readings, the motor speed, the timing, or whatever. At certain points, the atoi and a proprietary itoa function have to be applied to the data to get it to show on screen, or, to have any meaning for the logic processing.

PIC16 internal clock
The PIC16 is set at maximum processing speed with the internal 32MHz clock, with PLL enabled. This is because the balancing algorithm is quite intensive, and making the robot balance depends heavily on a fast reaction to tilt angles of the MEMS. The PIC24 baud rate is set at its maximum for the same reason.

External Crystal for Timer 1
The PIC16 also has the external crytal. Originally, I had used this for the timing to be used by the algorithm. However, timing is also required for the interrupt which turns the stepper on and off. For one reason or another, I have set both Timers to overflow every 1 millisecond; and because of its greater speed, I used Timer 1 with the crystal to give me a finer interrupt overflow period, so that it is actually less than 1ms.

Batteries
The batteries are from the Parkside range of power tools; they are £20 for the charger, and the 2AH 20V. I stripped them out of the plastic casing to reduce their size. I have a total of 4AH on board at 20V, using two packs.

Voltage regulation
Not shown on the schematic, there is a need for the pure 20V for the steppers, and then 5V for the PIC16, and 3V for the PIC24 and MEMS. I used classic voltage regulators for this.

Notes on tuning the steppers
If they howl or whine, then there is too much current x voltage going through them. Turn the potentiometer anti-clockwise and until this stops.

PID
What a PID is I only discovered while completing this project. So I am no expert. As far as this code and this robot is concerned, I have found that tuning it should be done as follows: First get a range of speeds for the motors, based on a value of 0 to 300, let us say, where 300 will rpresent the highest speed you will want your motor to turn, and 0 should be no turns of the motor.

Then, ensure that you know the exact angle at which the robot body would naturally rest in equilibrium, and use this as the ‘desired_angle’ value. I have found that using a float value will ensure that the motor is continuously running, so that it constantly oscillates. This is advantageous in my application because the robot body falls so easily to the floor, that it is naturally always in motion. Making the motors also naturally always in motion means that the wheels and the body are in a constant uneasy harmony. The wheels pre-empt any noisey movement by creating their own and stronger noise, so to speak.

Next, make the PID algorithm output values which will make the motor turn fast enough so that the motor will halt the falling of the robot body and yet also not cause it to swing back the other way.

The adc_p variable value will increase or diminish the value of the speed variable at a higher or lower rate; it governs acceleration of the motors.

The adc_i variable will give yet more acceleration when the robot is out of balance for longer than it should be; the adc_i variable, that is, is the equivalent of negative feedback in electrical instruments.

The adc_d variable will ensure that, when acceleration occurs, and the robot swings back to upright position, it does not overshoot and fall down the other way.

The code for this PID was taken in part from the work of three Cornell students, which can be found here. Cornell students robot

Because of differences in motor type, and body shape, each robot will have different tuning.

The result is not so much a robot, as a simple inverse pendulum. As such, it has a short pendulum arm, and the arm itself is very heavy. As such, it is very prone to disturbance, and naturally falls over easily and heavily. But the challenge was to make this thing work, despite the unpromising beginnings. And, unbelievably, as far as I am concerned, it actually works. This is largely down to the processing speed and the fine movements of the motors, due to the PID programming.

Technology

Inverted Pendulum / Self-balancing robot

1. Introduction

2. The inverse pendulum

3. The demonstrations

4. Explanatory

4. Schematics

5. Firmware

6. Datasheets

7. End