0%
0%

# Double Pendulum Cart

Swing up and stabilization of a double pendulum cart

Similar projects worth following
1.1k views
A double pendulum cart consists of a cart free to travel along a linear rail, with two pendulums in series dangling from the cart. The only actuator is a force input into the cart parallel to the rail - the pendulums are completely unactuated (hence underactuated, in this case one actuator, three degrees of freedom). The challenge is to design a controller that can swing the pendulums into the vertical position, or some other stable pose, e.g. one pendulum hanging down and one up, and to keep them stable in that configuration in response to disturbances. Right now this is all done in simulation, but I plan to build a real system.

I recently took the edX / MIT Underactuated Robotics course (which by the way is excellent, though not easy), and in order to try and consolidate some of the concepts, have been working on the swingup and stabilization of a double pendulum cart system.

A double pendulum cart consists of a cart free to travel along a linear rail, with two pendulums in series dangling from the cart. The only actuator is a force input into the cart parallel to the rail - the pendulums are completely unactuated (hence underactuated, in this case one actuator, three degrees of freedom). The challenge is to design a controller that can swing the pendulums into the vertical position, or some other stable pose, e.g. one pendulum hanging down and one up, and to keep them stable in that configuration in response to disturbances. Obviously it doesn't serve a useful purpose in of itself, but pendulum-cart systems are often use as a vehicle for developing control systems, precisely because they're well understood but difficult to control (partly because of the non-linearity of the dynamics), and because other more complex systems can be approximated by pendulums. A Segway (or balancing robot) is an example of a similar system, albeit one in which you don't have to solve the swingup problem (it's already too late if it's not upright!).

At the moment the project is purely software based, but the intention is ultimately to build a real system. The basic concept is to generate an optimal trajectory using a process called trajectory optimization (direct collocation specifically), linearize the system along the trajectory, and then use a time varying LQR to control the system in closed loop. All the code is implemented in Matlab, and consists of four sections:

1. Functions to generate the equations of motion for a solid body system given the Lagrangian
2. A small animation library
3. A trajectory optimization library using fmincon which implements direct collocation and direct transcription (using 4th order Runge Kutta)
4. A function which creates a closed loop controller for the system along the nominal trajectory

The code (which is still in a somewhat messy state) is now up on github. There's still quite a bit of work to do, but all the constituent elements are working pretty well, and I'm confident now that the closed loop controller should be robust enough to control a real system.

If you've never heard these terms before none of this is likely to make much sense, but hopefully these videos will start to explain what it's all about.

Nominal (optimal) swing up trajectory, using a weighted sum of control effort squared and time squared as the objective cost function (above).

Above: Now the physical properties of the system are perturbed (mass and moment of intertia increased by 5%, damping doubled). Using the nominal force trajectory from the trajectory optimization, it's unsurprisingly not possible to swing up the pendulum.

Incidentally this is simulated using ode45 which uses a variable time step, hence the slightly unsteady playback speed. I need to re-write my animation export function to pick animation frames at a roughly constant interval of time (it's on the to-do list!).

Above: Here's the system with the same pertubations to the physical parameters, but this time using the closed loop controller. Now it can successfully swing the pendulum up. Notice that the two pendulums are near vertical by the end, but the cart is about 0.6 units to the right of the nominal trajectory final position. The LQR is weighted to favour pendulum angle over cart position.

Next - building the real thing!

• ### Progress update...

lukejs311/25/2019 at 16:47 0 comments

Despite appearances (i.e., no posts for years!), I have been making steady if grindingly slow progress on this project. The reasons for this are a combination of other distractions (e.g. interesting jobs, moonlighting as a jazz musician - my other occupation - and having a young child), and my stubborn insistence on making every aspect of this project myself, which in turn has meant reconditioning my lathe, learning to use the CNC milling machine I bought myself, and so on.

Anyway, I plan to provide a quick overview of progress to date here, and then dig into some of the details in future posts. So, what's been happening? Three main things: Choosing the electronics platform for the project, designing and building the mechanical components, and interfacing the electronics to the control software.

Electronics

After a brief flirtation with the Beaglebone Black, I had some exposure to an STM32-based controller for a haptic robotic controller at my then employer (Generic Robotics), and realised that it provided all the functionality I needed and seemed pretty straight forward to develop for. Consequently I selected a STM32f746 mbed development board which includes an Ethernet interface, hardware timers for incremental encoder quadrature, tons of processing power, and furthermore is absurdly cheap. I'm using the mbed environment to develop on, which brings with it lots of rich libraries including an easy to use TCP-IP stack. On top of that I designed a simple breakout board to hook up my three incremental encoders (one per DOF), and do some level shifting.

I'm using an Electrocraft brushed DC servo which I had spare from an old CNC project, complete with 500 line encoder, and two AEDC-5560 5000 line encoders for the two pendulum axis.

For a DC motor, torque is proportional to current, so I'm using a Maxon Escon 50/5 controller module (that's 50V, 5A maximum) with an integrated current control loop. I just have to feed it a PWM signal or analogue voltage proportional to the target current, and it will do the rest.

