Finally some significant progress with my code

On our family holiday to Dorset where we have gone to hunt for fossils on the Jurassic Coast most years since our children were born. By coincidence I find myself working on my robot in the same holiday let conservatory where I worked on my first ever Pi Wars robot back in 2019.

My first objective is to master rotary encoders in MicroPython. It took me a while to get my head around the examples provided for the Motor2040 board by Pimoroni. One example shows how to control velocity of a motor using PID control to adjust the measured velocity from the encoder to reach a desired target velocity. Another example shows how all four motors can be controlled, but this uses an array of motors, an array of encoder classes and an array of PID controllers. It all gets rather complicated and hard to follow. So I refactored these examples to create a PID controlled encoder+motor class. This massively simplifies the code once the constructor has been passed all the complicated parameters needed to assign an available PIO and state machine. The magic happens inside this class, but all you need to do in your program is call the setVelocity method and the PID controller adjusts the PWM duty cycle of the motor driver to get the motor rotating at that velocity by using the encoder in a feedback loop. Velocity control is great because now all motors can easily be set to run at the same speed regardless of small mechanical differences between them and the load due to robot mass or forces due to driving up or down a slope. Meanwhile the code is kept really simple. 

There is another advantage that comes from using PID control, in that you set a target velocity and the PID controller takes the motor to that velocity in a progressive way. So there is some built in dampening which smooths out sudden changes in requested velocity from the driver. This protects the motor gear boxes from excessive strain which can otherwise strip the teeth from cogs in the gearboxes. If you suddenly slam the power joystick from full power forwards to full power reverse, the PID controller starts to adjust the motor power to comply, but does not immediately give the motor full reverse power. It backs off the power a little, measures the effect on the velocity by reading the encoders and re-adjusts accordingly. The driving is still really responsive, but the motors do not break under the strain.

On to the second objective: mechanum driving. I was disappointed to find that the examples for the Motor2040 just set motor speeds to drift left or right, or move forwards or backwards. No omnidirectional drifting. So I looked for information on the internet and eventually found this excellent article with code examples (in C). I managed to reimplement the equations in MicroPython, finding some bugs in their example which had me scratching my head for a few days until I got it all working. Some of my problems where due to me mixing up my motors, and some due to a copy and paste error in the article where they use the wrong variable to adjust for turn input. Now I could move my robot in any direction using one joystick on my controller, while rotating the robot on the spot using the left-right channel from the other joystick. I think this ability to move in 2 dimensions while independently rotating to face in another direction will be really handy in Pi-Noon!

The final piece of the puzzle was to measure the robot heading, so that I could implement field oriented driving. This is where the robot moves in directions relative to the driver position/arena, regardless of which direction it is actually facing. To put it another way, up on the joystick moves the robot up the arena (away from you) and down moves it back towards you. You can spin the robot around to face in any direction and it still moves away/towards you when you push up or down on the joystick. The magic of mechanum wheels in conjunction with matching wheel velocities due to the velocity controlled encoder motor driving, allowing the robot to move in any direction while pointing in any unrelated direction. The robot just needs to be able to measure it's heading, which requires an IMU. Luckily I had been learning how to use the BNO01 IMU chips on my other small robot project (see my earlier blog entry for Piwars 2024). This IMU chip has on-board sensor fusion, where it combines the 3 axis compass, 3 axis accelerometer and 3 axis gyro readings to calculate a 3 dimensional orientation vector for the robot. Using this you can determine which direction the robot is facing at any point in time, and subtract that angle from the direction the mechanum drive equations are being given to move the robot. This provides field oriented driving, which should be very useful in several of the challenges.

A New Idea to Rescue My Pi Wars Entry

