This a generic overview of making basic hobby robotics with common off the shelf parts. This is not a comprehensive guide but a collection of notes and concepts to keep in mind about this topic. This also assumes you’re looking to make something yourself vs. building a kit.
So you want to build a robot?
These are the key concepts to keep in mind:
- basics on circuits
- power system
- writing code
Will your robot use wheels/tracks or legs. This will affect what kind of electronics you will need to use. Also it will determine how simple or complicated your robot will be, particularly since a wheeled body would be more stable and require less effort to control and move.
Basics on circuits
The main thing I wanted to call out here is how important it is for the various parts to generally share the same ground (eg. black/brown wire). And to keep an eye on your parts, most things will use 3.3V or 5. You may have to mix the two in which case you would need a way to step down your power eg. 5V to 3.3V and possibly use a level shifter for communication. You may consider picking one voltage and sticking with it for simplicity.
More than likely the robot will be powered using batteries. Depending on what kind of robot it is eg. a hexapod (legged robot with 6 legs, 18 servos) that means a lot of servos (geared motor) moving at the same time that can pull a few amps or more together. You will have to figure out what kind of batteries you will use to power your system or if your power supply can sustain the amperage needed.
Here’s the wiring diagram for one of the robots above. I initially used an 8-cell NiMH pack and the current output was limited to 2A. It was a very heavy battery pack. This robot cheated by using the middle servo to support the weight of the robot as two of the four corners moved at at time.
The modern/powerful batteries like Li-Po, 18650 cell, have a form factor of 3.7V per cell, so you put two of them together in series, you get 7.4V. How do you get the 7.4V down to 5V or 3.3V? That’s where a regulator comes in. There are different kinds but for hobby grade, you’re dealing with some form of linear or switching (more efficient).
The left component is a step-down linear regulator, takes a voltage higher than 5V and drops it down to 5V. The right is a boost converter (step-up regulator), you can use this say to take a single-cell battery at 3.7V and get a 5V output (after twisting the blue potentiometer and hot-gluing in place).
The other thing to keep in mind is how many amps you have to work with. If you’re pulling from a power supply (switching regulator for ex.) it will most likely have a fixed output current eg. 2/3 A. Some will have more depending on what you buy (cost). Your electronics have to operate within that range. Servos can pull a lot of current so this is important to know. One way to measure the current draw of a bunch of servos running is by using a bench top power supply which acts as your battery. Then you can see the current draw being pulled.
You can also just directly power your servos from the battery however this requires being aware of operating voltages eg. can your servos handle it and is your battery protected (BMS).
Once you know what parts you’re going to use, you can wire them together in a way to control the source and flow of power.
The other important thing to keep in mind at least for servo-related robots/speed controller is PWM. Which I won’t go too deeply into but know that the better control you have with that and being true hardware, the more accurate and stable your servos will be to control. You will see servo drivers get connected to an RPi vs. directly to an RPi due to the GPIO pins on an RPi being mostly digital/a couple of PWM pins. Also the current limit on pins is another reason. The Arduino servo library is pretty good out of the box.
The RPi is good for doing things like visual computation (camera and GPU). Arduino is better for IO/analog (ex. more analog pins to read real values from devices). You can combine the two and have them talk to each other using communication protocols like I2C (easiest) and SPI. Also I shouldn’t say “better” they’re two different things kind of hard to compare.
The main thing I wanted to call out is, in Arduino there is a main loop that keeps running over and over again. This is a different way of thinking than say a Python script that runs once top to bottom.
So your code will be arranged around that concept. If you use an Arduino-based system then every time a loop happens, you can call methods, check things, etc… note that you can achieve the same thing in Python if you want. You probably would have some kind of loop going anyway that constantly listens for commands or checks its environment via sensors.
Depending on your robot type, if it’s a wheeled platform like an rc car, it is much easier to program/control than say a legged robot. The legged robot requires more coordination of things moving together to get a desired direction of motion and remain balanced/standing. You can manually program the legs or the more advanced way is to use inverse kinematics to control the “gaits” which is the specific pattern on how the legs move.
The basic tail-dragger robot at the very top image has a pretty dense, sensor-packed head. It features two ToF depth-sensors (purple/black things around camera in left image). The purple one has a very wide cone shape (25 deg, better at close range) and the black one has a very narrow cone shape (2 deg, better at distance). Inside it also has an IMU (tells you how fast your robot is accelerating, if it’s rotated and magnetic field strength around it — this is a 9-axis/DOF IMU). The bottom right is an ultrasonic sensor which is a very basic “something is there” type sensor. You can get distance but you generally need perfectly solid/reflective surfaces for them to be good.
To determine the robot’s orientation you can use a 6 DOF accelerometer/gyro (IMU). An IMU spits out raw values for acceleration, rotation… you have to apply math with these values to get anything useful from them other than just knowing if you’re moving or right side up. Concepts like dead-reckoning (in this case finding the floor) and more advanced terms like quaternions. Even more advanced… using filters to clean the data/infer more accurately.
Your robot may be controlled manually eg. RC or self navigate by obstacle detection or scanning with sensors and mapping (SLAM). It is pretty trivial to implement a bump sensor eg. ultrasonic sensor telling the robot to back up/go a different direction. The SLAM part is more complicated.
There are different options. You can use wired (serial) or wireless (WiFi/Bluetooth/other tech). Initially you’ll probably just be using serial whether it’s by USB wired or by SSH eg. a headless Raspberry Pi (no desktop environment). But you can attach other components like an ESP-01 which is a WiFi module to an Arduino. The ESP-01 then talks to the Arduino via some protocol like I2C. You can also use more advanced ESP boards like ESP32 with the Arduino IDE.
So at this point you have some idea of what’s involved. You should be able to start planning your own robot/what you will need in order to build one. There are a lot of guides out there and forums to get help from. It’s a great feeling being able to tinker and build something yourself.
There are also much more advanced topics for robotics like ROS but I have personally not gotten that far to write about it. Same for topics like visual inertial odometry (VIO) which is on my list of things to learn.