Changelog

• feat(gz): Make RPLidar work in simulation
• fix(mcu): Update dependencies and fix PWM parsing (#39)
• feat: Add RPLidar_A1_M8_Holder

1. All 4 motors now work properly.
2. I added an RPLidar holder/connector for the top base and got the RPLidar properly working in simulation.

I am now going to work on getting full navigation working in simulation. There sadly isn’t enough time left to get it working on the real robot, also.

Description of the image below: The left shows the simulation world (Gazebo) while the right is essentially what the robot thinks is around it.

Changelog

• build(variobot_mcu): Update dependencies.lock (#38)
• fix(nix): Add mesa to fix rviz2 runtime errors (#35)

I am just gonna go ahead and explain the current hardware situation of the project with this devlog.

1. The power mux of the PCB stopped working for some reason. I had to bypass it by cutting a trace in the PCB and powering its 5V and 3.3V separately from the buck converter PCB.
2. This caused the USB port of the PCB to no longer give any power to it, leading my laptop to give the error connect-debounce failed and not detect the ESP32. I had to then forego the built-in USB port of the PCB and instead attach a USB to UART converter to the UART pins of the ESP32.
3. After fixing all of this, I still had problems with the motors. For some reason, even after directly soldering the motors’ wires to the PCB, only 3 motors are rotating, and the fourth one doesn’t. I am still trying to solve this. It may be a battery problem, so I have put my batteries on charge.

Changelog

• build(variobot_mcu): Update dependencies in idf_component.yml (#33)
• ci(prek): Cache nix shell environment (#32)
• docs: Update AGENTS.md (#31)
• docs: Update AGENTS.md (#30)
• ci(renovatebot): Update configuration for faster dependency updates (#23)

Some random CI-related stuff, check the individual commits.

Changelog

• feat: Create variobot_mcu and variobot packages for real robot (#19)

I have completed the code to make the real robot work properly.
I had to fix many issues with memory allocation on the MCU, which prevented it from receiving joint commands from the ros2_control topic-based hardware interface.
I haven’t tuned the PID constants yet and will do so later.

The main problem I am facing is that I soldered the absolute worst of screw terminals onto my PCB; the screws in them don’t even turn, half the time electricity doesn’t conduct at all, and wires keep coming out.
This has cost me multiple hours. This is also the reason for only 2 wheels moving in the video below.
I am now going to desolder the screw terminals and solder the wires directly. This will be done later on though, for now I am going to focus on getting autonomous navigation with a lidar working on the robot in simulation.

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.