So I need a new idea for my Pi Wars robot. Something small that will be quick to build. I am a big fan of small robots, although it can be challenging to fit everything in the limited space. For me the value of Pi Wars is that it pushes me to learn and advance. I've never really enjoyed the competitive aspect of things, but I really enjoy pushing myself to improve. So I started thinking about building on the ideas I have been working on using a Raspberry Pi communicating to a MicroPython board with the Pimoroni Yukon, but shrinking things down a little. I have wanted to build a robot with Mechanum wheels for a while now. Mechanum wheels have little rollers mounted at a 45 degree angle all around them, and by driving them in different directions it is possible to make a robot move in any direction without turning the body of the robot to face in that direction. I had all the parts I needed in my 'things I bought in Pimoroni sales but have not had time to use yet' boxes. So I swapped the Yukon board for the smaller Motor2040 board which supports 4 independently controllable encoder motors. Encoder motors are another thing on the long list of topics I have wanted to explore but hadn't found the time yet. So I laser cut a pair of acrylic plates with mounting holes for motors, a Raspberry Pi and a Pimoroni Motor2040 board. I already had some motor mounting brackets I had 3D printed on the Makespace resin printer. 

I have a robot! Albeit a test chassis to develop some code on rather than a final Pi Wars entry. I had been designing a case for the new Raspberry Pi 5, so I just mounted that on the chassis. Another step into new learning as the power requirements for the Pi 5 for mobile robotics raise more problems I wanted to solve. The Raspberry Pi 5 also requires running the Bookworm version of Raspberry Pi OS, which means python libraries not included in the apt packaging system can only be installed into a virtual environment. So this would push me to solve the problems of configuring my robot code to run on boot inside a virtual environment. So I will be learning a lot! Now I just need to find some time to work on the code.

Mentoring a Young Persons Team

Mentoring young persons in PiWars has by far been the most rewarding aspect of the competition over the past 5 years. This year is the 7th young persons team I have mentored through the competition. They have pretty much taken up all my time for robotics during this competition so far, hence the lack of progress and updates on my own robot. Time is always very limited with young persons teams. In the past I have always mentored through running after school robotics clubs in local schools. School safe guarding rules generally mean I only get a hour a week with the teams, and have no way to communicate with them outside of these club sessions. This really restricts what I can do with them. I literally get around 20 hours with them over the entire span of the competition, to help them design, build and code a robot. The exception to this has been the monthly Robot Club run by Brian Corteil at Cambridge Makespace, where I have managed to arrange with the parents of some of the children in my teams to bring their children along and give us some more precious time to work on their robots.

This year is a little different as I was unable to get an after school club organised due to staff leaving and schools closing/merging where I had previously made contacts with staff. But then my daughter entered with a school friend giving me a team to mentor who I could work with outside of school. This has made a huge difference both in terms of what we can do, and in how much of my time they have taken up!

Here they are at Makespace where we went to the Robot Club and built this robot in a day!

It was based on the guts of a robot from last year (my daughter was also on that team). We designed and laser cut a base plate with holes to mount all the electronics and batteries, then mounted everything with machine screws. This is just a working development platform to give them something to start working on the code. We looked at my collection of sensor electronics, and they decided to start with a camera as they plan to try and tackle some of the challenges autonomously. This brings me to the second huge benefit of mentoring young people. They teach you so much! I have never done any image recognition before. I always wanted to explore this area, but never found the time until now. Suddenly I am up to my neck in their Open CV code, trying to understand it, help them debug it and advising them on approaches to problem solving. They have some great ideas, slicing images into vertical strips, calculating average brightness to determine where in the frame the line is for the line following for the Lava Palava challenge. Detecting barrels by colour, and recognising Zombies. Even if I never get the time to work on my own robot for this competition, they have pushed my knowledge far into new areas. It has been great!

Size Matters

Everything has gone wrong! I've been trying to find a way to make my robot narrow enough to fit inside the Pi Wars maximum allowed robot dimensions. The problem is that the motors I planned to use along with the tracked wheel assemblies are too wide. I was planning on a belt drive mechanism so one motor could drive both tracks on one side of the robot, and the rocker bogie pivot could be the axis of the motor. 

But with these motors positioned back to back there is only going to be room for the tracks within the width if I design a two stage belt system so that the belts driving the tracks are in line with the motor body. 

Another idea I played with was to use 45 degree angle bevelled gears to enable me to mount the motors at 90 degrees to the pivot axis. This would enable me to mount the motors so their bodies were oriented along the length of the robot, rather than the width. I could position the motors closer together this way and get the robot to fit inside the width limit for the competition.

