Chapter 19: Planning Your Next Robot Project – Putting It All Together

Throughout this book, you've now seen how to plan, design, build, and program a robot. We've covered many of the starting topics with some hands-on experience of them, an example demonstrating the basics, and some ideas of how you could improve them. In this chapter, we will think about your next robot. We'll answer questions such as the following: How would you plan and design it? Which skills might you need to research and experiment with? What would you build?

We will cover the following topics in this chapter:

• Visualizing your next robot—how will it look?
• Making a block diagram—identify the inputs/outputs and parts it would need
• Choosing the parts—which tradeoffs will you think about when selecting components for the robot?
• Planning the code for the robot—which software layers and components might this robot need, and which behaviors would be fun?
• Letting the world know—how would you share your plans, or your robot, with interested people?

Technical requirements

For this chapter, I recommend having some diagramming tools such as the following:

• Pen/pencils
• Paper—a sketchbook (or perhaps graph paper) is great, but the back of an envelope will do
• A computer with internet and access to https://app.diagrams.net/

Visualizing your next robot

When we started this book, in Chapter 2, Exploring Robot Building Blocks – Code and Electronics, we first learned how to look at robots as a sketch. I suggested that you make quick drawings, and not worry if they are rough and sketchy—this is perfect at an early planning stage. Use a pencil or pen, and then move on to the more formal block and layout diagrams later.

Every robot starts with a bit of inspiration. Perhaps there is a competition you want to try; maybe you've seen something such as another robot or an animal you want to mimic (crabs are fascinating!). Other inspirations may come from seeing a unique new part or wanting to learn/play with a new skill. You may even have made a list of amazing robots you want to try to build.

Before building a robot, make a short bullet-point list of what it will do, which sensors/outputs it will have, and what it might have to deal with. This list lets you focus your efforts. Here is an example, which I made for my SpiderBot project seen in Chapter 10, Using Python to Control Servo Motors. This is what I planned for it to do:

• It will have six legs (yes—an insect, not a spider).
• I will use it to experiment with legs and gaits.
• It will be able to avoid walls.

Your quick sketches could first be a basic six-legged stick drawing, with some squares at one end to represent the ultrasonic sensor, and perhaps a few arrows with notes to depict what they mean. You've seen this technique in detail in Chapter 2, Exploring Robot Building Blocks – Code and Electronics. The following photo shows a simple design:

Figure 19.1 – Sketching your ideas on paper

As Figure 19.1 shows, my preferred first sketches are with a biro on graph paper, but I'll use any paper I have.

Visualizing the robot can be made with 2D, 3D, or profile sketches. Here are a few tips:

• Draw lightly, then follow through with firmer strokes when you are more confident with the design.
• Annotate it a lot with anything that comes to mind.
• Don't worry about scale, dimensioning, or perfect drawing; this is simply to capture ideas. You'll flesh them out and make firmer decisions later.
• It can be a good idea to date the picture and put a working name on it, even if you have a better name later.
• Feel free to combine block-style representations with sketchy visual versions.
• Keep a biro/pencil and notepad/scrap paper with you somewhere so that you can quickly jot down ideas. A whiteboard is excellent if you are near one. A pencil can let you erase and rewrite, and a ballpoint pen is easy to keep in a bag or pocket.
• Get the big ideas down first; come back for detail. It's easy to get bogged down in detail on one aspect, forget the other parts, and run out of time. You can always make a tiny note to remind yourself.

You can revisit this process at any time during the robot build, perhaps when you have further ideas, when you have a problem you are solving, or when you want to refine it. Most ideas start with some bullet points and a scribbled sketch; waiting for access to a computer or trying to draw it perfectly will detract from the next fantastic idea you already have in your mind—get it down first.

Now that you have a sketch of roughly what it will look like and have written a basic plan on paper, we can start to formalize it with block diagrams.

Making a block diagram

Recall how in Chapter 2, Exploring Robot Building Blocks – Code and Electronics, and throughout the book, we've created block diagrams showing the robot we built there. You can represent any robot in this way. This diagram is where you would have a block for each input and output and then create controller and interface blocks to connect with them. Don't worry about the diagram being perfect; the main point is that the picture conveys which parts you'll connect to others. It's also quite likely that the initial diagram will need some change as you build a robot and come across constraints you were not aware of.

Here are two stages of a block diagram for SpiderBot:

Figure 19.2 – SpiderBot block diagram stages

In Figure 19.2, I initially knew going in that each leg had three motors, but not a lot else. So, I drew those blocks in, along with the distance sensor I want it to have and a Wi-Fi connection.

In the next stage of the diagram, I added the controllers I'll use for it and then made the rough connections on the diagram. These are just blocks, and this is not a circuit diagram. These have been thrown together with app.diagrams.net. Note that things could still change as you learn more about your robot and its controllers.

You may also consider making diagrams for add-ons and subcomponents. Any part that seems complicated may need a further diagram to explore it. The important thing is to get ideas such as this out of your head and onto paper so that they are clearer, so that you don't forget them, and so that you may be able to spot flaws.

