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

• 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(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.

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 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.

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.

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 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.

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 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.