Construction of Mobile Robots Software

Transcription

1 Construction of Mobile Robots Software Institute for Software Technology 1

2 Referee Box I central game controller automatically controls the game time keeping game phases robot status orders machine status stand alone server interactive GUI (shell) communicates information periodically 2

3 Referee Box II different communication channels TCP/non-encrypted connection to GUI UDP/non-encrypted public general information to teams UDP/encrypted private information to/from teams modbus connection to the machines communication to GUI and teams is based on protocol buffer (protobuf) 3

4 Referee Box III source distribution contains a ready to use communication library (protobuf_comm) examples for peers and robot connections important messages Attention human interaction required Beacon alive signal for robot and referee box ExplorationInfo mapping lights machine type GameState information about the game MachineInfo available machines MachineCommands setup commands for machines OrderInfo orders to be processed various sub messages, e.g. time, pose 4

5 protobuf communication is based on protocol buffer (protobuf) library to serialize messages by google message description language compiler to generate serialization classes language and platform independent (C++, Java, python, ) network client-server communication based on protobuf messages simple standalone library by RWTH Aachen sending of messages receiving messages with registered callbacks 5

6 protobuf message 6

7 GRIPS Architecture - Overview RefBox Shell (GUI) protobuf TCP RefBox modbus MPS MPS protobuf UDP protobuf TCP Team Server OpenPRS OpenPRS protobuf TCP ROS Gateway ROS topics ROS Action Servers per robot 7

8 Team Server central control of the robot team handles all information from/to referee box game state machine info/setup orders maintains a knowledge base (game state, orders, machine state, ) a task network by using a planner triggers execution of tasks on robots integration of execution results relays messages of robots (heartbeat, machine setup) 8

9 abstract base class Planners need to implement 3 functions (waitforplannerinfos, createmissingtasks, generatetasklist) existing exploration planner partitions of zones assigned to robots explore one zone after each other individually existing production planner generate a task network for each order estimate the necessary start time (to keep the deadline) schedule a task network for execution once start time passes only one task network active at a time 9

10 Task Networks represents individual tasks and dependencies as a tree one network per order execution based on precondition relation between tasks tasks are mapped on OPRS procedures retrieve cap dispose base mount cap retrieve product deliver product retrieve base C1 product 10

11 LP/CSP scheduling and planning problems can be expressed as Linear Programming or Constraint Satisfaction Problems a number of description languages and solver exists commercial or academic MiniZinc powerful modelling language a lot semantic sugar mapping to existing solvers nice for prototyping (GUI, editor) Gecode efficient basis for constraint-based systems C++ library for integration in applications 11

12 Optimal Assignment Problem find m n non-negative integers x ij to maximize U x ij m i 1 j 1 m i 1 n j 1 n x x ij ij {0,1} x ij U 1 1 ij j j n i n i th agent will do one job j th job will be done by only one agent n m j are the weights for the prioritization of tasks 12

13 MiniZinc int: jobs = 4; int: machines= 4; array [1..jobs,1.. machines] of var 0..1: x; array [1..jobs,1.. machines] of int: costs = [ 90,75,75,80, 35,85,55,65, 125,95,90,105 45,110,95,115 ]; constraint forall(i in 1..jobs) (sum(j in 1.. machines) (x[i,j]) ==1); constraint forall(j in 1.. machines) (sum(i in 1..jobs) (x[i,j]) ==1); solve minimize sum(i in 1..jobs, j in 1.. machines) (x[i,j]*costs[i,j]); 13

14 Belief-Desire-Intention (BDI) popular architecture for agent control based on the explicit representation of propositional attitudes belief - what the agent knows about the world desire - pending goals, either percepts, messages or internal goals intention a set of plans chosen for (eventual) execution reacts fast simply matching of goals and intentions several intention may be active at the same time example: Procedural Reasoning System (PRS) we work with the OpenPRS implementation 14

15 BDI System Overview Sensors Beliefs Plan Library Environment BDI Reasoning Engine Goals Intension Structure Actuators 15

16 Working With OpenPRS I definition of symbols, predicates and actions best in a single file ( xxx.sym ), examples are in rcll.sym symbols: declare symbol xxx predicates: normal: declare predicate xxx, hold whenever asserted to knowledge base closed world assumption: declare cwp xxx, hold whenever asserted to knowledge base otherwise the negation holds evaluable predicates: not here automatically registered by dynamic library, dynamically derive their truth values using the code in the library actions: look like ordinary predicates not here automatically registered by dynamic library 16

17 Working With OpenPRS II definition of the initial knowledge base best in a single file ( xxx.db ), examples are in rcll.db just an enumeration of the predicates that holds in LISP syntax. e.g. ( (game running) (state robot1 active) ) 17

