The Mote Hardware

· 8 min read

Hardware vs Software

When it comes to robot tutorials, especially ones with a focus on beginners and cost, there is a tendency to focus heavily on the hardware leaving the software as the minimum required to get the robot moving. There are two main reasons for this:

  1. The minimum cost of hardware required to get a “real” autonomous robot is high given a student’s budget. When you cut the cost of the hardware, you either lose some fundamental capability, or you have to spend more time to work around the limitation. For example, most cheap robot projects will use a microcontroller rather than a full computer. These can be 10x cheaper but don’t allow you to run a complicated software stack. Cheap motors require special controllers or hacks to measure their velocity among other things.
  2. When starting out there is so much to learn that it can be easier to focus on one thing first. Robotics is enthralling because it is all about the physical system and so hardware often takes the priority. Cheap hardware without software still gives you a robot, but software without hardware isn’t really robotics.

With these in mind, I want to spend this post going through the few pieces of hardware Mote uses and the trade-offs we are making for each.

Motors

Ok, this one is easy to understand - if we want our robot to move, it needs motors. Motors come in many types with many different properties. A motor used for a quadcopter is not the same as one used for a robot arm. But what’s the difference between a £1 motor and a £50 one? What is a servo and how is it different from a motor?

Alright, let’s back up a bit. What exactly is it we need our robot to do here? Firstly, we want it to move, that’s the obvious one. If we want to turn then we also need to set the relative speeds of the motor on each side. We also want to have some idea of how far we have moved. Breaking these down, we need our motors to:

  1. Accept speed commands so we can control how the robot moves
  2. Report how far they have moved so we can keep track of where we are
  3. Do both accurately enough that we don’t get lost - turning 85 degrees and moving 10m puts you in a very different place than turning 90 degrees and moving 10m

Before we go further, it’s worth clarifying that motors alone will never be able to exactly tell you how far the robot has moved. The robot can get caught on things, wheels slip, and general wiggle within the gear train (“backlash”) - all reduce its accuracy. However for all its faults, it’s still our first piece of the puzzle when it comes to tracking our location.

Back to the motors. Ok so you bought the £1 motor, what is it missing? Well it won’t have an encoder (the thing that tracks how far the motor has turned) so we would need to attach one ourselves. It also won’t have anything to control the speed or direction, so we would need to add a driver for that. Finally, we don’t have any way to feed the output movement data back into the control data to ensure our commands are being executed accurately so we will need some sort of controller loop.

What about the £50 motor? Well it likely has an encoder built in and can put out a lot more torque or speed, however it will still need the driver and the controller.

The motor ladder

Enter servos. Servos are a special type of motor designed for precise control rather than speed. These have both a controller and an encoder built in which is what allows them to turn to a precise position. Most cheap servos are limited in that they will turn to the desired position, but have no way of feeding that back. This is great for RC applications but not for robotics. Smart (or bus) servos have a digital protocol that allows them to report their position back (along with other data).

Now, smart servos are great, but they are not entirely self-contained. They still need a board that can understand the digital protocol and convert it into something a computer can understand. This board is also responsible for distributing power to the servos. It doesn’t need a controller loop or driver though so it is generally cheaper than a full motor control board needed for motors. On top of this extra board, they have one other big tradeoff: they are really slow. The one we use for Mote has a max speed of about 0.22m/s; fine for us but it won’t win any races.

So what does Mote use? Two Feetech STS3215 bus servos (~£12 each) plus a £15 adapter board. Checking the list: speed commands over the serial bus (1), position reported back from the built-in magnetic encoder (2), and the control loop closed inside the servo itself (3). That gives us a total cost of around £40.

This compares with two motors with hall encoders (£8 each), an H-bridge driver (£4), and either a microcontroller which you will need to program yourself (a lot of work), or an integrated control board which is expensive (~£80).

The servos are a good balance of cost and get us to the “smart” bit of robotics much quicker.

Battery

Ok let’s apply our logic to the battery story. What is it we really need for a robot to power itself? With a limited number of components, we really only need to worry about three things: capacity, size, and connectors.

  • capacity - it needs to last a good few hours of use
  • size - it has to fit in the chassis
  • connectors - it has to connect to all of our other components

Battery packs for RC vehicles tend to be raw LiPo cells that then need to be connected through a battery management system. This then distributes the power out to the various systems. You need to monitor temperature, voltage, and a few other things to ensure it is operating correctly and safely. Connecting raw DC is a simple solder/connector job, but if your computer wants power from a USB-C port then it gets more complicated.

Luckily for us, the battery story has become much simpler than it used to be. Rather than worrying about all of that, we can now get USB-C battery packs for cheap. These include a battery management system and use a universal connector format (USB!). The biggest problem is that there are so many options available!

To narrow it down, we need to ask how many connectors, and how much power do we need? Well we need one for the servo board we talked about above. We will also need one to power our brain (Raspberry Pi). The STS3215 servos we use are rated for 7.4V but work down to ~4.5V (with reduced performance) and require less than 2A of current. The Raspberry Pi requires 5V at 5A for full power.

This gives us a rough estimate for our power draw of 2 servos x 5V x ~0.5A = ~5W + the Raspberry Pi’s 5V x ~3A = 15W for a total of 20W average power draw (and in most situations it will be far lower than this). A normal battery pack size is about 20Ah (normally displayed as 20,000mAh) which assumes 3.7V so ~74Wh of energy (minus conversion losses so more like ~63 Wh). That means a 20Ah battery pack gives us about 3 hours while actively driving.

Things get a little complicated when we start considering protocols, but most power banks these days support USB-C PD (Power Delivery) which allows the devices to negotiate the voltage and current output. Without this USB-C is capped at 5V and 3A (and the Pi would throttle power to its USB-A ports which we use later).

Mote uses a 20Ah battery pack from UGreen that has two USB-C output ports that both support USB-C PD and that costs ~£45. (In the last post we did use a slightly larger 25Ah pack but it didn’t quite fit in the chassis with the cables attached, trading one hour less drive time for no risk of snagging).

The tradeoff here is that automatic recharging is probably out of the question but thats seems a fair trade for the simplicity.

LIDAR

Camera

Brain

Everything in this post is in the BOM: github.com/ClachDev/Mote.