Designing a Mobile Robot

In this first article of my three part series on mobile robots I will walk through the hardware design of Cerus and share practical approaches and useful resources with you.

Setting Development Goals

When starting to design a mobile robot there are virtually infinite routes you can go. Popular designs have wheels, legs, tracks in any configuration — each with advantages and disadvantages. I’ve contributed to a number of different robotics projects over time, from factory floor robots to ones that will work on a farm. I’ve found the best way to narrow down development options is to define a concise problem statement and eliminate options that are not a good solution to that problem statement. For an agricultural robot, for instance, you may look at different obstacles on a farm that the robot needs to overcome, the weight of tools and attachments it has to pull and potentially adverse weather conditions it needs to operate in. These considerations can quickly become a long list of requirements that will determine basic aspects of your design, such as the number and size of wheels, strength of the motors and materials that are suitable to be used.

For Cerus, the problem statement was quite simple — it had to be able to drive around autonomously in an apartment. We don’t have stairs and mostly hardwood floors, which makes an easy environment for a mobile robot.

Choosing Wheels

If you’re just starting out with mobile robots, using a differential drive with two driven wheels and a caster is ideal. The Jetbot takes this approach (if you haven’t built one, consider it as your first robotics project). Differential drive robots are easy to make and easy to program. Because I was looking for a challenge, I decided to go for a four-wheeled approach and to make things even more interesting, I chose Mecanum wheels which allow the robot to also drive sideways in a somewhat mind-bending fashion. For this series, we treat our Mecanum robot as a differential drive robot by pairing the wheels on both sides to make the robot turn left or right, or have it spin in place. The wheels I chose are 60 mm Mecanums here. Mecanum wheels are different for the left and right side of your robot, so make sure you get a matching pair.

Note: The Mecanum wheels I chose for Cerus combined with the rather long wheelbase generate a decent amount of drift (meaning the wheel spins without actually moving the robot). This causes problems in our go-to-goal application in the third part of this series. In retrospect, I would consider larger non-Mecanum wheels combined with a shorter wheelbase.

Specifying Motors

Once you’ve settled on wheels, motors are next. There are a few different approaches, but geared DC motors are almost always the way to go. They are cheap, light, easy to control and they offer decent low-speed torque which is critical for a mobile robot. I chose four Pololu 100 RPM 12 V motors with encoders.

The only specified input you provide to any DC motor is a voltage. I recommend working with 12 V motors for a medium-sized robot, so the input voltage range is 0–12 V. The current of the motor will be determined by the shaft speed and the torque the motor needs to provide. That means that we need to only select the speed that we want, and the torque that we need.

Motor Speed

Geared DC motors are a motor paired with a matching (reduction) gearbox which takes the high speed of the motor shaft and reduces it to a lower and more suitable speed that can drive the wheels of a robot. Typically, motor manufacturers will give the output speed of the gearbox in RPM (revolutions per minute) which is all we care about. Using RPM and the size of your wheels we can calculate our robots maximum speed in meters per second:

Max Speed Vmax: m/s
Rounds per minute rpm: 130/s
Wheel radius r: 0.03 meters

Vmax = rpm * 𝜋 * 2r / 60

For Cerus’ 130 RPM Pololu motors and our 60 mm wheels this solves to about 0.4 meters / second. Not a blazing speed, but more than fast enough to get around an apartment.

Motor Torque

Beyond speed, the torque of the motors needs to match your wheels and your general requirements. Torque is measured in Newton meters (Nm) and describes the rotational force that your motor can exert on the ground via your wheel. Since Nm is multiplicative (Newton * meters), with a bigger wheel your motor has to exert higher torque to introduce the same force into the ground to move the robot. Put simply: Bigger wheels, bigger motors. Low torque will lead to bad acceleration and can cause your robot to stall (not move at all) when loaded or attempting to drive over an obstacle.

To determine the required torque for our motors, we can use the following equation (thanks to AJ Neil at Servomagazine):

T = M(a + g * sinθ)r

Where T is the torque required, M is the mass of the robot, a is the desired acceleration, g is the gravitational constant, θ (theta) the angle of the incline in degrees and r the radius of the robot’s wheels.

For Cerus, we can fill in the following assumptions:

Weight of the robot: M = 5 kg
Maximum Speed: v = 0.4 m/s
Maximum incline to climb: θ = 10 degrees
Reach maximum speed in one second: a = 0.4 m/s²
Drive wheels will be 60 mm in diameter: r = 0.03 m

And solve the equation:

T = 5 kg * (0.4 m/s² + 9.81 m/s² * sin(10)) * 0.03 m = 0.32 Nm

Since our robot has four driven wheels, we can divide by 4:

Twheel = 0.08 Nm

If you don’t like equations, the Robot Shop has a great calculator.

