[Jochen Alt]’s Paul is one of the coolest robots of its type, and maybe one of the coolest robots period. Personality? Check. Omniwheels? Check. Gratuitous feats of derring-do? Check. Paul is a ball balancing robot.
Under the hood, Paul isn’t all that strange. He’s got two microcontrollers, one for taking care of the balancing and kinematics, and another that handles the LEDs, speech processor, loudspeaker, remote-control, and other frilly bits. But the mathematics! Paul is a cylinder standing up on top of a bowling ball, so the only way it can roll forwards is to lean forwards. But of course, it can’t lean too much, because it has also got to balance. It’s absolutely the least reasonable means of locomotion. We love it.
[Jochen] was nice enough to put everything up on GitHub, so you can see how it was done, even though it looks like magic. And we dare you to watch the video, embedded below, and not feel at least a pang of sympathy pain when (spoiler alert!) he falls flat on his face. Does he recover? We’d love to know!
Paul is just one of the stellar robots in the 2017 Hackaday Sci-Fi contest, so head on over there if you still don’t have your fill.
Funny and impressive. Keep it up.
AWESOME and Inspiring.
OMG. I was so afraid I was going to hear “Daisy, Daisy, …”
I was waiting for, “I can feel it, Dave…”
But yeah, same thing.
Yay for Control Systems!
These things require metric *****tons of math to design and implement (like, whole branches of calculus) but allow for some really amazing things. That being said, this is hardly the worst possible system. A cylinder balancing on a ball is a fairly simple system, being essentially an inverted pendulum, where as walking robots of pretty much any kind are a billion times harder. They have a ton of joints and bones and torques and masses to deal with, and some extremely non-intuitive kinematics which dictate how the system will behave in different orientations. That’s why we don’t have really nice, generally available walking robots yet, especially with a dynamic gait. I don’t hold out much hope for community projects to catch up any time soon…
Also, is it not about time we started equipping 3D printers with PID control systems? This should be a standard feature on at least the fancier ARM boards…
My 3D printer has two PID control systems:
– Extruder temperature setpoint
– Bed temperature setpoint
It does not have feedback control for extruder position for a couple of reasons:
– There is no position sensing on the extruder position
– Stepper motors have enough torque, speed, cost and control complexity to do the job.
So, until something changes, there’s no huge pressing need for feedback control mechanisms on hobby-style 3D printers. It would increase the cost for no benefit to normal users.
From a control systems perspective, it’s entirely possible to get by without the temperature PIDs. A much simpler system will also suffice to achieve the same results.
Position feedback however, would be far more useful, allowing for the correction of skipped steps etc. There are projects to try and incorporate it after the fact onto the stepper transparently to the controller, but that’s not really a great solution. It still makes use of steppers instead of much cheaper geared DC motors, and doesn’t allow the controller to make use of position data (a sudden increase in position error likely means a mechanical fault, for example).
The reprap project used to use geared, open-loop DC motors for their extruders, but abandoned it due to (suprise!) insufficient accuracy. This is probably the closest the mainline’s come to cheap closed loop control, but instead of implementing a PID feedback loop to correct it, they continued with the tried and true but significantly dumber stepper solution we all use now. Instead, PID found it’s way into temperature control (probably because you can’t open-loop it, and there were existing *duino examples for temperature PID control).
To be honest, steppers are the lazy man’s solution to the problem of control systems, where you tell the stepper controller to move and hope the motor (with it’s large current draw, including holding current) has enough torque to do it without any corrections needed. Abandoning steppers would mean massively more efficient motors, especially considering that a 3D printer doesn’t need anywhere near as much torque as it’s older CNC cousins (old enough that many used a parallel port to bit-bang the step and direction signals).
The recent article on the Tiko ragged on it for the missed steps of it’s lower powered steppers, but with closed loop control those skipped steps disappear.
Position feedback on a stepper motor only allows identification of problems, not correction.
If you have lost position it is because the motor had insufficient torque to follow the desired path. No amount of math and sensors can overcome a collision, binding, or mechanical failure.
Even a real closed loop servo will immediately fault and cut power if the motor tracking error exceeds a handful of encoder counts. As soon as you have lost position the print is ruined – plastic has already been extruded in the wrong location.
In a properly designed system the motor will not stall unless something has gone horribly wrong. Trying to continue the print in such a situation (by waiting until the axis unsticks? jacking up the torque?) will only damage an already ruined print or cause additional mechanical failures.
That’s an awful exaggeration of the problem at hand, and belies a fundamental misunderstanding about how control systems work and what they do, as well as the non-idealities of real-world processes.
You’re assuming all failures are inherently and absolutely unrecoverable, when this is simply not the case. Fundamentally any real world process will never do exactly what you request of it. That’s why the PID controller on your hot end exists. Any number of short lived disturbances (like air currents, for example) can cause it to deviate from the prescribed value, and are compensated for by the proportional and integral terms in the PID controller.
In the case of the movement of the printer, individual steps are infinitesimally small, and missed steps due to random errors (from hundreds of points of friction and other no-idealities) can be corrected for without any noticeable difference to the print whatsoever. It is only when missed steps are allowed to accumulate that their sum exceeds other sources of error, such as the uniformity of the flow and deposition of molten plastic.
In the traditional solution, you crank up the torque with beefier motors and hope to god that they never, ever miss a step. A better approach is to measure the real, actual effect of your actions and correct each missed step as it occurs. Had the team behind Tiko allowed themselves more time to develop their product, it is entirely possible they could have added position encoder to their motors and leveraged their more powerful controller to fix the issue it has with missed steps and drift (I may yet attempt this myself, having been given one by a disappointed backer, and having seen this effect firsthand).
As for when things go seriously and more importantly, unrecoverably wrong, you really want to have a feedback loop to your controller. Current implementations in 3D printing rely on the the measurement of current in the stepper wingdings triggering a cutout in the driver, but far more time can elapse before that becomes noticeable and the controller itself often has not idea it’s occurred. In implementing a proper control solution you gain the ability to monitor the system and detect when the rate of error is sharply increasing, and take appropriate measures far sooner. You can even log the aggregate error through various operations, and warn the user when their slicer tries to make the machine turn corners more abruptly than it can physically achieve within some specified tolerance.
In summary, control systems not only allow for the detection of issues (many of which currently go unnoticed) but is entirely capable of (and indeed, designed to) recover from errors gracefully and without impacting quality, all while running the machine more efficiently and cost-effectively. Not only that, but when neither correction nor a gradual degradation of performance is possible, a closed loop position controller allows the machine to safely halt much sooner and more gracefully that current stepper drivers allow.
If a well-documented, open source, functional system using stepper motors with an open-loop controller is the “lazy man’s solution,” what do you call posting on the internet about how easy it would be to implement a closed-loop controller? Instead of telling us how simple it could be, I would love for you to help the community by designing and documenting a simple, low-cost solution. Right now the cost to beat is ~$12 for a stepper motor and driver (single quantity). For usability, all I have to do right now is download well-documented code, update a single config file, upload to my MCU and I have a working g-code interpreter. If you can beat that, I would love to try it out, and I’m sure your solution would be very popular in the world of 3D printing and general DIY automation.
I am NOMAD!
The girl in the end (Outtakes) says “So toll ist es jetzt auch nicht, oder?”, which translates into “That ain’t really that cool, is it …” :-D
My lovely daughter takes care that I stay grounded :-)
Maybe so, but it really IS that cool.
this is a very nice video of a very nice looking robot.
I guess that thing that instantly builds that character is the rust… although it is a new build, it looks like an experienced robot (sounds strange, I know). Therefore reciting poems (with a slight attitude) seems more believable. If it was all shiny I guess it would look to artificial, now it seems like the robot has a past and is still going strong, please don’t polish it, keep it this way.
To say it with Gloria: Paul grew strong and learned to get along
I liked the fact that it had an “No Idea” blinkenlight.
What a beautiful build, love how the LEDs work. No wonder you have cool people wearing sunglasses hanging around your couch :P
What’s better than a robot with omniwheels balancing on a ball? A robot with omniwheels balancing on *two balls* (from 2014). Paul’s personality is much better, though – Henri, Le Chat Noir the insouciant and self-involved cat seems involved in the programming, somehow.
https://youtu.be/ZjlZN9qhTXY
If the blue ball was not captive THAT would be something
This, not so much…
We human beings basically walk by falling forward and then catching our fall with our legs. It’s not so different.
Oh, nooooo………. So far I’ve managed to avoid wanting to own any sort of robot, but I must try to build a Paul. Katie isn’t going to be happy.