Mechanical design

This definitely deserves its own post, but I'll try and summarise the system briefly. I'm using V-Slot bearings and 1.5m long extrusion for linear motion of the cart. The cart itself is a piece of V-Slot standard plate with a custom designed body which holds the bearing assembly, encoders and slip ring. A loop of GT2 timing belt provides mechanical power transmission, and two custom machined plates hold the servo and timing pulleys. Short lengths of aluminium extrusion bolted to the two plates allow the whole assembly to be quickly clamped to a bench when I want to work on the project.

The pendula are made from 12mm (10mm ID) aluminium tube. At each end are a pair of brackets which hold bearings and clamp onto the respective axles. There's an encoder on the back of each joint. The second encoder, between the two pendula, is wired via a through-hole slip ring on the back of the cart. Each joint consists of a machined aluminium axle supported by two deep groove ball bearings.

Control interface

I had wanted to rewrite the Matlab based controller to run on the STM32 development board, the idea being that I would transfer the nominal trajectories from the Matlab-based trajectory optimisation program to the controller, and then run the system independently of the host PC. Although this would be an interesting exercise, I realised that it's just a whole chunk of extra work, and the project is going slowly enough as it is! So instead I'm interfacing to the controller using UDP over Ethernet. I can achieve an update rate of up to 2 kHz using this approach. Unfortunately the in-built ethernet functions in Matlab seem to be extremely slow. So far as I can tell they open a new socket for every packet sent, which seems absurdly inefficient. In the end I found some example code for a compiled MEX ethernet interface that offered much higher performance, and I modified it to suit my purposes....

• ### Slip ring configuration

lukejs307/24/2017 at 21:11 0 comments

I've more or less completed my first pass of everything from the cart to the 2nd pendulum. I still need to start work on the rails and the linear actuation. To get signals from the 2nd encoder (between the two pendulums) to the cart I plan to use a slip ring.

Here's a quick (not especially instructive) render:

And here's a picture that probably makes a bit more sense:

The idea is wires from the 2nd encoder (between the 1st and 2nd pendulums) pass through the hollow shaft (green), then after the bearings (also green), exit the shaft the the hole in the side and enter the slip ring (pink). The orange cap holds the slip ring in place and supports the first incremental encoder (orangey-red). I've still got to flesh out the details of how the encoder is attached, hence its currently floating in mid air.

All of this will sit on the cart, which is going to be a stock V-Slot plate with four v-slot wheels.

The joint between the two pendulums is a similar set up, but without the hollow shaft:

The orange block on the right is the 2nd incremental encoder. The block in the middle holds the bearings, and the shaft is positioned with circlips. The circlips may rub against the outer bearing race so I'll probably put some shim washers in to make sure this doesn't occur. The pendulums are attached using the design I outlined in my previous post.

• ### Pendulum plug

lukejs307/24/2017 at 12:34 0 comments

Despite appearances (given the length of time since my inaugural post), this project is steadily, if slowing, progressing! One major reason for the delay has been my starting a new job with a robotics startup, which has consumed a lot of the creative energy that was going into this project (a good thing). But being in that environment has also meant I'm surrounded by people who are experts on various aspects of this project, so I can grill them for suggestions.

Anyway, I'm currently designing the physical hardware for the pendulum test rig itself. There are several elements to this which I'll talk about as I resolve the design, but in this post I wanted to highlight one small aspect I've settled on.

The pendulums will consist of 12mm diameter, 1mm thick (i.e. 10mm ID) aluminium tubing, cut to length.  I anticipate that I'll probably want to be able to swap out different pendulum lengths as I work on the controller, so I want something that easily clamps on to the tubing and can be detached when necessary, and this is what I've come up with:

White piece is SLS Nylon. A threaded insert goes in the top, and an M3 grub screw is screwed in - as this is tightened it forces the tips open against the walls of the tubs it's inserted into.

This shows how an M3 screw attaches the plug/tube assembly to the axle:

Next, more design, and controller electronics choices!

Share

## Discussions

Sam wrote 11/28/2019 at 13:00 point

I love it. Love control engineering and need to do more, love machining and would love to get started! Perfect project for me!

Are you sure? yes | no

Brandon wrote 12/05/2017 at 18:09 point

Cool project for any control engineering fanatic! It would be rather interesting to see an inverted double pendulum with a LQR controller that minimizes the control effort, such that the controller efficiently utilizes the pendulum's dynamics.

Are you sure? yes | no

## Similar Projects

Project Owner Contributor

### TeensyFlight36

Jacob Dahl

Project Owner Contributor

### ZIPY : ZIPY Inverted Pendulum Yakshave

Philip Zucker

Project Owner Contributor

### Synchronous Buck Control Using the PIC16F1769

Brian Cornell

Project Owner Contributor

Blake W. Ford

# Does this project spark your interest?

Become a member to follow this project and never miss any updates