Skip to content

Mission Planner: Requirements, Overview, Implementation

Jump to bottom Edit New page
Siddharth Kannan edited this page Jul 19, 2014 · 5 revisions

Mission planner documentation

Overview

Code must be modular. This makes changes fast and improvements understandable. The approach that we take to solve a problem must be structured and lucid. At no point, during the testing and runtime phase should the model go out of our control. This is the reason for the existence and the one of the requirements for a mission planner.

The vision and IMU sensors take control of the vehicle at appropriate times, but when the switch must take place is decided by the mission planner. This is one of the many things that the mission planner performs during runtime. The mission planner acts as a top-level manager for all the low-level code (such as the different tasks, changing depth etc). An example will illustrate this concept better.

Eg. As the vehicle enters the arena, from the approximately constructed pre-map, we know the approximate position of the Orange marker for the first task. The IMU stack now has control of the vehicle. As the vehicle goes close to the marker, the vision stack may have spotted the marker. This is a crucial moment. As it is not wise to allow all the code to interact with each other, at this moment the vision tack will give a pre-decided feedback to the mission planner, which will switch control from Imu to vision stack. Note that, this is the only task performed by the mission planner. It does not have any code that is related to any task. Once the control is switched, the vision stack will (try to) center the vehicle over the marker. When this is complete, the vision stack will again give feedback to he mission planner. Now the mission planner must trigger the code for the first task.

In this manner, the mission planner is the communication interface for all the code. It also holds a unique position, in the sense that it is the only stack which has access to all the other stacks.

Advantages

  • Structure A well defined and nicely modelled structure exists.

  • Easier to debug As all the communication goes through the mission planner, the debugging phase becomes logical and painless (instead of being confusing and frustrating, as is often the case , when debugging complex code).

  • Standardized Only the package kraken-msgs is used for the communication between the mission planner and other modules of code. Thus ensuring that a common standard is followed throughout.

  • Easier to understand As well be clear once you read the implantation subsection of this document,the mission planner is implemented as a finite state machine. This is a scalable concept and can be easily understood by all members of the team using a simple state diagram.

Implementation

Implementation overview

The mission planner is implemented as a finite state machine. An FSM can be in one of a finite number of pre-defined states. It is implemented in Python using Smach Library alongwith ROS capabilities.

Note that Smach is a library for Python and is independent of ROS.

Implementation of a State

Functions

Every state will have atleast two functions, __init__ and execute.

  • The __init__ function

This is the constructor of the object that is represented by the Class.

  • The execute function

This is the function that is called when the state machine transitions to this state.

Overall Process

  1. Inside every state, a SimpleActionClient will be declared. This client will wait for the SimpleActionServer to come online.

  2. Once the server and the client are online and connected, the client will send a goal to the server. While sending the goal, the client will also give a callback function to handle the feedback that will be recieved from the server. (Refer to doc on ActionLib for more details)

  3. When the goal has been sent to the server, the server will start trying to execute the goal. Throughout the execution, the server will also keep sending feedback to the client. This feedback will be channeled to the feedback callback function. And will be appropriately interpreted.

  4. Now the client will wait for predefined timeout. Once this timeout is elapsed, the server will stop executing the goal and send back a final result.

  5. Depending on the final result of the SimpleActionServer, the appropriate message is printed, and the outcome is sent to the state machine, so that the next transition can be decided.

External Links:

Plan

  • Describe how a state works

  • Describe how the transition takes place

  • Try to make complete state diagram

  • link to doc: action server: concept and implementation: separate document

  • the states in the mission planner and the state diagram

Add a custom footer

Networking and Setup

Clone this wiki locally