18 Working With OpenPRS III definition of plans (operational procedures) best in files ( xxx.opf ), examples are in move.opf OpenPRS is able to load several definition files each definition files may contain several operational procedures (OP) all Ops contain invocation: when is the OP triggered, single goal expression context: when is a triggered OP executable, set of expressions effects: what does the OP affect, set of goal expressions there are different types of Ops graphical: graphical representation of an OP textual: textual representation of an OP actions: simple OP without a plan body but a single executable action 18

19 Working With OpenPRS IV all definition can be loaded using include files best in files ( xxx.inc ), examples are in rcll.inc supported commands load external "library_name" "init_function", load a dynamic link library with actions and evaluable predicates, e,g. load external "libasrael_oprs" "init_asrael_oprs include "xxx.sym", loading the symbol/predicate definitions, e.g. include "./rcll.sym" load db "xxx.db", loading the initial knowledge base, e.g. load db "./rcll.db load opf "xxx.opf", loading a plan library, load opf "./rcll.opf" 19

20 Hookup C++ to OpenPRS I OpenPRS Interface for Actions (C++ dynamic library) Symbols Predicates robot-specific C++ code Interface for Evaluate Predicates (C++ dynamic library) Reasoning Engine Knowledge Base Interface for Evaluate Functions (C++ dynamic library) Plan Library 20

