11/25/2019 at 16:47 •
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.
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.
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.
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. I'll dig up and post a link to the original code soon, and my own if I can make it presentable.
What next? All of the above works, even if there's scope for improvement. I've started measuring the physical properties of the system, e.g. moments of inertia, joint damping, cart damping, etc, and I've begun running trajectories on the system, and using the trajectory optimisation library to generate trajectories using a model of the system using these parameters. I haven't swung the pendulums up yet, but I'm getting closer. More soon!
Thanks for reading.
07/24/2017 at 21:11 •
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.
07/24/2017 at 12:34 •
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!