MOOS-IvP Cross Platform Software for Robotics Research Alberto Grati Engineering Department STO Centre for Maritime Research & Experimentation La Spezia - ITALY Lecture Series STO-SCI-271 Command and Reporting Standards and Associated Development Tools for UxS Portugese Naval Academy Lisbon, Portugal January 2015 Slide 1
Lecture overview Prerequisites: C++ programming shell scripting basic knowledge of sensors and actuators Objectives: MOOS software architecture and tools run simulations program autonomy write custom applications get/compile/install MOOS-IvP Slide 2
MOOS framework contents: Core: IPC libraries, headers (C++) and apps Support applications and libraries: development and debugging tools geometry libraries logging Slide 3
MOOS Interprocess Comms Slide 4
Software architecture: Publish/Subscribe Centralized hub (MOOSDB) Slide 5
An example: GPS reader Position MOOSDB COMPASS reader Position, Heading, NAV Heading Slide 6
Variable MOOSDB Source Value Latitude GPS_Reader 38.6676 Longitude GPS_Reader -9.1515...... New value Heading COMPASS_Reader 55.5 Update Publisher... Subscribers Slide 7
class CMOOSMsg { /**what kind of data is this? String,Double,Array?*/ char m_cdatatype; /**what is the variable name?*/ std::string m_skey; /** double precision time stamp (UNIX time)*/ double m_dftime; //DATA VARIABLES double m_dfval; std::string m_sval; std::string m_ssrc; std::string m_soriginatingcommunity; } Slide 8
MOOSDB connections MOOSDB MOOS Apps ServerPort TCP Variables HTTP Server Slide 9
Mission files and pantler Slide 10
MOOS Community: Set of related processes (share a single MOOSDB) Can run on multiple machines Mutual dependencies between processes Community health awareness (dead processes) Desirable to be prepared off-line and launched with a single command Slide 11
Community parameters Global scope: ServerPort ServerHost Community name... Process scope: AppTick CommsTick...(process-specific)... Slide 12
MOOS Mission file (Global section) (List of processes) Where is the MOOSDB Community name Executables to be launched Alias names (default to process name) (Process A block) (Process B block) (Process X block) Slide 13
ServerHost=localhost ServerPort=9000 Community=example Globals Processes list ProcessConfig = Antler { run = MOOSDB @ NewConsole=false run = icputemp @ NewConsole=false ~ icputemp run = pcpumonitor @ NewConsole=false ~ pcpumonitor } ProcessConfig = icputemp { AppTick=4 Process-specific CommsTick=4 blocks (...icputemp specific parameters...) } ProcessConfig = pcpumonitor { AppTick=4 CommsTick=4 (...pcpumonitor specific parameters...) } Slide 14
pantler MOOS processes mission.moos (reads own ProcessConfig block using its alias) Process command line: $ processname mission.moos processalias It's process own responsibility to get its parameters from the provided mission file (MOOS lib provides APIs) Slide 15
Example <hw device> icputemp CPU_TEMP CPU_TEMP MOOSDB pcpumonitor CPU_HEALTH Slide 16
uprocesswatch Detects dead processes Can publish per-process boolean still alive variables Integrated with uxms Some parameters: nowatch = <pattern> //example uxms* watch = <process> : <OK variable> //icputemp : CPUTEMP_OK summary_wait = <refresh period> //seconds Slide 17
Building custom MOOS Applications Slide 18
Requirements: Support MOOSDB protocol Subscribe for selected variables updates Post own variables new values Compatibility with mission files Application timing (AppTick, CommsTick) Slide 19
MOOS Application States OnConnect StartUp Connecting Loop ondisconnect Slide 20
MOOS Library: default MOOS application implementation #include "MOOS/libMOOS/MOOSLib.h" CMOOSApp::Run() CMOOSApp C++ class MOOSDB Connection handling StartUp Check incoming messages Do processing iteration Slide 21
The simplest MOOS application #include "MOOS/libMOOS/MOOSLib.h" CMOOSApp class EmptyApp: public CMOOSApp { }; int main(int argc, char* argv[]) { EmptyApp myapp; myapp.run("pempty", "mission.moos"); } EmptyApp Slide 22
CMOOSApp customization Callback function can be overridden by derived classes Slide 23
A more complete MOOS application #include "MOOS/libMOOS/MOOSLib.h" class EmptyApp: { protected: virtual virtual virtual virtual }; public CMOOSApp bool bool bool bool OnStartUp(); OnConnectToServer(); OnNewMail(MOOSMSG_LIST & NewMail); Iterate(); // TODO: add member functions definitions... int main(int argc, char* argv[]) { EmptyApp myapp; myapp.run("pempty", "mission.moos"); } Slide 24
Real World MOOS application should: read their own configuration block from the mission file; support standard command line (pantler conventions); register for MOOS variables... Better to use a script (and generate from a template)! GenMOOSApp <name> <type> Application name p = pure MOOS-to-MOOS u = utility i = interface Slide 25
Building a marine vehicle simulator Slide 26
THRUST POSITION_VECTOR RUDDER ELEVATOR simulator Parameters: Dynamic model coefficients Environment model Initial conditions Slide 27
HEADING RUDDER DEPTH SPEED ELEVATOR controller THRUST POSITION_VECTOR Controller parameters (PID,...) Slide 28
CONTROLLED VEHICLE Desired: - DEPTH - HEADING - SPEED controller actuators commands vehicle simulator Actual: - DEPTH - HEADING - SPEED state feedback Slide 29
MOOS vehicle simulator DESIRED_HEADING DESIRED_DEPTH DESIRED_SPEED pmarinepid (controller) usimmarine (simulator) NAV_HEADING NAV_DEPTH NAV_SPEED DESIRED_RUDDER DESIRED_ELEVATOR DESIRED_THRUST MOOSDB Slide 30
Vehlcle Autonomy and the IvP-Helm Slide 31
autonomy PLANNING REACTIVE ACTIONS MISSION PHASES DESIRED_HEADING DESIRED_SPEED DESIRED_DEPTH controller vehicle (simulator) trajectory CONTROLLED VEHICLE Slide 32
BACKSEAT DRIVER FRONTSEAT DRIVER autonomy DESIRED_HEADING DESIRED_SPEED DESIRED_DEPTH controller vehicle (simulator) trajectory CONTROLLED VEHICLE Slide 33
The IvP-Helm as back-seat driver vehicle state Back-seat driver phelmivp set points for: - heading - speed - depth Front-seat driver Behaviors set Slide 34
IvP-Helm behaviour VEHICLE POSITION BEHAVIOUR REQUESTS ANY SET OF MOOS VARIABLES CUSTOM BEHAVIOUR PARAMETERS (IN A CONFIG. FILE) An IvP behaviour is NOT a MOOS process!!! Uses phelmivp as gateway to/from the MOOSDB Slide 35
Key questions about an IvP-Helm behaviour How to request values for the decision domains (course, speed, depth)? How a behaviour's request will influence the final decision? How to gather information from the environment/vehicle? How is the workflow organized? Slide 36
Behaviour's output Behaviours may influence a subset of the decision domain (e.g. a simple waypoint behaviour might ask for heading only) Output is an objective function that expresses the usefulness of decision variables' values within their domains utility MAX course [deg] 0 H0 359 Slide 37
Outputs reconciliation (example for 1 variable - course) Next waypoint obstacle Waypoint preference F1(h) = 45 F2(h) = Obstacle avoidance preference 35 50 Slide 38
F1(h) + F2(h) = Input function to the optimizer PEAK VALUE IS FOUND 45 35 50 50 OPTIMAL VARIABLE VALUE IS SELECTED Slide 39
IvP Behaviors need some external information before being able to produce an objective function They do not talk directly with the MOOSDB IvP-Helm (a MOOS application) subscribes to MOOS variables requested by the behaviors and keep the values in an Info Buffer IvP-Helm InfoBuffer MOOSDB Slide 40
IvP-Helm workflow YES GET NEW MOOS MSG NEW MAIL? NO RETRIEVE OBJ. FUNCTIONS RUN OPTIMIZER UPDATE INFO BUFFER OUTPUT DECISIONS Slide 41
Example A waypoint behaviour influence the heading towards a sequence of preprogrammed waypoints at a specific speed (domain = course + speed) A constant-depth behaviour asks for a preprogrammed survey depth (domain = depth) A periodic-surface behaviour forces the vehicle to surface every 10 minutes to get a GPS fix (domain = depth) Slide 42
Behaviours run states Idle Running Completed Active The condition (if present) is met The behaviour declares to be complete The behaviour produces ojbective functions A condition (specified in the.bhv file) is not met Slide 43
Conditions Behavior = BHV_Waypoint { name = survey pwt = 100 points = (some points definitions) speed = 3 lead = 50 condition = (SURVEY_DONE!= true) endflag = SURVEY_DONE = true } example Behavior = BHV_Waypoint { name = return pwt = 100 points = 0,0 speed = 3 lead = 50 condition = (SURVEY_DONE == true) } Slide 44
Run flags A behaviour can post MOOS variables/values when it's in a specific state (idle, running, active, complete) Behavior = BHV_Waypoint { name = survey pwt = 100 points = (some points definitions) speed = 3 lead = 50 condition = (SURVEY_DONE!= true) endflag = SURVEY_DONE = true } Will post SURVEY_DONE = true when the last waypoint is reached (can be used to switch to another behaviour) Slide 45
Modes definitions To simplify the syntax of behaviour conditions in multi-phases complex missions, the IvP-Helm uses a syntax to define a MODE TREE Slide 46
Deploying the MOOS-IvP on a real vehicle Slide 47
Payload computer MOOS Interface process MOOSDB Vehicle Vehicle controller The link is vehicle-specific: RS232 RS485 CAN BUS TCP/IP Slide 48
MOOS interface process Subscribes for: DESIRED_HEADING DESIRED_SPEED DESIRED_DEPTH Translates IvP-Helm decisions into vehicle's format (usually NMEA) Publishes: NAV_HEADING NAV_SPEED NAV_DEPTH NAV_LAT NAV_LONG Parses vehicle response messages and extracts IvP-Helm usable information Slide 49
Integration with other frameworks Slide 50
IvP-Helm & behaviours Behaviours updates MOOSDB commander Mode change New waypoints Change speed Change depth Slide 51
pjauscommander events JAUS Control Station UDP JAUS++ library feedback IvP-Helm updates MOOSDB status MOOS application Slide 52
MOOS-IvP @CMRE Slide 53
Supported platforms - surface H-Scientific (UK) RHIB (2008) Frontseat: microcontroller-rs232 Backseat: Intel x86 Missions: Port Protection Sea Robotics (US) (2009) Frontseat: ARM-TCP/IP Backseat: ARM Missions: Port Protection, MCM Slide 54
Supported platforms - surface Sea Robotics (US) (2012) Frontseat: ARM-TCP/IP Backseat: x86 Missions: MCM, SONAR processing L3-Calzoni (IT) (2014) Frontseat: M68K-RS232 Backseat: x86 Missions: SAR (ICARUS Project) JAUS integration Slide 55
Supported platforms - underwater OEX-C Florida Atl. University (US) (2005) Frontseat: QNX x86 TCP/IP Backseat: x86 Missions: CASW, array processing Bluefin (US) (2011) Frontseat: x86 TCP/IP Backseat: x86 Missions: SAS adaptive survey Slide 56
Supported platforms - underwater efolaga (IT) (2012) Frontseat: x86 TCP/IP Backseat: ARM Missions: ACOMMS Slide 57
MOOS-IvP resurces Slide 58
Official repository (hosted @mit.edu) svn co https://oceanai.mit.edu/svn/moos-ivp-aro/releases/moos-ivp-14.7.1 moos-ivp svn co https://oceanai.mit.edu/svn/moos-ivp-extend/trunk moos-ivp-extend CMake build system (www.cmake.org) Natively supported OSes: Linux Windows MacOS Portings for embedded ARM platforms (by CMRE users): Gumstix IGEP boards Slide 59
Thank you! Alberto.Grati@cmre.nato.int www.cmre.nato.int www.cso.nato.int Slide 60