The other block diagram to consider is a software diagram, which we will visit in the Planning the code for the robot section.

Now, you have a rough sketch of the robot and the block diagram, and you are ready to start choosing the parts you would use to build a robot.

Choosing the parts

Throughout this book, we have looked at the tradeoffs between different kinds of sensors, different chassis kits, controllers, and so on. These are tradeoffs on weight, complexity, availability (you don't want an irreplaceable part), and cost, covered in detail in Chapter 6, Building Robot Basics – Wheels, Power, and Wiring.

If a particular kit inspired the robot—for example, SpiderBot was inspired by a hexapod kit; yours could be a robot arm or caterpillar track kit—this will likely constrain the other part choices you need to make. I'd need to support 18 servo motors; however, I had a 16-motor controller available, so I elected to use two input/output (I/O) pins of the central controller for the remaining two servos. This added software complexity, though.

Another tradeoff was the main controller. I knew that I'd want SpiderBot to be Wi-Fi-enabled, but it wasn't going to be doing visual processing, so a small, cheap, and low-power controller such as the ESP8266 was an excellent choice for it.

For power, I knew that it would require a lot of current for all those servos but it wouldn't be able to carry a great deal of weight, so a more specialist lithium polymer (LiPo) battery would be needed, along with a charger/protection circuit.

A key stage of choosing the parts is to test fit them.

The test-fit diagram

When choosing the parts, consider how they will fit together: is there a clear path to interfacing the choice of motor controller with your choice of main controller? Have these two components been used together, or are you prepared for the complexity of making a new interface? Based on the parts you think you will buy, collect their dimensions and try making a test-fit diagram, as we did in Chapter 6, Building Robot Basics – Wheels, Power, and Wiring. Try to make a test fit before buying new parts.

Buying parts

It was then a matter of finding stockists to buy it. I do have some local favorites (such as coolcomponents.co.uk, shop.pimoroni.com, and thepihut.com), and you will find those in your region as you build more. Looking for local Pimoroni, SparkFun, Raspberry Pi, and Adafruit stockists will help you find the right kind of store.

You can find modules on your regional Amazon, Alibaba, or eBay but be very clear about what you are buying and how much support you will get. You'll find individual parts at large stockists such as Element14, Mouser, RS, and Digi-Key; although they tend not to have many prebuilt modules, they are reliable and have large catalogs.

Parts are mostly sold online. There may be high-street sellers of electronics and mechanical parts, but this is becoming rarer.

You may also use parts from an existing stock, which you will build up as you build robots. You can convert toys into robot chassis, a practice known as toy hacking. Robot builders can salvage motors and sensors from old printers and electromechanical systems (with care). In this case, the test-fit diagram will help you see what you may need to change to make things work with the salvaged parts.

Assembling your robot

Now, you are ready to assemble your new robot. The building guides in Chapter 6, Building Robot Basics – Wheels, Power, and Wiring, and Chapter 7, Drive and Turn – Moving Motors with Python, along with the basic soldering guide in Chapter 12, IMU Programming with Python, will get you started. However, the additional reading and skills suggested in Chapter 18, Taking Your Robot Programming Skills Further, will give you many more options for assembling the robot.

Now that you have the parts and you've started building the robot, the next thing to consider is the robot's code.

Planning the code for the robot

We started planning code in layers in Chapter 2, Exploring Robot Building Blocks – Code and Electronics, and then explored this further in Chapter 7, Drive and Turn – Moving Motors with Python under the Robot Object section.

Let's recall how we planned our code structure with layers.

System layers

The general idea is to create layers of code in the system, as shown in the following diagram:

Figure 19.3 – Robot software layers

As Figure 19.3 shows, there are some suggested layers, as follows:

• At the bottom of the stack, Vendor Libraries. These, as the name implies, usually come from the hardware supplier, third parties, or a community. These are things such as the gpiozero library we have been using or the various Arduino libraries for that ecosystem. This layer may include I/O control, bus layers, and network stacks.
• The next layer is Libraries and Middleware. This software may come from a third party—for example, higher-level libraries to interface with specific hardware. The middleware layer also includes abstractions you've written, such as making two-wheeled robots behave the same, even if the third-party libraries differ. On the same layer are algorithms and libraries. OpenCV exists at this layer, from a community. Your Proportional-Integral-Derivative (PID) algorithm or object recognition pipelines may belong in this layer. This layer has components to build apps and behaviors.
• The top layer is gluing everything together. Take hardware sensor inputs, through algorithms, to create hardware motor outputs and pleasing control interfaces or dashboards. The top layer is where you make behaviors and apps for the robot.

For a basic robot, components in these layers could just be functions or classes. For a more complicated one, these may be different software components talking on a shared software bus (such as a message queue or as connected services). The library we have already built will work for many small-wheeled robots (at the middle layer). This library will need refining as you gain experience with it. You can adapt behaviors for new sensors and outputs if you have kept the behavior separate from the hardware concerns.

Use diagrams to draw the blocks and layers to express where those boundaries lie. Expect to write code in modules and blocks that you link together to reason about each part. It should not be necessary to get lost in the details of a Serial Peripheral Interface (SPI) data bus transaction (at the vendor hardware layer) when thinking about making pleasing LED patterns (at the behavior layer).

Once you've considered layers and some rough components, you will need to think about how information moves between them with a data-flow diagram.

Data-flow diagrams

You can also use diagrams to explore the behavior from a data-flow perspective, such as the PID and feedback diagrams used to express the behaviors in Chapter 13, Robot Vision – Using a Pi Camera and OpenCV. We also use this diagram style for the color object and face-tracking behaviors as data pipelines showing the image transformations. Don't expect to capture the whole story in one diagram; sometimes, a few are needed to approach the behavior's different aspects.

Spend time considering the tricky areas here, such as additional math that might be needed if the sensor/movement relationship is complicated. You might not get it right the first time, so building it and reasoning about why it behaved differently from your expectations will be necessary. At this stage of the design, going and finding similar works on the internet or reading one of the many recommended books will yield a deeper understanding of what you are attempting. In most cases, persistence will pay off.

Formal diagrams

There are formal representations for diagrams such as flowcharts or the Unified Modeling Language (UML) types. These are worth finding out about and learning as a resource to draw upon for drawing. The app.diagrams.net software has a nice library of diagram elements. The most important aspect of a diagram is to convey the information—you should try to express what is in your head in a way that makes sense to you 6 months later, or to your team (if you have one).

Sometimes, building simple behaviors gives you a library to use for more complicated and interesting ones. Our straight-line drive behavior was a building block to start on driving in a square behavior.

Programming the robot

You can now program the robot, but be prepared to go around a few planning, implementing, testing, and learning loops. Do not be disheartened by testing failures, as these are the best opportunities to learn. The most learning is done in planning and determining test failures. If it all works the first time, it's far less likely to stick with you. Each behavior in this book took me multiple attempts to get right; tuning them is a trial-and-error process.

You've planned your code, and you're now building the robot. How do you let the world know you are making something and find help?

Letting the world know

You are bound to have questions about how to proceed and problems to be solved—perhaps you've already encountered them before building. When you have questions or have made some minor progress, it is the right time to get online and link with the robotics communities, as shown in the Online robot building communities section of Chapter 18, Taking Your Robot Programming Skills Further.

Use Twitter and Stack Overflow to ask questions or even answer questions from other robot builders. Use YouTube to share your creation or the story of your build and see other people's builds. You do not need to wait until you have a perfectly polished product. Share the steps you've taken, the frustrations you have encountered, and even the failures you've learned from. Failure situations make for some of the best stories. These stories can be just the right motivation for someone else to keep on persisting with complicated builds.

Use a combination of YouTube, Instructables, and online blogs to practice new skills, or—better yet—get to a nearby Makerspace, Coder Dojo, or Raspberry Jam to practice new skills with others who are also making and learning.

Being a robot builder will make you an eternal student; there is always more to learn on the subject, not least because it is still an area of much research. People are pushing the boundaries of human knowledge in robotics. You can push your skill and knowledge boundaries while becoming a mentor and helper to extend the boundaries of what others can do. Perhaps you will come up with kits, modules, and code to lower barriers to entry, and you may also find novel ways to use robotics or build a sensor that pushes the boundaries of human knowledge. Whichever way it is, engaging with the robot community is exciting, refreshing, and keeps you looking out for new stuff to try.

Testing your robot in lab conditions is OK, but the most rigorous testing happens outside, at competitions and demonstrations. You will shake out new bugs, find new problems to solve in these cases, and create a network of robot-building friends and peers. Robotics has a stereotype of being a very solitary hobby or profession, but this need not be the case as there are plenty of people making something, so make with them.

Building with a team can be very rewarding and challenging. It will allow you to create more ambitious builds than going it alone. Getting involved in any of the communities, especially local ones, will probably represent your best chance of finding team members.

You've now reviewed how to reach out to the wider world of robot builders and find help, inspiration, and competition. You've seen how robotics can be a collaborative and social hobby. Perhaps you've also been inspired to start your own robotics blog or YouTube channel. I look forward to seeing you in our community!

Summary

You've now seen throughout this book how to build and program your first robot. You've seen where to find out more and how to extend your knowledge. In this final chapter, we've summarized what you've learned and suggested how to use this to plan, build, and program your next robot, as well as taking it on tour and being a member of the robotics community.

You've seen how to design and plan a robot and how to build, program, and test a robot. You've learned hardware skills such as soldering, simple software such as moving a robot, and have touched lightly on complex areas such as computer vision and inertial measurements. You've shaken out bugs, made tradeoffs, finely tuned systems, and learned how to keep backups. You've made user interfaces, smart behaviors, and taken control of a robot with a smartphone.

You have reached the end of this book, but I hope this is just the start of your robotics journey.