Pre-ramble I have been wanting to give drake a try for a while now, and after running into some issues with Gazebo, I decided it was a good chance to finally get around to trying Drake. There were some hurdles along the way, but truthfully it was less painful than I was expecting. The end result is drake as a stand-in replacement for Gazebo, publishing to /joint_states,/imu, and subscribing to /cmd_vel for joint commands.
I’m back, and as promised we’re now doing a dive on LQR. I had to do a ton of scope adjustments for this post, as it was difficult trying to estimate what the “stopping point” should be. The initial vision for this segment also included an introduction to Control Barrier functions, Control-Lyapunov to be specific. However this would have required a primer on not only stability, but also on convergence and initial guesses.
I have (finally) gotten around to getting KIWI to balance in simulation. All in took me about an hour to write up the pid_controller and get it to stay upright. A little longer to nail down twist tracking via a /cmd_vel command. The core logic is remarkably simple, and I think serves as a great showcase of the “power of PID”. In the same way I think that people tend to overlook linear regression for their solutions as it’s not shiny enough, I really think people under-estimate how far a well-tuned PID can get you.
Alright, third post in a row where I switch to a new build system. I know it’s not a great look, but I swear this is the last time.
With this new model in Build123d, I’m finally settled on a library that seems to scale gracefully (roughly linearly) as assemblies accumulate complexity.
Why the switch?: Assemblies become unwieldy Previously I touched on the fluent programming style, and how it felt like a substantial change from the OOP style I’m used to.
In the last post, I mentioned I was having reservations about OpenScad, and its suitability as CAD software for KIWI. The primary source of these reservations was simply that after making only minor headway, each operation had become so tedious. Simple things like a bracket for a servo was becoming far too much trial and error for my liking. Initially, I thought I’d be able to simply take some measurements of my part before I begin modelling, save them as variables “servo_width, servo_height” or something similar, then use these dimensions to define our extrusions/cuts for the servo mounts.
In our last post, we blocked out a primitive 3d model of our inverted pendulum. From here, the next step is to get the basic mesh into Gazebo, to allow us to begin testing in simulation.
From Zero to Gazebo I suspect that everyone who has ever used ROS has had to deal with the horror of building/installing ROS. It can become a serious pain, and you wouldn’t believe the number of hours I’ve had to spend in the past dealing with missing/incorrect dependencies, or the source code refusing to compile.
I’ve been wanting to get better about writing updates more frequently than I am currently. One of the big reasons for taking so long between posts is that I’m absolutely horrible at judging where exactly I should ‘plant the flag’ in a project, and get to writing about it. This is most evident in ORNIS, where I literally spent six months writing code, and didn’t write a single word about it until it was essentially a mvp.
K.I.W.I, aka ‘Kinetic Inverted Wheeled Invention’ is the next project on our journey forwards. You may have noticed a trend in naming: I really like bacronyms, no matter how forced. This project will be a little more involved than QUAIL, as an inverted pendulum is inherently unstable, requiring us to do some analysis before getting into the design. This is one of my favorite parts of working on robots, there is something really satisfying about being able to do a bit of math to predict how the robot will behave.
