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.
This post is going to be more “stream of consciousness” than my other writings. This is noteworthy as I haven’t really felt the need to write about something that wasn’t a presentation of some form. Up to this point, all of my posts have been of form “Look at this milestone in this project” or “Here is a trick I figured out” and I’ve enjoyed having the value of my writing derived from the milestone itself.
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 brought up the ros.el emacs package a number of times now, as it has become a package that I use multiple times a day. A little while ago, I had the idea to see if I could add a debugger function, to take advantage of the emacs-gdb functionality.
The implementation took me down a rabbit hole of learning about how tramp handles remote connections, as well as how gdb links shared librarys.
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.
It has been around a year since I moved to working in ROS2 full-time. Much like the Post about using GDB in ROS1, I wanted to make a reference for myself, and potentially anyone else, for creating a decent debugging workflow for ROS2. Unlike my ROS1 guide, I will be covering launch files here, as information regarding debugging with ROS2 is a bit sparse.
Step 1: Compile with debug flags $ colcon build [flags] --cmake-args -DCMAKE_BUILD_TYPE=RelWithDebInfo You don’t need to build your whole workspace with debug flags, just the package you want to debug.
In the last post, I mentioned that the ros.el emacs package had been on my radar. I finally got around to giving it a try a few days ago, and it has quickly become a staple of my workflow (Highest praise possible!).
I had to add some dependencies in my packages.el:
;; `ros.el' depends on `with-shell-interpreter' among other packages ;; See: https://github.com/DerBeutlin/ros.el/blob/master/Cask (package! with-shell-interpreter) (package! string-inflection) (package! ros :recipe (:host github :repo "DerBeutlin/ros.
I’ve been developing on robots with Emacs for a few years now, and I thought it may be beneficial for me to do a write-up of some of the tricks I’ve learned. The usefulness of the following won’t be limited to robotics, nor only to those who use Emacs, as I’m sure the frustrations of developing on a remote machine, inside a container are transcendent. Given that I have wound up revisiting the ROS and GDB page a good number of times to jog my memory, I suspect that this topic will be as useful.