21 Hookup C++ to OpenPRS II OpenPRS allows to use external code to execute actions, evaluate predicates and functions realized using a shared library register all external code by a central function extern "C" void init_oprs_rcll(void) register actions make_and_declare_action("move", moveaction, 1); Term *moveaction(termlist terms) register predicates make_and_declare_eval_pred("see", see, 1, TRUE); PBoolean see(termlist terms) register functions make_and_declare_eval_funct( nrobots", nrobots, 1); Term *nrobots(termlist terms) 21

22 Executive Layer I to team server protobuf server OPRS goals Message Passing protobuf client OPRS evaluable predicates OPRS evaluable functions OPRS actions low-level actions reports and commands to refbox action execution reports to team server low-level queries protobuf server to ros interface protobuf client 22

23 OPRS actions Executive Layer II OpenGripper, CloseGripper, CheckLightState MoveToWayPoint, MoveToExplorationPoint FineAlignment, RawAlignmentSafe, DistanceAlignmentSafe SendTaskResult, SendFoundLightInfo, SendRobotInfo, ReportSeenMachines SendRobotStop ConfigureXX (XX = BS, RS, CS, DS) OPRS evaluable predicates lightstate, facemachine, seear OPRS evaluable functions getmachinename 23

24 Robot Operating System (ROS) framework for the development of robot software provides OS-like functionality originally developed by Stanford AI Lab (SAIL) and Willow Garage meanwhile maintained by the Open Source Robotics Foundation open source robotics framework used by several leading robotics labs provides a lot of functionality on various levels 24

25 provides a lot of functionality many research groups provide their results as open source ROS packages: motion planning and navigation localization exploration and mapping arm navigation and object manipulation 3D perception and object manipulation high-level control and knowledge representation 25

26 Transport Mechanisms (1) all architectures comprise different modules they need to exchange commands and data Publisher-Subscriber (Topics) messages are broadcasted multiple recipients components are usually not aware of each other central message routing (IPC, ROS topics) single point of failure Client-Server (Services - Blocking) components directly talk to each other components are aware of each other remote method invocation (RPC, CORBA, ROS services) + explicit return value 26

27 Transport Mechanisms (2) Client-Server (Actions Non Blocking) components directly talk to each other components are aware of each other remote trigger of durative activities on the server side + explicit status, error and return values 27

28 Tools in ROS rxgraph display a visualization of a ROS computation graph client library supports the development of nodes allows easy access to topics, paramter, C++ & Phyton rviz is a 3d visualization tool it is online configurable and is able to display sensor data, point clouds, paths, coordinate systems ROS is able to record and playback all topics in an transparent way and in the proper timing 28

29 Launch Files it s a pain to start up larger project form scratch at the command-line the tool roslaunch allows to script start up procedures allows to specify nodes, configurations, renaming follows a XML-syntax <launch> <param name="foo" value="$(optenv NUM_CPUS 1)" /> <param name= foofile" value="$(find foo_pkg)/foo.xml" /> <node name= foo" pkg= foo_pkg" type= foo.py" /> </launch> 29

30 robots usually have a number of data (2D and 3D senor data, poses, ) in various static and variable coordinate systems data in ROS are relative to a coordinate system called frame data stay in their producing frame data are transformed in a target frame on purpose only the tf library and a set of tools take care about transformations tf 30

31 Transformation Basics +Z yaw pitch +Y roll right hand rule +X roll, pitch, yaw Euler angles [x,y,z,w] ROS uses Quarterions 31

32 Transform Chains frames can build transformation chains tree-like structure transformation between any frames automatically calculated by tf if connected by a tree (a forest is possible too) map kinect frame laser frame plate frame [Andreasson et al. 2008] odometry frame base frame 32

33 Transformation Tree plate_link map kinect_base_link odom base_link laser_base_link odom base_link map plate_link laser_base_link kinect:_base_link 33

34 Reactive Layer to OPRS protobuf server protobuf client ROS interface conveyor allignment HOG detector gripper moveto AR checker set reference machine position report machines ROS action lib movebase 34

35 Robotino ROS Robotino offers a web-based (RPC) interface API allows access to all features of the robot API server runs on the internal PC a ROS interface node exists cmd_- vel topic gripper - service sensors - topics Robotino ROS Node API C++ Library web RPC demon external PC internal PC 35

36 Localization in ROS ROS provides a ready-to use localization stack the Adaptive Monte Carlo Localization (amcl) package laser-based localization particle filter localization (MCL) KLD sampling to control the sample size augmented MCL to recover from localization errors Sensor model beam range finder model likelihood field model Motion model sample-based odometry model (differential drive) sample-based odometry model (omni-directional drive) for usage and parameter look to the tutorial 36

37 amcl overview Map Server Laser Node initial pose/pose with covariance acml particles/pose array Robot Node odometry/odometry-tf 37

38 ROS Navigation Stack ROS provides a full navigation stack global planning A* and LPN local planning Dynamic Window Approach or Trajectory Rollout implemented as action service (non-blocking) supports differential drive and omni-directional robots works with and without global localization and map can work with 2d and/or 3d maps and sensors for usage and parameter look to the tutorial 38

39 ROS Navigation Stack Overview 39

40 Detecting AR Markers each machine of a team is labeled with a two distinctive AR tags on the input and output each tag represents a particular number alvar (a library for virtual and augmented reality) can track multiple tags a ROS package exists (ar_track_alvar) provides position and transformation of each detected tag in camera frame Cap Station Team Cyan Input 1 Cap Station Team Cyan Input 2 40

41 Gazebo Simulator high-fidelity simulator for robots and environments rich and accurate physics simulation a lot of libraries for robots, sensors, objects and environments separation of physical modelling and behavior neat integration of ROS 41

42 Grips Simulator II completely based on Gazebo uses RCLL simulation environment of RWTH Aachen communication independent connection to refbox automated loading of environment (machines, field) full functioning model of MPS (all machine types) basic model of robotino robot and common sensors adaptation for Grips architecture ROS interface abstraction of actuators and sensors multi-robot enabled by topics name prefix plugin based 42

43 RefBox RCLL Environment Models Grips Simulator II ROS interface localization (amcl, abstracted) topis ROS interface robot topics plugins MPS Robot 1 actuators, sensors Robot 2 actuators, sensors Robot 3 actuators, sensors Gazebo API & topics ROS interface lidar topics ROS interface cameras topics ROS interface gripper (abstracted) actionlib ROS interface light detector (absracted) actionlib 43

44 ROS Build System - catkin catkin official build system of ROS Cmake with some custom Cmake macros and Python scripts supports for automatic 'find package' infrastructure and building multiple, dependent projects at the same time simplifies the build process of ROS s large, complex, and highly heterogeneous code ecosystem advantages of using catkin enables to use packages after building (without installation) generates find_package() code for your package generates pkg-config files for your package handles build order of multiple packages handles transitive dependencies 44

45 package.xml Overview of a catkin package contains the meta information of a package name, description, version, maintainer(s), license opt. authors, url's, dependencies, plugins, etc... CMakeLists.txt The main CMake file to build the package Calls catkin-specific functions/macros "Read" the package.xml find other catkin packages to access libraries / include directories export items for other packages depending on you 45

46 Dependency Management: package.xml (c) ETH Zürich 46

47 Dependency Management: CMakeLists.txt (c) ETH Zürich 47

48 Other common files in a package Common source layout include/pkgnamespace/ src/ setup.py ROS specific subfolders msg/ srv/ launch/ scripts/ the recommended folder name equals the package name 48

49 Recommended Literature Murphy: Introduction to AI Robotics Thrun, Fox, Burgard: Probabilistic Robotics ROS Wiki ( ROS Tutorials Robotics Wiki at IST ( RoboCup logistics League OpenPRS Gecode PDFs for download at the course website 49