Author: automaticaddison

Autonomous Agricultural Robot Systems Design & Architecture

In this tutorial, I will present a template for the system design and architecture for an autonomous agricultural robot. This template could be modified for designing any autonomous mobile robot. These requirements are not an exhaustive list.

System Requirements

Mandatory Functional Requirements 

Functional requirements define what a system must do. These requirements are typically specified by the user.

M.F.1. The system must accept a map of the farm.

M.F.2. The system must harvest wheat.

M.F.3. The system must detect static objects.

M.F.4. The system must detect dynamic objects.

M.F.5. The system must return to the home location after harvesting.

M.F.6. The system must indicate when fuel is low.

M.F.7. The system must generate an estimate of crop production, including acreage, area harvested, and yield.

Mandatory Non-Functional Requirements

Non-functional requirements define the constraints that impact how the system should fulfill the functional requirements. These requirements are typically specified by the engineer.

M.N.1. The system shall harvest 95% of crops on flat, unobstructed terrain.

M.N.2. The system shall send a notification when the fuel level gets to 5% of a full tank.

M.N.3. The system must cover 0.25 acres on flat, unobstructed terrain in 20 minutes.

M.N.4. The system shall navigate on a 15-degree sloped hill.

M.N.5. The system shall detect >99% of static objects greater than 0.3 meters in height and 0.2 meters in width.

M.N.6. The system shall detect >99% of dynamic objects greater than 0.3 meters in height and 0.2 meters in width.

Desired Functional Requirements

D.F.1. The system must generate a report of crop health.

Desired Non-Functional Requirements

D.N.1. The system shall navigate on a 25-degree sloped hill.

D.N.2. The system shall harvest 99% of crops on flat, unobstructed terrain.

Functional Architecture

functional-architecture-ros2

EKF = Extended Kalman Filter

Cyber-physical Architecture

The cyber-physical architecture maps the functional architecture to the hardware and software components of the robotic system. 

User Interface

Hardware

Software

Navigation

Hardware

  • On-board computer
  • Vehicle (Including Motors)

Software

Sensing

Hardware

Software

Manipulation

Hardware

  • Microcontroller
  • On-board computer
  • Vehicle

ROS 2 Architecture Overview

ROS 2 Architecture Overview

Below is a high-level diagram of the ROS 2 architecture.

ros-architecture

Data Distribution Service (DDS) Architecture Overview

ROS 2 uses DDS as its middleware. DDS reduces coupling, increases scalability, and improves performance, reliability, security, and flexibility. It is for this reason why it is common to see the DDS communication protocol used in the defense industry. 

Below is a high-level diagram of the DDS publish-subscribe communication protocol using an example robotics application.

dds-overview

Topics vs. Services vs. Actions in ROS2-Based Projects

ROS 2 has three main ways nodes (i.e. the individual C++ or Python programs that make up the robotics system you’re building) can communicate with each other.

Below I will detail the circumstances when you should use each of these communication methods.

Use Topics for Continuous Data Streams

Use topics when you have continuous data streams (e.g. sensor data, robot state, etc.). 

An example of a continuous data stream is laser scan data generated by LIDAR. Data will be continuously published on the topic as long as the robot is up and running.

1-ros-2-topics
Source: ROS.org

The data types used in topic-based communication are known as messages. Nodes publish messages via topics, and nodes subscribe to messages via topics.

You can use standard ROS 2 message data types, or you can create your own custom message data types.

Use Services for Quick Request/Response Communication

Services should be used for fast request/response communication. A Service Client node sends a request (typically for some data) to a Service Server node. The Service Server node then replies to that request with a response.

An example of a service is in this post where I call a service to load a new map once a robot has reached a new floor of a building.

2-ros-services-actions
Source: ROS.org

Use Actions for Long-Running Tasks That Have a Clear Beginning and End

Actions should be used for long running processes that have a clear beginning and end. An action is made up of a goal, interim feedback (to keep you updated on the progress being made to reach the goal), and a result.

An Action Client node sends a request (i.e. a Goal) to an ActionServer. The goal might be, for example, for the robot to move to a particular location in the environment.

The Action Server node gives the Action Client feedback on the progress it is making towards the execution of that goal (e.g. the robot’s most recent position along the path towards the goal location).

When the Action Server completes the goal, it sends a result message to the ActionClient.

3-ros-action-client-server
Source: ROS.org

That’s it! Keep building!