Note that the above equation doesn’t take into account any inefficiencies, such as wheel resistance, gearbox losses etc. Because it is much more annoying to spend hours building a robot that is sluggish than to over specify the motors, I tend to pick motors that are much stronger than what the calculation suggests. This is fine in small scale projects where power consumption doesn’t matter, but becomes tricky for larger robots or those that need to be small and or efficient. That’s where these calculations are important.

Our 4 Pololu motors offer 1.75 Nm of torque in total, more than enough to move along a flat floor.

Managing Power

Once you have your wheels and motors you will need to select an adequate battery to power the robot.

Three factors matter in battery selection: The voltage (V), peak discharge current (A) and capacity (Ah). The battery’s voltage ideally determines your system voltage and it makes sense to match it to your motor’s voltage to avoid unnecessary power transformations. Peak discharge current describes how much current you can draw from a battery at once without destroying the battery or causing an internal fuse to shut off. This matters because multiple motors, controllers and computer on your robot can draw quite a high current under full load. I’ve had many occasions where a stalling motor on a robot caused the main computer to shut down because of a current shortage. Battery banks (those used for charging phones) are convenient for building small robots because they come with handy USB connectors but they are notorious for limited current output. Here is how I estimated the current requirements of Cerus:

Motors: 5.6 A * 4
Main computer (Jetson Nano): 0.83 A
Sensor array (Intel Realsense): 0.3 A
Microcontroller (Arduino Mega): 0.2 A
Accessories (Motor controllers etc.): 0.5 A

In a worst-case scenario Cerus could draw almost 25 A. That’s too much for most batteries. I opted for a LiFePo battery that offers 15 A of peak current. These are similar to Li-Ion or Li-Polymer batteries but don’t catch fire when you accidentally overstrain them. Which is good. To prevent system issues if we somehow manage to stall all four motors, I connected the motors via a current limiting circuit. More on that in the second article.

Lastly, we’ll look at capacity. Battery capacity determines how long our robot can run until it needs to recharge. Because capacity is a function of time and momentary current draw it’s hard to estimate (unless your robot only processes one program forever and only drives at a constant speed). Taking the 25 A peak current from above, Cerus could run for 24 minutes on a 10 Ah battery. Because it is very unlikely it will ever reach peak currents it will likely run MUCH longer. Because I don’t like recharging my robots, I chose a rather massive 15 Ah battery — which will power Cerus for days on end under normal use.

⚠️ Even at 12V, the shock from a battery can be harmful. Be careful when wiring up your robot.

*Remember that the current is highest when the torque is highest — meaning we can use the stall current to know the maximum amount of current the motors would ever draw.

Designing the Chassis

With wheels, motors and a power source, the last part of hardware design is making a chassis that allows all of these components to be assembled to make a robot. I use Autodesk Inventor for CAD design but other tools such as Autodesk Fusion360 (free for hobby projects) or even Sketchup work, too. Onshape is a cloud-based alternative that works in a browser. I designed for 3D printing from the get-go, as you can see from the somewhat complex geometries. I still like to use a number of screw connections (rather than printing larger portions of the design in one piece or gluing parts together) because it makes assembly and disassembly so much easier. McMaster-Carr is a great source for any nuts and bolts you might need.

The lower portion of our design features the motor mounts that bolt together with a base plate. When mounting encoder motors like this, make sure there’s enough of an airgap to avoid encoder interference! Together with a top plate, this assembly of four parts forms a tight grip around the battery, holding it in place. Keeping the battery at the center and as low as possible helps with the driving dynamics of the robot.

The top plate and a lid form an enclosure for the motor controllers and power converters — I wanted these components safely tucked away because I knew I wouldn’t touch them once Cerus was assembled.

The very top of Cerus is designed with a number of mounting holes for all components I wanted easily accessible — such as the Arduino microcontroller and the Jetson Nano. Plus, the exposed wires and components remind me of the Mars rover — and I really like this aesthetic.

A Low-Cost Alternative

If you don’t have access to a 3D printer, consider designing your chassis using laser cut flat material. I did this for a first test of the motor configuration and it’s an extremely quick and cheap way to put together a robot. I used Sculpteo for the parts.

Keeping Wiring In Mind

When designing in CAD, it can be tempting to forget about, or at least gloss over the existence of wires and cables only to find that assembling the physical product is a mess because wires don’t quite fit. This has happened to me many times. For Cerus, I bought most of my cables, wires and connectors before I started with the hardware design, carefully measured the size of the connectors and the bend radius of the cables and factored these into the design of the chassis. This really pays off when designing a robot where you’ll usually end up with dozens of wired connections and you don’t want any of them to get into the way of moving parts!

Conclusion

In this article, we walked through the mechanical design for our mobile robot. We looked at selecting motors and wheel combinations that make sense, how to figure out the right power source and we investigated the different aspects of designing a chassis in CAD. With a solid mechanical platform in place, we can now look at the next article in this series.

If you are interested in building your own Cerus, you can find the bill of materials on GitHub here and the 3D print files here.

Continue reading part two, Electronics and C Programming for a Mobile Robot.