IPragmaticCoder

Introduction

---

Welcome to what will be a journey in utilizing a Raspberry Pi 5 as the logic board for a robot and all that entails. This article will be a multi-part series of posts discussing the facets involved in building a simple, purpose-built robot. We will look at the various HATs, sensors, controller boards, OSes, tooling, and more to develop a clear path for others to use this as a blueprint for their own endeavors.

This series will include the following (links will be added as posts are published):

• Part 1 – Introduction
  • This post.
• Part 2 – Initial Setup of the Raspberry Pi 5 Stack (as I see it)
  • In this post, we will cover connecting the Raspberry Pi 5 to the AI Kit and the AI Camera. We will also install Ubuntu (both 24.04 LTS and 25.04) and walk through the OS setup. After that, we will install the firmware and tooling for the AI Kit and the firmware for the AI Camera. This isn’t as straight-forward as one might think but is doable to an extent. Since Ubuntu (Canonical) currently doesn’t have a release of the tooling for the AI Camera in their repository, we will use Docker to create a Bookworm environment with all of the firmware and tooling for the AI Kit and the AI Camera which will allow us to test object detection, pose estimation, and other ML modes.
• Part 3 – Adding an IoT Platform to the Mix
  • In this post, we will connect the device to the Particle.io Cloud Platform and test accessing the device. Here we will test Terminal access from the cloud and see what events and data can be sync’ed from the edge device. We will also dive deeper into this, in a later post, to review OTA system and application updates.
• Part 4 – Remote Software Development using SSH
  • We definitely want to be able to write code easily for the specific device we are using so, we will setup SSH on the Raspberry Pi system. This will allow us to connect to the device from another system through Visual Studio Code and CLion. We can then develop our software directly on the edge device from an environment which we are most comfortable. Since the edge device will be used in a robot, we will use ROS 2 and C++ for our application development. In a later post, we will look at reusing the earlier Docker container as the host for our application in case we take that route.
• Part 5 – Adding Controller Boards and Sensors
  • Since our goal is to build a robot, we have need for additional hardware which may include a robot controller board, various sensors, and a battery. Some of the sensors might include GNSS/GPS, Sonar, LiDAR, and ToF but there are many, many others you may use for your specific use-cases. We’ll look at the packages we will need to install in the host system (RPi5) and/or the Docker container to access these hardware components through code.
• Part 6 – Where Should the Application Run?
  • There are, at least, a couple ways to go as to where the application can be hosted and executed and the options are probably obvious but worth discussing in this context. Either the application is executed directly on the host system or in a Docker container. This can become a more nuanced conversation for various reasons. These nuances include a supervisor/main application running on the host and calling services/APIs for the worker/subordinate applications hosted within the Docker container, the reverse is also true where the application in the Docker container is accessing the host network to call services/APIs running on the host, accessing Cloud APIs, etc. We are constrained in this set up but still have options. We will work through the choices and what might direct us to choose one over the other.
• Part 7 – What Do We Want to Build and What’s the Minimum Viable Product (MVP)?
  • When creating a product, we should have a generalized idea of what we want our product to be. We may not have all the answers to this on day one, but we have a general idea of how expansive we’d like it to be, even if that’s “pie in the sky; it’ll solve world hunger” type of idealism. Once we have that generalized goal, we now have to trim that down to which parts of the system can and must must be created to achieve an MVP. This MVP and some forethought on where we want to go should help us setup and structure our application architecture and application project setup(s).
• Part 8 – TBD
  • As we get closer to defining our end-goal and our MVP, we’ll be able to expand on the topics that need to and should be discussed. This may include items that deal with ROS, deployments for system updates and application updates, architectural choices, data collection and storage, data transmission (between swarm devices, real-time uploads to the Cloud, and, potentially, to a supervisor robot for real-time or post-event uploads to the Cloud). There’s a lot to discuss and we will continue to add to the series until we have a finalized path to a physical MVP.

We will be utilizing a robot vehicle designed for educational purposes. Instead of using the out-of-the-box platform already developed, we will design and build the software to control it ourselves, hopefully with some rigor.

By the time we are done, the hope is this series will be a thorough introduction creating a relatively basic robot along with all that entails (setup, configuration, application development, etc). This should create a stable foundation to expand into more advanced robotic designs and developments as there are so many facets to consider.

As an example, in later articles, we will look expanding this development to include swarm capabilities, autonomous capabilities (where the swarm is given a goal and it executes it without much, if any, outside assistance), sensor data collection and storage, on-device edge data analysis, and XR environment creation using the vast amounts of sensor data.

I hope you will find this journey interesting, exciting, and fruitful in your existing and/or future endeavors.

Part 2 (coming soon) >