This article provides the high-level motivations for building the GARP while also introducing the initially-defined subsystems and their core roles and responsibilities. Functional descriptions of the subsystems are provided, and functional diagrams of the Power and Mobility Subsystems are included. This article serves as an entry to the series on the GARP, its design, and its implementation, the links to which are provided at the end of this article.
Motivations and Guiding Concepts
Over the past couple years, I’ve had a few opportunities to manage several robotics efforts and have been really impressed with where the technologies are going. Unfortunately, despite the proximity to the technology, my management responsibilities didn’t afford me the bandwidth to delve into the details, let alone learn the ins and outs of contemporary challenges in robotics and autonomy. As an engineer, I enjoy solving problems, and I tend to learn best by researching them and implementing solutions. Furthermore, one of the reasons I was drawn to Electrical Engineering in my education was the breadth of topics it touched and the opportunities for cross-polination across them, which I saw again in robotics and autonomy. Along another dimension, I’ve been most impressed in my interactions with those that possessed knowledge of the full stack of technologies leading to a capability, including across the analytical, simulation, and empirical domains. I believe this is particularly beneficial in robotics where the energy densities provided by current technologies create incentives to couple subsystem designs such that low-level details can weave their way throughout systems.
With this in mind, I decided to design and build a ground robot to support my future learning and research dubbed the Ground Autonomy Research Platform (GARP). To do so, I’ve adopted a few guiding principles:
Modularity: Avoid coupling across subsystems wherever possible. This is a driving factor in choosing to build a more forgiving UGV versus e.g. a UAS.
Capacity: Design-in significant excess capacity whenever possible to provide additional flexibility in future applications, particularly at the expense of application-performance measures
Iterate: Start with minimal or simple solutions first and then iterate to more complex solutions
Strategy
To realize this iterative approach, I’ve established a process moving through three initial stages:
- Alpha: Focused on producing Breadboard (TRL ~4) components, this stage:
- Supports parallel initial development of subsystems such as Mobility and Navigation
- Supports evaluation of critical design choices such as microcontroller selection for the motor controllers
- Supports rapidly converging on required design changes such as are higher resolution encoders or different motors needed
- Beta: Producing Brassboard (TRL ~6) components, this stage:
- Begins evaluation of the individual components and the integrate whole
- Is not intended to be fieldable, and is intended as a benchtop immobilized system
- Allows testing of extended run times and discovery of issues such as thermal management issues
- Supports basic characterization and parameter tuning such as exploration and coordination of updates rates across multiple subsystems
- Enables using and refining the planned field use protocols for processes such as start up, data collection
- v1.0: Targeting a Prototype (TRL ~6) maturity, this stage:
- Provides the first live field operation
- Operates “off of blocks” with skin and skid plates
- Includes first exposure of mechanics to realistic forces like dynamic forces on pillow blocks and loss of traction
- Supports characterization in representative environments such as characterizing E-Stop ranges
Tangentially, I’ll use these posts to catalog design thoughts and keep them relatively compact to support ease of production (and review.)
Design
The GARP will be composed of subsystems grouped into a “host” platform and payloads akin to the subdivision of modular cube sats:
The virtual backplane serves as a flexible means for connecting a variety of payload subsystems to shared power and data busses at a hardware level. Conversion across data protocols (e.g. I2C ↔ SPI) is required separately, but GARP will explore using ROS2 Control to execute these conversions as part of the Communication Subsystem as required.
Power Subsystem
The primary role of the Power Subsystem is providing reliable power at various voltages to the GARP. The subsystem is arranged around abstraction of a power “backend” with energy sources such as batteries from a power “frontend” with voltage rails:
The abstracted backend is composed of various power sources such as batteries or mains power along with type-specific adapters to convert the energy sources into an intermediate voltage (IV) rail. This then allows an array of subsequent converters to produce separate voltage rails for consumption by the platform. Other than the IV passthrough, this provides an optional additional layer of safety by selecting converters with over current and other protections, but at the expense of additional efficiency losses from the converter layer. Buck converters are expected to be fairly efficient (~95%) while operating at their rated power outputs, but can be significantly less efficient while operating below their rated powers. While not shown in the diagram, the various components should provide status to the C&DH via the data bus via (e.g.) a power management integrated circuit (PMIC).
Communications Subsystem
The Communications subsystem is composed primarily of the C&DH’s communication busses and hubs (e.g. USB, CAN bus, …) with little active “userland” activity for the early versions of the GARP. As the GARP matures, it is expected that additional conversions will be introduced such as using ROS2 Control to expose I2C and SPI sensors to the ROS2 DDS. That said, the data lines should be available to the system and should include:
- Ethernet
- USB
- CAN Bus
- SPI
- I2C
Command & Data Handling Subsystem
The Command & Data Handling (C&DH) subsystem is responsible for managing platform resources and providing data infil and exfil for the GARP. This should expose a UI for monitoring system status such as battery level or health statistics. The C&DH is also expected to host ROS2 Control for the Mobility Subsystem and various sensor payloads.
Mobility Subsystem
The Mobility Subsystem is primarily composed of the Motor Assemblies containing the motors and Motor Controllers:
The Mobility Subsystem also includes the mobility-related components on the C&DH such as ROS2 Control and the differential drive controller. In the most general terms, the components of the Mobility Subsystem will:
- Accept commanded (platform) velocities
- Convert commanded velocities to per-wheel (rotational) target velocities
- Transmit these target velocities to the Motor Assemblies via the CAN bus
- Control the motors to seek these target velocities
- Report actual velocities back via the CAN bus
Future capabilities could include motor health monitoring and status alerts like traction loss, or the addition of additional wheels, or Mechanum wheels.
Payload Subsystems
The Payload Subsystems are not constrained at this time, although Navigation and Perception Subsystems will be needed to support autonomy. These and other payloads will interface with the GARP through the virtual backplane for data and power access. These components are separated out as it is expected their processing and memory requirements will vary significantly from the C&DH. For example, the Perception Subsystem is expected to require a GPU or ML ASIC, whereas the C&DH is not expected to require this, and so the two subsystems are separated. This modularity also allows replacing the C&DH or Perception Subsystems with minimal impact to the other subsystem.
Summary
This post provided the high-level motivations for building the GARP while also introducing the currently-defined subsystems and their core roles and responsibilities. Functional descriptions of the subsystems were provided, and functional diagrams of the Power and Mobility Subsystems were provided. This article serves as an entry point to the series on the GARP, its design, and its implementation.
GARP Article Series
The Ground Autonomy Research Platform (GARP) is a home-grown UGV designed and built to support independent learning of robotics and autonomy through a full stack from hardware to behavioral autonomy and HMI. To document the implementation of GARP, I’m capturing the process in a series of articles that I’ll link here as they’re completed:
GARP Article Map
- Motivations and Design of a UGV for Robotics Research
- GARP Power Subsystem
- Design
- Alpha Implementation
- GARP Mobility Subsystem
- Motor Selection
- Subsystem Design
- Motor Controller
- C&DH
- Design
- Alpha Implementation
- GARP E-Stop
- Design
- Alpha Implementation
