Robobot architecture: Difference between revisions

From Rsewiki
 
(44 intermediate revisions by the same user not shown)
Line 1: Line 1:
Back to [[Robobot B]]
Back to [[Robobot B]]


==NASREM==
== Software block overview ==


The software architecture is based on the old NASREM architecture, and this is the structure for the description on this page.
[[File:robobot-in-blocks-2024.png | 600px]]
 
Figure 1. The main building blocks.


The National Aeronautics and Space Administration (NASA) and the US National Institute of Standards and Technology (NIST) have developed a Standard Reference Model Telerobot Control System Architecture called NASREM. Albus, J. S. (1992), A reference model architecture for intelligent systems design.
=== Software building blocks ===


[[File:nasrem.png | 700px]]
[[File:robobot-function-blocks.png | 600px]]


Figure 1. The NASREM model divides the control software into a two-dimensional structure. The columns are software function: Sensor data processing, modelling and behaviour control.
Figure 2. The main software building blocks.  


== Level 1 ==


[[File:robobot_level_1.png | 800px]]
==== Base control====
The 'base control' block is the 'brain' of the robot.


Figure 2. The lowest level in the control software. The encoder ticks are received form the hardware (from the Teensy microprocessor) in the sensor interface. The encoder values are then modeled into an odometry pose. The pose is used to control the wheel velocity using a PID controller.
The base control is an expandable skeleton software that is intended as the mission controller.
The desired wheel velocity for each wheel is generated in the mixer from a desired linear and rotational velocity.
The skeleton includes basic functionality to interface the Teensy board, to interface the digital IO, and to communicate with a Python app.


=== Hardware Teensy ===
The base control skeleton is written in C++.


The Teensy handles all the sensors connected to the microprocessor and the wheel motors as well as the up to 5 servos.
==== Python3 block====
Vision functions are often implemented using the Python libraries.


The sensor data is available as subscriptions with a constant sample rate. The sample can be specified in units of 1 ms.
The provided skeleton Python app includes communication with the Base control. The interface is a simple socket connection, and the communication protocol is lines of text both ways. The lines from the base control could be e.g. "aruco" or "golf" to trigger some detection of ArUco codes or golf balls.  
The USB connection has a bandwidth of about 4000 sensor messages per second.
The reply back to the Base control could be "golfpos 3 1 0.34 0.05" for; found 3 balls, ball 1 is at position x=0.34m (forward), y=0.05m (left).


All subscription requests start with the 'sub' keyword followed by the message key for the data type and the sample time in milliseconds, e.g:
The Python3 block is optional, as the same libraries often are available in C++, and therefore could be implemented in the 'Base control' directly.


sub svo 50
==== IP-disp ====


that subscribes to the servo status (for all 5 servos) every 50 ms.
Is a silent app that is started at reboot and has two tasks:
The Teensy interface will add the CRC and make sure it is received.
* Detect the IP net address of the Raspberry and send it to the small display on the Teensy board.
* Detect if the "start" button is pressed, and if so, start the 'Base control' app.


==== Teensy PCB ====


=== Teensy i/f ===
The Teensy board is actually a baseboard used in the simpler 'Regbot' robot.
This board has most of the hardware interfaces and offers all sensor data to be streamed in a publish-subscribe protocol.
All communication is based on clear text lines.


This is the Teensy interface controlling the USB interface to the Teensy.
See details in [[Robobot circuits]].


