Pi Wars Robot Electrical Design

The fundamental components I needed for my raspberry Pi based robot were a Raspberry Pi board, a servo driver board and dual motor controllers. On top of this there would be various sensors and a camera. I decided early on I wanted some sort of display and buttons to control a menu system on the display to set the various modes of the robot for different challenges. The display I chose was the HyperPixel 4.0 touch screen display which Pimoroni had just released. This would give me a beautiful full colour display and the touch screen would enable me to use the screen itself to select menu items.

The next decision was how to power the robot. I had learned from other people of the problems with using a power source for the Pi shared with the motors. If the motors draw too much power then the supply to the Pi can dip, causing reboots or crashes. One way to avoid these problems is to provide a completely separate power supplies to the Pi and to the motors/servos. But this is not necessary provided the power supply can provide enough power for all components at their full loads. I decided to use a high discharge current LiPo battery. I planned to use UBECs (Universal Battery Eliminator Circuit) to eliminate the need for different battery voltages. I could supply 5V to the Raspberry Pi using one UBEC, and 6V to my motors and servos using a second UBEC. I already had experience using the cheap Hobbywing 3A 6V/5V switch mode UBEC for robots. These are readily available online (try eBay). I tend to buy 10 at a time from China so I have a stock of them in my parts box ready for projects.

Early prototype wiring to test the servo and motor drivers, powered by a LiPo battery and two UBECs

For the motor drivers, you need to choose some which can supply the voltage your motors require and handle the maximum current which the motors can pull. My robot was using 6V rated micro metal gearmotors with 1:50 ratio gear boxes. According to the listing on the Pimoroni website these have a stall current of 770mA. Stall current is the current the motors will draw if they are fully powered and the shaft is prevented from turning. Typically this can happen if the robot is trying to drive up too steep a slope or into an obstacle which prevents it moving, so all motors could draw this current at the same time. My design had them wired up as 2 pairs of 3 motors in parallel, so I needed a 6V supply to the motors and a maximum stall current of 3 x 770mA = 2.3A. I already had a pair of Adafruit DRV8871 motor driver breakout boards, capable of supplying up to 3.6A per board. The UBEC circuit can supply a steady 3A at 6V so I would need a UBEC per motor driver. I built a test circuit for a single motor and found it did not work. Reading the specifications of the motor driver board again I realised if needed a minimum of 6.5V input voltage. So my UBEC regulating the voltage down to 6V would not work.

Some discussions on Twitter led me to the decision to drive the motors directly off the battery voltage. This could be as high as 8.2V when fully charged, but seeing as the software would limit the motor power using PWM anyway I could set a limit to prevent the motors getting the full power of the battery. They would still be getting peaks of more than 6V during the on-cycle of the PWM signal, but the motors are not such sensitive components that this should be a problem, and I had been advised that these motors could be over-driven safely at these voltages. At a higher voltage I would have more speed, more torque but also a higher stall current. But I would not need a UBEC per motor driver now. The driver boards I had can supply up to 45V to motors, and up to 3.6A so this should work fine.

Next I looked up the HyperPixel touch screen board on the excellent pinout.xyz website to find out which GPIO pins it used on the Raspberry Pi. The answer turned out to be all of them! But it did break out the software i2c bus so I still had the option to control i2c hardware from a Pi using this screen. I was already planning to drive the servos using an Adafruit 16 channel 12 bit PWM servo driver board which is an i2c device, so that should work. But I had no GPIO outputs available on the Pi to drive the motor driver boards. I discussed some options with Brian Corteil of Coretec Robotics at one of the monthly robot club sessions he organises at Cambridge Makespace. These included the following:

• Use an Arduino to provide some additional PWM outputs
• Use a second Raspberry Pi to connect sensors and drive the motors
• Use an i2c GPIO extender breakout board

Then it occurred to me that what I needed to drive my motors were digital PWM outputs, and this is exactly what the 16 channel PWM board I was planning to use to drive my steering servos had in abundance. I built a test circuit on a breadboard to experiment with this. I made a mistake thinking I would drive the servos at 6V, because while the motor driver boards can drive motors at up to 45V, the logic inputs to the board are only rated up to 5.5V. My 6V PWM output damaged one of the boards and I had to replace it. My steering servos were plenty fast enough and strong enough using a 5V supply, so I switched the UBEC supplying power to the servos back to 5V.

The last piece of the puzzle was how to drive multiple laser time of flight distance sensors over i2c when the boards I had chosen (the VL53L1X breakout by Pimoroni) had a fixed address. I read it is possible to switch this address on power up, but this presumably required powering up each sensor board in turn, and that would require more digital outputs which I did not have. An easier solution was to use an i2c board which provides switchable i2c buses, and I chose the TCA9548A I2C MULTIPLEXER from Adafruit.

To connect up all my i2c devices, and supply power to the Raspberry Pi, I made a small power and i2c bus breakout board using strip-board. I built this with 5 pin connectors to match the Adafruit PWM board and Pimoroni range of i2c breakouts which all have 5 pin headers including an interrupt line.

i2c and power bus board

