Changelog

• fix(variobot_mcu): more code cleanup
• fix(variobot_control): Use PID controllers without causing errors (#21)
• refactor: cleanup code
• fix: micro-ros stuff and wiring

I cleaned up the MCU code generated by Gemini quite a lot. There were a lot of small bugs and improvements that could be made here and there.

I designed a top plate for the robot where the Lidar will go. I am also temporarily putting the other 2 pcbs and wiring on this only rn.

I then got the PID controllers working with the simulation properly. The main thing I needed to figure out was how to disable them in the simulation without having to create an entirely separate parameters file for the controllers specifically for the simulation.
They need to be disabled for simulation, as the Gazebo hardware interface doesn’t simulate actual motors and just transfers whatever is sent to it as angular velocity for the wheels.

I then spent multiple hours wiring and screwing everything on the physical robot to get it working. I have the encoders giving accurate angular velocity and position data now.

Now I have to tune the motor PIDs and after that we should have the robot moving!

Changelog

• fix: micro-ros stuff and wiring

After a whole lot of debugging of the micro-ROS code, I have got it successfully working. It listens to motor commands and publishes the current wheel position (through quadrature encoders) on 2 different /joint_states ROS topics.

The work that’s left now:

1. Calibrating the encoder: how many ticks for 1 rotation
2. Wiring all 4 motors properly and creating the top layer of the robot that, in the future, would have the lidar, but for now would have the battery pack and 2 PCBs.
3. Fix wheel movement direction issues that may occur when I start to try to drive the robot.

Changelog

• feat: Initial implementation
• fix(CAD): 48mm_Mecanum_Wheel_N20_Motor_Coupling according to real-world constraints (#20)

After inhaling some plastic fumes, I have gotten the motors and mecanum wheels assembled on the robot.
I needed to edit the print slightly to make space for the screw of the coupling. I also switched the coupling’s screw from an M2 to an M3 to make it tighter.

I also guided Gemini to make the initial implementation of the microcontroller’s code. I have done this many times before and thus felt too lazy to do it myself.

Changelog

• feat: Got a motor moving
• ci(mcu): Add paths filter
• feat: updates
• feat: Init variobot_mcu
• ci(nix): Cache shell environment (#18)
• refactor: Remove redundant ament_lint dependencies from packages (#17)

I have started working on the microcontroller code for the real robot and, after a lot of work, finally got a single motor to move.
I am using this incredible dev-board, which I made a few months ago, as the main microcontroller: https://github.com/Amronos/ESP32-S3_6_Motor_Driver_IMU

The code is written in ESP-IDF, with Arduino as an ESP-IDF component, so that I can use this Arduino library for the DRV8912 motor driver IC.

I was facing a bunch of bugs and errors while using the library, so I forked it and got Gemini to read the datasheet and fix them for me. This worked incredibly well, and I saved a bunch of time.

I also created a new CI workflow that ensures that the ESP-IDF code builds properly.

Changelog

• fix: Speed and step input boxes not working
• ci: Add building, testing, prek, and renovatebot
• fix: Prek workflow
• fix: Missing .hpp headers on older ROS 2 distros
• ci(nix): Temporarily remove ROS 2 rolling

I fixed a few bugs as described in the above commits and created some (more like reused previously made ones) CI workflows.
I will now do the necessary things needed in order to get this package published in the ROS 2 apt repositories for all the current ROS 2 distributions.

Changelog

• build(ros-deps): Fix xacro (#14)
• build(nix): Switch to clangStdenv and add libsForQt5.qt5.qtwayland (#15)
• fix(variobot_control): mobility_system_controller topics and odom debug (#16)

I got the xacro PR merged successfully after testing several approaches to the issue at the request of xacro’s maintainer.

RQT tools had rendering issues on my system due to qtwayland not being installed. I added it to the project’s Nix flake.

I have an odometry debug topic from the Gazebo simulation that gives me the real values of the robot’s position and velocity. It wasn’t properly getting bridged to ROS. This was due to the topic name being incorrect in the bridge’s config, which I fixed.

I then worked on making the teleoperation experience of the robot a lot better by creating an RQT Teleop Plugin and remapping the mobility_system_controller’s topics to standard ones used throughout ROS.

Changelog

• feat: Initialize repository and create basic keyboard-based teleop

I spent a lot of time deciding on the framework I wanted to use for this tool. I initially wanted this to be a simple TUI in Rust, but it was pretty hard to get keyboard input detection working properly (it was almost impossible to find a cross-platform way to detect whether a key/multiple keys were pressed at the same time).
I then decided to just use ROS’s standard RQT framework for creating GUIs.

I have created the following features right now:

• Publishes geometry_msgs/msg/TwistStamped
• Drives linear.x, linear.y, and angular.z with the keyboard
• Continuously publishes the current command at 20 Hz
• Clears held motion keys when the window loses focus
• Lists available TwistStamped topics from the ROS graph and also allows manual topic entry
• Exposes per-axis speed and per-axis speed step controls in the GUI

Changelog

• feat(variobot_control and variobot_gz): Add 48mm_N20_Mecanum_Drive Mobility System (#13)

I worked hard on creating ROS 2 launch files for launching Gazbebo (the simulator) and ros2_controllers for core robot control.

On the simulation side of things, I worked on defining friction parameters for a mechanum wheel and creating a simulation world with the right plugins.
For control, I worked on PID control and defined parameters for the kinematic equations used by the controllers.

In the middle of doing all this, I encountered a weird bug with Xacro, which I fixed and made a PR for.

While I was working on all of this, my previously ordered Mecanum wheels arrived, and the base finished 3D printing.

Yay! It finally builds now! I had to disable the tests and examples as they will require a bit of patching to get them working.
As the package has now been successfully built, I have gone ahead and opened a draft PR to nixpkgs so that other people working with depthAI can leave some initial reviews while I fully test the package out and fix the tests and examples now building.
nixpkgs-review reported that everything is successfully building on all 4 Unix platforms.
Hopefully, by next devlog, I will get a few examples built, allowing me to use my depth camera and get something “tangible” as a devlog attachment.

I completed writing the robot description file of the mecanum base in SDF/URDF/Xacro. I have defined all the necessary joints, links, visuals, and collisions.

The only thing left is to define friction coefficients for the mecanum wheels, I will do that when I start working on the simulation.

I fixed a bunch of errors in building DepthAI with GCC 15. There are still so many left!
The main issue isn’t even the code; it’s the amount of time it takes for the library to build every time I make a change.
I also cleaned up the Nix code a ton to make it PR ready.

Lapse: https://lapse.hackclub.com/timelapse/4Kra3pPmvryx

I have started writing the robot description in SDF/URDF/Xacro for use in ROS and Gazebo.
I have successfully written and visualized (in RViz) the visual and collision geometry (the one in red) of the mecanum base.

I continued working on getting DepthAI packaged in nixpkgs.
I have fixed many build errors by patching the CMake and updating the dependencies of depthai-core in nixpkgs.
The main problem is that depthai-core assumes that internet access is present in the build phase, and it thus clones many dependencies from the internet. Nix doesn’t allow internet access during the build phase; due to this, I need to get the dependencies packaged directly in nixpkgs and patch the CMake accordingly.
Many errors still remain, but I am close.

Lapse: https://lapse.hackclub.com/timelapse/ZlbehmeoYnwq

More CI Updates

I moved from pre-commit to prek for all linting and formatting checks. prek is way faster and feels much better to use.
I also moved from dependabot to renovatebot for dependency updates, as renovatebot supports updates for a larger number of dependencies.

Changelog

• ci: Configure Renovate (#9)
• ci: Use prek for all linting and formatting (#7)

I added some extrusions on the sides for easily screwing on the top.

I am finally done redoing the lost work! This time, the final result is much better than before!
I spent quite a lot of time figuring out the proper placement of screw holes for the motors. Turns out that the last time I did this, I was orienting the screw holes incorrectly, causing the design to not be completely symmetrical.
The next step is to make a top cover and add the microcontroller board, SBC, and a Lidar.

I created a coupling to attach DFRobot’s 48mm Mecanum Wheel to an N20 motor.
Since I have already done this once before, it was pretty easy.
The coupling also includes a screw hole to make it extra tight on the motor.

I worked on porting the crude oil compatibility feature.
Turns out the only problem was that TFMG stores its generated recipes in recipe/ instead of the standard recipes/. I didn’t notice this for a long time and even went as far as trying to Mixin into the recipe generation code of TFMG.

I am now going to ship the new version of Create: Addon Compatibility, yay!
The next step is to backport a bunch of fixes to Minecraft 1.20.1.

I have been working on and off on updating this mod to Minecraft 1.21.1 for a while now.
Since my exams are over now, I have decided to speedrun this update.
I spent the past hour looking through what’s done and what is left to do, and came up with a list of stuff that’s left to be ported to Minecraft 1.21.1.

I should have added this project to Flavortown way earlier, but I completely forgot.

For the past few weeks/months, my contributions have focused on adding ROS tooling to nixpkgs.
I have been working on adding various extensions for the colcon package. colcon is a build tool for ROS packages.
ROS, btw, stands for Robot Operating System; you should be able to find plenty about it by searching for it online.

I have currently made PRs for adding 3 colcon extensions.
I have made a 4th PR for updating colcon to its latest version. You can find more details on the PR page.

I have also been working on packaging the latest versions of depthai for Nixpkgs; till now, this has mostly involved cleaning up and trying to understand this incomplete PR.

I also spend some time reviewing PRs for packages I use.

Since I am redoing 20 hours of my work, I decided to do things more properly now. I am now going to make multiple FreeCAD files instead of breaking FreeCAD by trying to fit all my assemblies into one file.
Instead of just downloading the motor clamp’s model from the internet, I have now gone ahead and remodelled it by myself in FreeCAD. I did this because the original model wasn’t centred properly, and by remaking it in FreeCAD, I can now modify it when needed in the future.
I probably spent more time mirroring the left motor clamp into a right motor clamp than I spent making the left motor clamp, lol. I didn’t have any prior practice in doing stuff like this. I learnt about making clones, links, and mirrors, yay!

I have finally started working on Zenoh support in Micro-ROS, the thing I started this project for. rmw_zenoh_pico had some patches for zenoh-pico to make it work better with Micro-ROS (rmw_zenoh_pico currently only has support for running Zenoh with Micro-ROS on Linux, not on microcontrollers). They didn’t work for the latest zenoh-pico versions and needed some cleanup. I did the necessary changes, and now zenoh-pico is building just fine with colcon for ESP-IDF.
rmw_zenoh_pico is currently failing as it was originally made to work on ROS 2 Jazzy, not Rolling. I will fix that in the next devlog.

I made many improvements to the GitHub Actions CI and README.md of the micro_ros_espidf_component to make it easier for me to test my changes. PR: https://github.com/micro-ROS/micro_ros_espidf_component/pull/324

I then worked on getting the component to properly work with ESP-IDF v5.5. I took most of my changes from another PR and retargeted them to rolling. My PR: https://github.com/micro-ROS/micro_ros_espidf_component/pull/325

I got the ROS 2 Rolling builds fixed and made a PR.
Look at the screenshot below or the PR for more details.

I have started by trying to build and run the micro_ros_espidf_component default examples using rmw_microxrcedds.
I first created a flake.nix for the project (something which I do for all my projects). I used nixpkgs-esp-dev for this.
When attempting to build the first example in ROS2 Rolling, I encountered an error. Turns out that right now Micro-ROS is not working for rolling due to a new package added to rcl_logging. I decided to address this issue as well.

I spent a lot of time improving the Nix setup, switching to a more efficient cache for the ROS packages and significantly enhancing direnv support by utilising ros-direnv.
I also accidentally rmed the robot’s CAD design, and therefore deleted like 20 hours of my work. I will have to redesign it; hopefully, it will take less time than before and be better as well.

1. Added formatting and linting rules through Prettier, ESLint, and pre-commit.
2. Created some GitHub CI workflows that run linting, builds, and tests.
3. Configured Dependabot to automatically raise PRs for updating GitHub Actions, pnpm, and Cargo dependencies.

Made the UI better and fixed the ghost scrollbar issue. It was caused by a bug in Blockly that occurs when using Tailwind CSS.
All of this is going to change a lot, this is just something basic to get started with.

I added Tailwind CSS and shadcn/ui to the project, then cleaned up the code a bit by deleting CSS that is no longer needed and moving CSS for specific components to their definitions, instead of having it defined globally. Some UI bugs have happened because of that, but I am working on fixing it.

To implement block-coding, I am going to use Blockly.
I first ported the Blockly sample app into Svelte and tried to get it functioning with Tauri.
The web version of the app looked fine and worked as intended, but for some reason, when run natively, everything was squished to a corner, causing it to appear glitched and making the app unusable.
I spent a lot of time trying to debug this issue. Turns out the problem was a bug in Tauri that caused incorrect DPI scaling with Wayland. To fix it, I temporarily got the app to use X11 by setting export GDK_BACKEND=x11.

1. I experimented with different theia plugins for a bit, there are way too many of them.
2. I tried to make my own Theia plugin, but implementing custom functionality proved to be too difficult.
3. I have now decided to just make my own app in Tauri; it is not required for me to have a text editor and other such things in it, as users can use something else instead for code editing and use Sprocket for its unique features.

Instead of just having a plate at the front, which could be swapped. I decided that it would be better to make the entire base of the robot that controls movement swappable. This would allow for multiple types of movement systems, both wheel-based and legged.
For this devlog, I mainly spent time creating a new base for mecanum drive, calibrating the motor’s position, and creating a coupling to attach the mecanum wheel to the motor.
During this, I learnt more about creating sub-assemblies and groups for models in FreeCAD and some of the quirks associated with those features.

I was so invested that I forgot to devlog :(.

I went ahead and created the GitHub repository that will contain all of the robot’s code, documentation, CAD files, and other relevant materials. Here’s a list of what I did and the difficulties I faced:

1. Created GitHub action workflows that build and test the robot’s code. There are two workflows, one that uses APT to install dependencies and the other that uses Nix. - Required a lot of testing and tweaking to get them working perfectly as I wanted.
2. Created an installation guide for installing/building the code. There are two ways: one is to use APT on Ubuntu 24.04, and the other (the one I love) is to use Nix to quickly install everything in one command on basically any OS.
3. Created ROS 2 launch files that allow for launching a basic RViz window that visualizes the robot description. This would be helpful while 3D modelling the robot. - I created these in yaml (much better), unlike how I did it with my past projects, where I used Python.
4. Wrote configurations for pre-commit.
5. Wrote the flake.nix file, I pretty much used ros2nix to generate it alongside a shell.nix. I then merged them into a single file and cleaned the code up a bit.
6. Added patches for joint_state_publisher into my flake.nix to allow joint_state_publisher to support infinite revolute joints defined in SDF files better, these are present in the APT installation method by using vcs to clone a .repos file.

I decided to use the Theia platform to make this project.
I spent a large amount of time shifting the hello-world example from the documentation to use pnpm, and I also created a flake.nix for the project. I got the browser IDE working, but even after a lot of debugging, I couldn’t get the Electron one to start.

I have decided to put the wheels inside the robot instead of outside so that they are protected, and the robot looks more aesthetically pleasing.
To support multiple drive modes, the plan is to have a system where you can change the front plate of the robot to accommodate different types of steering at the front (will probably support only Ackermann and normal for now). One of the plates will have two circular holes for the two steerable wheels, and another will have two rectangular holes for non-steerable wheels (in differential and mecanum drive). This system will also include different motors and mounts that will steer/rotate the wheels and keep them in place.