Final Pi Wars 2024 Blog Entry

It is late in the evening the night before the blogging deadline. So this is my final pre-judging blog entry. I am on holiday in an apartment with no TV. So I had no way to connect my robot to a screen other than to try and get it onto a WiFi connection and VNC onto it from my son's laptop (which I am also using to write this last blog entry). Without a screen to plug into the robot, I decided to try an idea I had but never tested before. I changed the mobile hotspot name on my mobile phone to the same network SID and password as the Makespace network. I then booted up the robot and it connected as it already had the Makespace network set up from working on it there previously. Next I connected the laptop to my hotspot. I just needed to know the IP address the Pi had been allocated. I could not ping it using <robotname>.local so I had to guess the IP. I checked what IP the laptop had on the mobile hotspot, and as the Pi had connected before the laptop I guessed it might have an IP address one bit lower that the laptop. This proved to be the case, and I was able to VNC onto the Pi and work on my code! 

Mostly progress has been in diagnosing why none of my I2C devices were working. After much head scratching I found a note on the Pimoroni website that the silk screen for the 8x8 TOF sensor I was using was incorrect on early boards, and it actually should say x29. The same I2C address as my IMU is using! The IMU can be configured to use x28, but that needs a soldering iron which I don't have with me this week. But at least I could confirm both sensors work when only one is plugged in at a time. I can work with that.

Next I discovered the 8x8 sensor example in MicroPython uses Numpy which is not in the Pimoroni Motor2040 firmware. Ulab Numpy is in the firmware for their Unicorn boards, so I was able to test with that. But in the process of flashing the firmware this wiped the filesystem on the Motor2040 with all my code on it! Thankfully I back things up pretty often. I had all the files on the Pi SD Card, and was able to restore them all apart from one. I managed to download that from my NAS at home over the internet. So everything is back in place. Unfortunately the Unicorn firmware does not contain the motor and encoder classes I need. A cry for help to Pimoroni software expert Gadgetoid resulted in him building a custom MicroPython firmware build which includes the ulab Numpy modules. Now that is customer service! He warned me it will wipe my filesystem, but as I've already been there I am good to try it. Except I had a blog to finish, so I've not done any more coding yet. Plus I am here to relax, after all!

My Robot is Hardware Complete!

 Finally I have everything assembled and wired up!

I realised my directly soldered wires were prone to snapping off the PCBs, and I needed headers to plug my servo motors into. Just having a pair of signal wires coming of the Motor2040 board was not going to cut it.

My solution was to design some additional brackets to bolt an I2C distribution board onto. A PCB I designed after Pi Wars 2019 but had never actually used on a robot until now.

This board has 4 pin sockets for I2C breakouts, along with some 5 pin sockets intended for the Pimoroni Breakout Garden boards which use a 5th pin for some other signal functions. This 5th pin for each of these sockets is connected to a header on my board. In a flash of inspiration I realised I could cut the power track to these 5 pin sockets, and by sacrificing 2 of these 5 pin outlets I could wire one of the spare 'signal' pins to V+ from the motor supply 6V line and one to GND. Then I could feed the servo supply voltage, GND and the RX and TX signals into this signal header and supply each of the remaining 5 pin sockets with high current power, GND and the signal line needed for the two servos. An extended custom lead crimping session saw the 2 servos converted to custom 5 pin JSH-PH plugs. A custom lead to supply the power and signal inputs to the board, and my servos were connected!

All that remained was to connect up the I2C input to the Motor2040 board and plug in my sensor and IMU and I was done. It was late in the evening the night before my week long family holiday and my robot was read to take away and maybe do some coding on in the evenings. Then the QWIIC socket broke off the Motor2040 board as I plugged in the final connector. I realised I it was too late to take everything apart again, and took the sensible option of going to bed to sleep on the problem.

In the morning, alongside final packing I managed to take apart the robot to remove the Motor2040 board. It has headers which can take a Breakout Garden socket (too large for the space I had) but also due to an extra GND pin on the header, could take a 4 pin JST-XH socket. Genius on the part of Pimoroni, or just good luck? Either way I was able to solder on a socket and crimp up one more custom lead and pack it all in my bag to take on holiday.

Pulling it all together!

 A few more late nights working to assemble my robot. Thankfully the CAD model went together pretty well, with just some minor filing of parts to make them fit together well. I used hot melt threaded inserts in several places which makes it very quick to assemble (and more importantly take apart) when things go wrong.

Here you can see the lower chassis with the Motor2040 board mounted at the front with the battery tray in the middle between the wheels (the battery slides into this). The UBEC sits on top of the middle battery and the USB-C battery pack is on the back, held in place with velcro straps.

The 3D printed Raspberry Pi 5 case sits on top, screwed onto a pair of bars. The screws come up from below and hold the case together, so need to be fitted before the bars are screwed down onto the robot. You can just see the Motor2040 board below the Pi here with an IMU plugged into the QWIIC socket. It was at this point that things started to go wrong. See the yellow wire which has snapped off the IMU board where I had soldered it straight to the PCB. Then I realised my Motor2040 board has no servo headers. I have nowhere to plug in the servos on my grabber!

Some frantic study of the Motor2040 board documentation and schematic revealed no broken out pins from the GPIO. There were some analogue inputs, but it turns out these are for a seperate ADC chip and not the RP2040. Then I spotted the UART pins labelled RX and TX on the board. Looking at the schematic these are directly connected to a pair of GPIOs on the RP2040, and I was not using them for serial communications as I am using the USB socket for that! I clipped my PicoScope probe ground to the USB plug (the only accessible GND point with my board mounted) and found a simple servo driving example for MicroPython. Setting the RX and TX pins as the 'servo outputs' in the example I was able to confirm the PWM output on these pins on the PicoScope. The day was saved!