Commands to the Teensy can be sent in two ways, trusted or best effort.
==Software architecture==
The trusted commands await a confirmation from the Teensy, if this is not received within 30ms, then it is resent - up to 3 times. If still not confirmed, then the message is dropped (most likely the connection is dead or two applications are listening to the same USB device.
The 'best effort' tye is sent once only, this is the fastest communication - like motor voltage in a control loop. If one message is lost, then a similar value will be sent at the next sample time.


Both types are further secured by a simple CRC check.
The software architecture is based on the old NASREM architecture, and this is the structure for the description on this page.


All received messages are sent to the service module for decoding.
(The National Aeronautics and Space Administration (NASA) and the US National Institute of Standards and Technology (NIST) have developed a Standard Reference Model Telerobot Control System Architecture called NASREM. Albus, J. S. (1992), A reference model architecture for intelligent systems design.)
All outgoing messages use the send method in this module.


All communication on the interface can be logged.
[[File:nasrem.png | 700px]]


The module is coded in the steensy.h/steensy.cpp files.
Figure 3. The NASREM model divides the control software into a two-dimensional structure. The columns are software functions: Sensor data processing, modelling, and behaviour control.


The messages look like this - timestamped by the logging function
The rows describe abstraction levels:
* Level 1 with the primary control of the wheels for forward velocity and turn rate. This level also maintains the robot pose (position, orientation, and velocity, based on wheel odometry.
* Level 2 is drive select, where the drive can be controlled by just odometry (forward velocity and turn rate) or follow a line based on the line sensor. This level also includes other sensor detections like crossing lines and distances.
* Level 3 is where the overall behaviour is decided and includes camera sensor object detections like navigation codes and other objects.


% teensy communication to/from Teensy
=== Level 1; Pose and drive control ===
% 1 Time (sec) from system
% 2 (Tx) Send to Teensy
%  (Rx) Received from Teensy
%  (Qu N) Put in queue to Teensy, now queue size N
% 3 Message string queued, send or received
1687200276.5853 Tx ;75!setid robobot
1687200276.5853 Rx ;04hbt 47.9792 128 1581 4.64 0 7 74.1
1687200276.5866 Rx ;57# got new name (get with 'id')
1687200276.5867 Rx ;65confirm !setid robobot
1687200276.5869 Tx ;80!setidx 2
1687200276.5880 Rx ;70confirm !setidx 2
1687200276.5881 Tx ;47!idi
1687200276.5892 Rx ;37confirm !idi
1687200276.5893 Rx ;57dname robobot Sofia
1687200276.7838 Qu 1 ;01!sub enc 7
1687200276.7839 Qu 2 ;04!sub hbt 500
1687200276.7842 Qu 3 ;34!sub gyro0 12
1687200276.7842 Qu 4 ;78!sub acc0 12
1687200276.7842 Qu 5 ;37!gyrocal 0 0 0
1687200276.7842 Tx ;01!sub enc 7
1687200276.7853 Qu 6 ;81!sub svo 50
1687200276.7853 Rx ;90confirm !sub enc 7


The CRC is coded as two numeric characters that are the sum of all non-control characters in the message. The sum is reduced to two digits by a modulus 99 and 1 is added to avoid '00'. The two numbers are preceded by a semicolon ';'.
[[File:robobot_level_1.png | 800px]]
Messages that need a confirmation are queued and an '!' are added after the CRC code. The '!' is included in the CRC calculation.


Messages are coded as a character line, coded in 7-bit ASCII, i.e. no Danish characters.
Figure 4. The lowest level in the control software. The encoder ticks are received from the hardware (from the Teensy board) into the sensor interface. The encoder values are then modeled into an odometry pose. The pose is used to control the wheel velocity using a PID controller.
The desired wheel velocity for each wheel is generated in the mixer from a desired linear and rotational velocity.
The heading control translates rotation velocity to the desired heading and uses a PID controller to implement.


All messages are terminated by a 'new line', a '\n'.
More [[Robobot level 1]] details of the individual blocks.


== Level 2 ==
=== Level 2; drive select ===


[[File:robobot_level_2.png | 800px]]
[[File:robobot_level_2.png | 800px]]


Figure 3. At level 2 further sensor data is received, modelled and used as optional control sources.
Figure 5. At level 2 further sensor data is received, modeled, and used as optional control sources.
 
More [[robobot level 2]] details of the individual blocks.
 
=== Level 3; behaviour ===
 
[[File:robobot_level_3.png | 800px]]
 
Figure 6. At level 3, the drive types are used to implement more abstract behaviour, e.g. follow the tape line to the axe challenge, detect the situation where the axe is out of the way, and then continue the mission.
 
[[Robobot level 3 details]]

Latest revision as of 12:24, 1 January 2024

Back to Robobot B

Software block overview

Figure 1. The main building blocks.

Software building blocks

Figure 2. The main software building blocks.


Base control

The 'base control' block is the 'brain' of the robot.

The base control is an expandable skeleton software that is intended as the mission controller. The skeleton includes basic functionality to interface the Teensy board, to interface the digital IO, and to communicate with a Python app.

The base control skeleton is written in C++.

Python3 block

Vision functions are often implemented using the Python libraries.

The provided skeleton Python app includes communication with the Base control. The interface is a simple socket connection, and the communication protocol is lines of text both ways. The lines from the base control could be e.g. "aruco" or "golf" to trigger some detection of ArUco codes or golf balls. The reply back to the Base control could be "golfpos 3 1 0.34 0.05" for; found 3 balls, ball 1 is at position x=0.34m (forward), y=0.05m (left).

The Python3 block is optional, as the same libraries often are available in C++, and therefore could be implemented in the 'Base control' directly.

IP-disp

Is a silent app that is started at reboot and has two tasks:

  • Detect the IP net address of the Raspberry and send it to the small display on the Teensy board.
  • Detect if the "start" button is pressed, and if so, start the 'Base control' app.

Teensy PCB

The Teensy board is actually a baseboard used in the simpler 'Regbot' robot. This board has most of the hardware interfaces and offers all sensor data to be streamed in a publish-subscribe protocol. All communication is based on clear text lines.

See details in Robobot circuits.

Software architecture

The software architecture is based on the old NASREM architecture, and this is the structure for the description on this page.

(The National Aeronautics and Space Administration (NASA) and the US National Institute of Standards and Technology (NIST) have developed a Standard Reference Model Telerobot Control System Architecture called NASREM. Albus, J. S. (1992), A reference model architecture for intelligent systems design.)

Figure 3. The NASREM model divides the control software into a two-dimensional structure. The columns are software functions: Sensor data processing, modelling, and behaviour control.

The rows describe abstraction levels:

  • Level 1 with the primary control of the wheels for forward velocity and turn rate. This level also maintains the robot pose (position, orientation, and velocity, based on wheel odometry.
  • Level 2 is drive select, where the drive can be controlled by just odometry (forward velocity and turn rate) or follow a line based on the line sensor. This level also includes other sensor detections like crossing lines and distances.
  • Level 3 is where the overall behaviour is decided and includes camera sensor object detections like navigation codes and other objects.

Level 1; Pose and drive control

Figure 4. The lowest level in the control software. The encoder ticks are received from the hardware (from the Teensy board) into the sensor interface. The encoder values are then modeled into an odometry pose. The pose is used to control the wheel velocity using a PID controller. The desired wheel velocity for each wheel is generated in the mixer from a desired linear and rotational velocity. The heading control translates rotation velocity to the desired heading and uses a PID controller to implement.

More Robobot level 1 details of the individual blocks.

Level 2; drive select

Figure 5. At level 2 further sensor data is received, modeled, and used as optional control sources.

More robobot level 2 details of the individual blocks.

Level 3; behaviour

Figure 6. At level 3, the drive types are used to implement more abstract behaviour, e.g. follow the tape line to the axe challenge, detect the situation where the axe is out of the way, and then continue the mission.

Robobot level 3 details

Retrieved from "https://rsewiki.electro.dtu.dk/index.php?title=Robobot_architecture&oldid=6751"