At this point I realised something more significant which had been staring me in the face all along. Placing two of my track assemblies one in front of the other, there is no way to fit them within the length limit for Pi Wars! There would not be enough clearance between them to prevent the front tracks snagging on the rear tracks in the rocker bogie arrangement where each track can freely pivot around it's own axis. I wondered if I could fit them offset from each other, placing the front pair closer together than the rear pair? Then the front pair could overlap with the rear pair. But this consumed too much width again. It was time to accept this was not going to work. So now I need a completely new idea!

Pimoroni Yukon - Interfacing a Raspberry Pi to an Micro-controller running Micropython

I've been working on testing some new pre-release modular robotics hardware from Pimoroni. The Yukon board.

I am planning to build my Pi Wars robot around this, which means I need a way to talk to a Micro-python board from a Raspberry Pi. It would be really neat to be able to do this over the USB lead. This board is not a HAT, so needs powering via USB. I thought it would be great to use the USB port on the Pi to power the Yukon board, and for communication between the two.

This opened up a rabbit hole of learning. First to work out how to send data over USB serial from Python on the Pi, and how to read the data in Micropython on a connected micro-controller. I discovered that certain byte values get changed (line ending conversions) and that some kill the micro-python program (the same way pressing the 'stop' button in the Thonny IDE does). I learned how to disable this feature in micropython, and then how difficult it is to get control back when main.py auto-runs on power up and turns off the ability of the IDE to intercept and stop the program!

To avoid these problems I decided to hex encode each byte I wanted to send, so it is sent as a pair of bytes represented by ASCII characters which are safe to send. This topic raised some interest on social media, so I cleaned up the example and made it run on a vanilla Raspberry Pi Pico board. You can find the code on github.com/Footleg/rpi-pico/tree/main/micropython/serial_comms_over_usb

Developing a small robot as a code test platform

I have learned from previous experience in the Pi Wars robotics competition how important it is to get testing code early. So rather than working on the physical build of my robot, I have been working on programming robotics code around areas which are new to me. I was already developing a small robot for STEM outreach events, based around the Inventor HAT mini board from Pimoroni.

This board supports encoder motors, something I have not developed code for previously. I wanted more feedback from my robot to better control it autonomously. Encoders enable you to read the speed of rotation of your motors, and count how many rotations they have made. This makes speed control possible, and distance travelled to be tracked. All my previous robots have been manual control only, so this was all new for me. I also added and IMU, which would enable measuring the orientation of the robot. This makes accurate turns possible.

The triangular tracked robot I was already developing is a little too small for Pi Wars, but the code developed on it should be portable to my competition robot once I have that built. I wrote a hardware abstraction interface so that my code talks to an interface which is independent of the specific hardware it is running on. I converted my manual control robot program from my STEM event robots to use the interface, creating this Universal Robot project on Github.

Pi Wars 2024 - The Beginning

Hard to believe it is almost 5 years since my last Pi Wars blog entry. Since I last entered as a competitor in 2019, I have mentored school teams each year the competition has run, and so decided not to enter myself after discovering just how much work that was in 2019! This year my plans to run another after school robotics club fell through when the Computer Science teacher I worked with last time left the school. So I thought I should enter again myself. I've built quite a few robots over the years since my last time, so I've been promoted to the 'veterans' category this time around. I just need a name and an idea now!

With the entry deadline fast approaching, I decided the most visually exciting robot I could think of would use 4 RC tracks in the place of wheels on a 4 'wheeled' rocker-bogie suspension. I've had these tracks in the parts box for a while, intending to build a robot out of them.

So that's the idea. In keeping with the theme 'Disaster Zone', I needed a robot name. So I decided on:

Team name: Footleg Robotics

Robot name: Ragnarök Rescue

Just as I had decided to enter, my daughter told me she was going to enter as a young person team with a school friend, and wanted me to be their team mentor. So here I am again, entering myself, and mentoring a young persons team at the same time. Will I never learn?