As you probably have realised, this system is composed of a significant number of pro-cessors ranging from basic embedded micro controllers to a quad-core processor. Each processor will be running some piece of software (in some cases proprietary) where time-liness is a factor. We now focus on the robot agent software running on the RP which is where the high-level robot control takes place and where your code will be running.
Towards the end of this section we also explain how the mission control software (run-ning at the workstation) operates, but since you will only use this software, not modify it, we keep this discussion very brief.
2.2.1 Robot agent software
The robot agent software is responsible for making the robot operate according to its specified mission. This software runs on the robot computer and uses the serial interface to the robot chassi to query sensors and send commands to control the movement of the robot. The robot agent is written in the C programming language and runs as a single process on the Raspberry Pi OS (formerly Raspbian). Figure 3 shows the software architecture of the robot agent.
Mission
Control Avoid Communicate
Navigate Refine Report
Tasks
Helper functions Robot agent
Task scheduler
Figure 3: Robot agent software
Tasks The tasks in the robot agent are pieces of code which each have a specific purpose and some temporal properties and requirements. We provide a high-level overview here, and refer to Appendix E for a more detailed description with pseudocode for each task.
The Mission task manages the overall mission of the robot which is essentially to search for victims and report found victims to the mission control centre. In particular, the mission task is responsible for keeping track of reported victims, and starting and stopping the other tasks. Stopping the tasks can for example occur because a stop message is received from the mission control. Mission control also generates and sends a stream data to Communicate task (right now stream data is just a randomly generated data, but in future it will be a video stream generated by a camera). Stream data is generated in a constant rate.
The Navigate task is responsible for determining the direction in which the robot should go. The navigation logic is based on a pheromone mobility model where each robot tracks its movement in a virtual pheromone map, similar to the way ants use pheromones on the ground to tell other ants where they have been. In the case of search and rescue, the existence of pheromones on the map will make the other robots avoid that area since it has already been covered. As time elapses the strength of the virtual pheromones decreases, allowing the area to be searched anew.
The Refine task uses the RFID reader to refine the robot positioning using the tags below the wooden surface that have known positions. The task queries the RFID reader for tags and checks whether the tag is a localisation tag. If the tag is recorded in the localisation database, then the particle filter is updated with this new information. The role of the particle filter is to combine the odometry location data available from the robot (see Control task below) with the RFID tag data through sensor fusion. If a tag is found which is not a localisation tag, then this represents a victim being found, so this information is forwarded to the Report task.
The Report task receives information about a found victim, it checks whether that vic-tim had already previously been reported. If not, then vicvic-tim information is given to mission task for victim registration and a message is sent to the Communicate task to send this information to the mission control centre (and display it on the operator screen).
The Control task is responsible for low-level communication with the robot. First the task reads the odometry (wheel encoder) sensor data from the robot and incorpo-rates this data in the localisation module (particle filter). Then it send the motor commands to the robot chassi with direction decided by the Navigate task.
The Avoid task is responsible for making the robot avoid getting stuck when running into obstacles. If the robot tries to go forward where it cannot, there is a high
risk of the motors being damaged. It is possible to detect this situation using the
“bump” sensor in front of the robot. The avoid task queries the bump sensor, and if it detects that the bump sensor is pressed, then it instructs the robot to turn to another direction. As robot can execute only one motor command, running Avoid task directly after Control task will override command sent by the Control task.
This also applies to inverse order: Avoid tasks motor command can be overridden by Control task.
Finally, the Communicate task manages all wireless communication by reading incom-ing messages and transmittincom-ing the messages generated by the other tasks in the system. Since the actual sending of messages occurs at lower layers in the commu-nication stack, the communicate task simply puts the messages on a queue without waiting for the messages to be transmitted.
Task scheduler The task instances are dispatched by the task scheduler which deter-mines the order in which tasks are run and how long to wait until the next task is run.
Note that the robot agent code runs as a single Raspberry Pi process which means the task scheduler in the robot agent has no possibility to preempt currently running tasks.
Helper functions Basic functions like communicating with the robot chassi and the RFID reader are implemented as helper functions. These encapsulate some of the low-level implementation-specific details, allowing the a more abstract implementation of the tasks. Some of these helper functions will be useful for your solution, and these will be described with a basic API description on the course web.
2.2.2 Mission control software
In order to control the robots from a mission level perspective, there is a mission control software that you will run on your workstation. This software serves two purposes. First, it shows the whereabouts of the robots on the field as they report it. What information is shown is dependent on the quality of the schedule you implement in the robot agent software. Second, the mission control software is able to start and stop the robots as well as to employ a continuous safety mechanism which only allows the robots to proceed if they are able to regularly report their location. This latter feature will be used in lab 2 when you will implement a form of real-time communication.
3 Instructions for lab sessions
In this section we will explain the detailed steps for each of the three labs, and the system requirements you will need to meet. Detailed instructions on how to setup the system will be given in Appendix D, on the course web and by your lab assistant.
3.1 Preparations
Before coming to the first lab session there you need to prepare by carefully reading this compendium. You should also familiarise yourself with the documentation appendices in this report which contain important information on how to handle the robots (Ap-pendix C) and how to get started with the lab skeleton (Ap(Ap-pendix D). Before the first lab session, we will also give an introductory lesson including explaining some of the practical issues.
In order to make sure that you have completed the above steps before the lab session, you are required to answer the preparatory questions provided in Appendix A by sending an email to your lab supervisor. Note, you need to do this at least three hours before your lab session starts. When you have passed this step, the lab assistant will send you the necessary information to start the labs.