I’ve been thinking about how to make my robot be able to stand up, regardless of it’s center of gravity for a long time. I would hate if it kept drifting away.

The Problem

A naive self balancing algorithm would be something like: “Always accelerate in the direction of tilt”. This algorithm is actually quite excellent, as it should keep the robot standing. However, if the accelerometer is not exactly aligned with the center of gravity – the robot will be tilting slightly in either direction and the robot will be drifting. The center of gravity could also change dynamically – for example if the robot is carrying a bowl of water, or due to other mechanics you add to the robot.

The Idea

I have to find a way to figure out what the center of gravity is. I had to think for a long time before I figured it out, and it turns out that the solution is quite simple. If you stick with the naive self balancing algorithm above, you could simply adjust the accelerometer slightly until the robot stops drifting. So that’s what I want to do in software.

In theory, this will be really cool. The ultimate solution will allow me to extend the robot with for example a really cool robot arm.

(Disclaimer: I’m using affiliate links with DX.com)

Having it automatically readjust to find the center of gravity would allow it to use this gripping arm. The body of the robot would then adjust while the arm is extending. If the gripping arm then grabs something from a table, the body should then lean backwards enough to keep the robot balanced still.

The actual solution

So, in the first step – we made the robot balance itself by accelerating forward if tilting forward, and backwards if tilting backwards using the PID controller algorithm.

We now have another requirement: adjust the accelerometer based on how the robot is drifting. So basically we need to know two things:

What velocity do we want our robot to have? What velocity does it currently have?

The idea is that, if the robot has a velocity that is higher than the velocity we want it to have – then we have to adjust the accelerometer. So, using the PID controller algorithm again, we feed it with the error offset as the first argument. The second argument could be the accumulated movement that has occurred since it started drifting. This should cause the robot to reverse back to the position we wanted it to be initially. The final argument is an estimate of what we believe the next error offset will be. Turns out this is called a Cascading PID controller. A PID controller adjusts the inputs to another PID controller.

Finding the variables

The Current Velocity

The current velocity can be obtained in several ways. The easiest is to trust the amount of current you send to the motors. A better approach is probably to measure the velocity – and that is the approach I’ll be taking. I’ll elaborate on my ideas for that in a later post. I’ve been considering multiple approaches to this, including an encoder wheel, using a camera pointed towards the ground, using optical mouse sensors on the wheels and a hall sensor.

Basically, I find this a bit challenging.

The Wanted Velocity

I’ll set this to 0 for the time being. I’m going to write a simple web application that allow me to adjust the wanted velocity, using my mobile phone over wi-fi. This will be the actual control of the robot. Of course, I wish my robot would have an AI and a mental map of my house etc – but we’ll have to wait for cool new technology to become affordable. All this also deserves a later post.