MOOS-IvP Cross Platform Software for Robotics Research

Transcription

1 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

2 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

3 MOOS framework contents: Core: IPC libraries, headers (C++) and apps Support applications and libraries: development and debugging tools geometry libraries logging Slide 3

4 MOOS Interprocess Comms Slide 4

5 Software architecture: Publish/Subscribe Centralized hub (MOOSDB) Slide 5

6 An example: GPS reader Position MOOSDB COMPASS reader Position, Heading, NAV Heading Slide 6

7 Variable MOOSDB Source Value Latitude GPS_Reader Longitude GPS_Reader New value Heading COMPASS_Reader 55.5 Update Publisher... Subscribers Slide 7

8 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

9 MOOSDB connections MOOSDB MOOS Apps ServerPort TCP Variables HTTP Server Slide 9

10 Mission files and pantler Slide 10

11 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

12 Community parameters Global scope: ServerPort ServerHost Community name... Process scope: AppTick CommsTick...(process-specific)... Slide 12

13 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

14 ServerHost=localhost ServerPort=9000 Community=example Globals Processes list ProcessConfig = Antler { run = NewConsole=false run = NewConsole=false ~ icputemp run = 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

15 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

16 Example <hw device> icputemp CPU_TEMP CPU_TEMP MOOSDB pcpumonitor CPU_HEALTH Slide 16

17 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

18 Building custom MOOS Applications Slide 18

19 Requirements: Support MOOSDB protocol Subscribe for selected variables updates Post own variables new values Compatibility with mission files Application timing (AppTick, CommsTick) Slide 19

20 MOOS Application States OnConnect StartUp Connecting Loop ondisconnect Slide 20

21 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

22 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

23 CMOOSApp customization Callback function can be overridden by derived classes Slide 23

24 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

25 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

26 Building a marine vehicle simulator Slide 26

27 THRUST POSITION_VECTOR RUDDER ELEVATOR simulator Parameters: Dynamic model coefficients Environment model Initial conditions Slide 27

28 HEADING RUDDER DEPTH SPEED ELEVATOR controller THRUST POSITION_VECTOR Controller parameters (PID,...) Slide 28

29 CONTROLLED VEHICLE Desired: - DEPTH - HEADING - SPEED controller actuators commands vehicle simulator Actual: - DEPTH - HEADING - SPEED state feedback Slide 29

30 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

31 Vehlcle Autonomy and the IvP-Helm Slide 31

32 autonomy PLANNING REACTIVE ACTIONS MISSION PHASES DESIRED_HEADING DESIRED_SPEED DESIRED_DEPTH controller vehicle (simulator) trajectory CONTROLLED VEHICLE Slide 32

33 BACKSEAT DRIVER FRONTSEAT DRIVER autonomy DESIRED_HEADING DESIRED_SPEED DESIRED_DEPTH controller vehicle (simulator) trajectory CONTROLLED VEHICLE Slide 33

34 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

35 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

36 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

37 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

38 Outputs reconciliation (example for 1 variable - course) Next waypoint obstacle Waypoint preference F1(h) = 45 F2(h) = Obstacle avoidance preference Slide 38

39 F1(h) + F2(h) = Input function to the optimizer PEAK VALUE IS FOUND OPTIMAL VARIABLE VALUE IS SELECTED Slide 39

40 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

41 IvP-Helm workflow YES GET NEW MOOS MSG NEW MAIL? NO RETRIEVE OBJ. FUNCTIONS RUN OPTIMIZER UPDATE INFO BUFFER OUTPUT DECISIONS Slide 41

42 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

43 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

44 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

45 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

46 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

47 Deploying the MOOS-IvP on a real vehicle Slide 47

48 Payload computer MOOS Interface process MOOSDB Vehicle Vehicle controller The link is vehicle-specific: RS232 RS485 CAN BUS TCP/IP Slide 48

49 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

50 Integration with other frameworks Slide 50

51 IvP-Helm & behaviours Behaviours updates MOOSDB commander Mode change New waypoints Change speed Change depth Slide 51

52 pjauscommander events JAUS Control Station UDP JAUS++ library feedback IvP-Helm updates MOOSDB status MOOS application Slide 52

53 Slide 53

54 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

55 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

56 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

57 Supported platforms - underwater efolaga (IT) (2012) Frontseat: x86 TCP/IP Backseat: ARM Missions: ACOMMS Slide 57

58 MOOS-IvP resurces Slide 58

59 Official repository svn co moos-ivp svn co moos-ivp-extend CMake build system ( Natively supported OSes: Linux Windows MacOS Portings for embedded ARM platforms (by CMRE users): Gumstix IGEP boards Slide 59

60 Thank you! Slide 60