The UBEC supplying power to the Pi and screen was connected to this, and power supplied over the i2c V+ and GND lines to all components. You can see the complete wiring diagram below.

The electrical design for my robot (click to see larger version)

In order to mount the display on top of the robot, I soldered up a right angle GPIO connector using a Pimoroni Pico HAT Hacker board which enabled me to connect the display to the Raspberry Pi using a ribbon cable. I soldered a second 4 wire ribbon cable onto this connector to supply power to both the Pi and the display, and to connect the software i2c bus to my breakout bus board. I was relieved when I connected this all up and saw it working as intended.

Working display and Pi powered via the i2c bus and power breakout board

The next challenge was going to be how to fit all this electrical hardware and connecting wiring into my robot chassis.

Designing the Main Chassis and Complete Rocker Bogie Assembly

Having built a pair of working prototype rocker bogie wheel assemblies, I turned my attention to the main body of the rover. Initially I just used a simple box shape, keeping the front of the chassis well back from the front steerable wheels to avoid collisions. The rear of the chassis had to overlap the area where the rear steerable wheels servo links came under the body in order to fit the top pivot for the linking bar assembly. But I now had a basic chassis design which enabled me to complete my CAD model and see a working mechanical model of the full rocker bogie suspension.

A rendered animation of the rocker bogie suspension

To avoid the rear wheel steering links colliding with the underside of the body, I modified the box so that the bottom was shorter than the total length of the body. This gave the servo steering links more clearance where they passed under the body. I made the front section of the body just long enough to fit in the Raspberry Pi 3 plus two additional support pillars to provide a second pair of holes for the main pivot bolts to pass through. This gave a more rigid main pivot axis assembly than if the bolts just passed through one piece of 3mm sheet material on each side.

I mounted the Raspberry Pi 3 board in the box, with the USB and Ethernet ports poking through a cut out. This was technically the first Raspberry Pi case I had ever designed. The rear of the box still needed to extend far enough back to support the linking bar assembly on the top. To allow this, the base of the box stepped up to a lesser depth at the rear.

The body design with a step up on the underside at the rear 

to allow the steering links to pass underneath the chassis

At this stage I was still pondering over how to build the linking bar assembly. I had modelled a bracket to hold the horizontal linking bar, which I was going to have to 3D print. I also needed to solve how to attach fittings to the ends of the cylindrical bar to link to the rocker arms. At about this time, somebody posted a picture of the NASA Mars Curiosity rover in a lab in reply to one of my progress posts on Twitter.

 Image Credit: NASA/JPL-Caltech

Up to this point I had not realised how large the real Mars Curiosity rover was! But I also noticed the linking bar was a flat bar, not a metal rod as I had modelled based on the JPL educational scale model project which inspired me to design a Pi Wars sized version of my own. That looked a lot easier to build. The picture also gave me another revelation. I did not need to mount the bar on the back of my rover. It could go in front of the main pivot axis of the body. This gave me more room as the body already extended further out in that direction to accommodate the Raspberry Pi. It also better distributed the weight of the body between the horizontal pivot axis and the top mounting point for the linking bar.

I now had a complete design worth building a prototype of. I laser cut it all from 3mm plywood because this was cheaper than plastic, easier to modify with small tools after cutting the pieces and I could re-purpose all the off-cuts and waste pieces as kindling to light the fire at home.

My first prototype, almost fully assembled (one rocker bogie arm is attached here)

This first mechanical prototype enabled me to verify that the design worked in practice. It also allowed me to test how much motion was possible in the rocker bogie arms before the rear steering legs collided with the underside of the chassis. I was not sure there was enough range of movement, and it also made me realise the weight was not well balanced around the main pivot axis of the chassis. I needed to think about how to solve these problems, and also work out how to fit all the electronics and a power source into the body.

Refining My Rocker Bogie Design

Using my newly learned skills in CAD and laser cutting I started to build the rocker arms for my robot. I was pleased with the way my servos fitted into the arm, but concerned that using the servo itself as the only mounting point for the steering leg was not going to be strong enough. That tiny screw attaching the horn to the servo just did not feel like it would handle all the strain put on the robot leg.

My first prototype steering leg assembly

I had only attached one leg to the first part of an arm and already I was needing to redesign. Some browsing of possible bolt styles I might use online led me to shoulder bolts. These have a solid cylindrical section (the shoulder) with a short threaded section on the end. I redesigned my leg and arm ends to attach the leg using a long shoulder bolt as the axis. A nylon spacer provided the required separation of the leg from the arm. Moving the servo along enabled me to attach the servo horn to the leg via a hinged link. The shoulder bolts were also perfect for the other pivots in the rocker bogie arms. So with the entire arm remodelled in my CAD software I was ready to assemble a complete version.

My first attempt to put it all together in laser cut 3mm plywood proved that the design would work, but I could not fit the nuts onto the small bolts which held the servo mounting plates in place. I had not left enough room for the nuts to fit alongside the spacers on the pivot bolts. It was at this point that I discovered the collision detection feature of the CAD software and sure enough it highlighted the problem in my CAD model. Lesson learned I made some more adjustments and was finally able to build and assemble a complete pair of rocker bogie arms.