feedback on the use of ros in the infuse project

Feedback on the use of ROS in the InFuse project Ellon PAIVA MENDES - PowerPoint PPT Presentation

Feedback on the use of ROS in the InFuse project Ellon PAIVA MENDES Pierre NARVOR Journe ROS - robots mobiles terrestres Clermont-Ferrand 4 Juillet 2018 The InFuse project " Infusing Data Fusion in

  1. Feedback on the use of ROS in the InFuse project Ellon PAIVA MENDES Pierre NARVOR Journée ROS - robots mobiles terrestres Clermont-Ferrand – 4 Juillet 2018

  2. The InFuse project " Infusing Data Fusion in Space Robotics " • One of six projects of Space Robotics Technologies SRC (Horizon 2020) • Aims to develop of a Common Data Fusion Framework (CDFF) building block • To serve through all SRC upcoming activities • LAAS is only involved with the planetary rovers (not the orbital track) • CDFF development • Absolute map-based localization • Alternative perception techniques (hyper spectral cameras, lidars, etc)

  3. What is CDFF? • Common Data Fusion Framework • Defines a functional architecture to integrate the data fusion process • that is flexible and generic • with clear inner and outer interfaces • expose products (maps and positions) • and algorithm models (to allow their control)

  4. CDFF functional architecture (outputs) (inputs) CDFF CDFF products 1. Acquired data • IMU • Images • Point clouds • … Environment 2. Initial data & models models • Orbiter maps Core processes • Satellite models • … 3. Knowledge • Terramechanics • Dynamics Internal data structures • … Poses

  5. Project constraints • ESROCOS should be used as Robot Control Operational System (RCOS) • Space oriented RCOS being developed in a parallel project • Problem: ESROCOS is not ready yet! → We decided to use ROS instead. • Data exchanged between nodes should be described using ASN.1 • Interface description language for defining data structures that can be serialized and deserialized in a standard, cross-platform way. • We decided to user ASN.1 over ROS messages.

  6. ASN.1 Communication interface • ASN.1 (Abstract Syntax Notation One) widely used communication standard. • Exchanged types defined in high level .asn abstract description files. TASTE-BasicTypes DEFINITIONS ::= BEGIN -- Set of TASTE predefined basic types T-Int32 ::= INTEGER (-2147483648 .. 2147483647) T-UInt32 ::= INTEGER (0 .. 4294967295) T-Int8 ::= INTEGER (-128 .. 127) T-UInt8 ::= INTEGER (0 .. 255) T-Boolean ::= BOOLEAN END

  7. ASN.1 Communication interface • ASN.1 (Abstract Syntax Notation One) widely used communication standard. • Exchanged types defined in high level .asn abstract description files. • ASN1SCC : ESA’s ASN.1 compiler for safety-critical embedded systems. • .asn compiled into C files with ready to use serialization functions TASTE-BasicTypes DEFINITIONS ::= #ifndef GENERATED_ASN1SCC_TASTE_TYPES_H BEGIN #define GENERATED_ASN1SCC_TASTE_TYPES_H -- Set of TASTE predefined basic types typedef int T_Int32; T-Int32 ::= INTEGER (-2147483648 .. 2147483647) T-UInt32 ::= INTEGER (0 .. 4294967295) #define T_Int32_REQUIRED_BYTES_FOR_ENCODING 4 T-Int8 ::= INTEGER (-128 .. 127) #define T_Int32_REQUIRED_BITS_FOR_ENCODING 32 T-UInt8 ::= INTEGER (0 .. 255) #define T_Int32_REQUIRED_BYTES_FOR_ACN_ENCODING 4 T-Boolean ::= BOOLEAN #define T_Int32_REQUIRED_BITS_FOR_ACN_ENCODING 32 #define T_Int32_REQUIRED_BYTES_FOR_XER_ENCODING 39 END flag T_Int32_Encode(const T_Int32* val, BitStream* Serialization pBitStrm, int* pErrCode, flag bCheckConstraints); flag T_Int32_Decode(T_Int32* pVal, BitStream* pBitStrm, functions int* pErrCode); ...

  8. Separation between "core" and ASN.1 • Core functionalities are being written into libraries • Libraries are wrapped in/used by a "main" program that may be written in Genom3 + ROS or pure ROS • ASN.1 related code stays outside the libraries • ROS is used as implementation middleware

  9. ASN.1 and ROS • Libraries use any internal representation for data (pcl, eigen, etc) • Data is converted from/to an according ASN.1 type • The ASN.1 type is converted to/from bitstream using asn1scc encode/decode functions • Bitstream is stored in a ROS message for output to/input from the middleware

  10. A single ROS message type ● Only one type of ROS message is exchanged between the modules # ROS common header std_msgs/Header header # Identification of the type : ASN.1 name string type # Serialisation method : 0 (uPER), 1 (BER), 2 (XER) uint8 serialization_method # Buffer with ASN serialised data uint8[] data

  11. ASN.1 Tradeoffs • Pros • International widely used standard, mature technology • Simple text notation for type definition with physical encoding rules • Independent from programming languages • ASN1SCC compiler : free, open-source, ready to use • Cons • ASN.1 ROS message used are not human readable • Extra computation overhead (to be assessed) • Some encoding limitations (e.g. NaN or Inf encoding missing)

  12. Integration with docker • Part of the project may be supplied as dockers images • Allow easy use of software with closed source code • Dockers communicate through ROS using the same type of ROS message

  13. Visualization with rviz • Rviz plugin implemented to decode and display data

  14. LAAS Rovers (not on Mars) Mana Minnie

  15. LAAS Rovers Hardware • Segway rmp400 and rmp440 platforms. • Six-axis IMU • (accelerometer, gyrometer, magnetometer). • One axis Fiber-optic gyro. • (100Hz, drift of 1 deg/hour after correction). • RTK GPS. • (20Hz, cm accuracy => corrections provided by a nearby base).

  16. LAAS Rovers Hardware • Lidar rover (Mana): • Panoramic Lidar velodyne HDL64. ● (Scan rate 5-20Hz, vertical FOV -24/+2deg, 1.4M points per second) • Vision rover (Minnie): • Panoramic Lidar velodyne HDL32. ● (Scan rate 10Hz, vertical FOV -30/+10deg, 700k points per second) • 1 NavCam stereo bench on a PTU. • Automotive Lidar ● High resolution point cloud, FOV 110x90deg. • 2 HazCam fixed stereo benches (front and rear)

  17. LAAS Rovers System Diagram GPS Base + Robot Wifi Station Base GPS Sick Stereo Controller Receiver Lidar bench 1 2 Industrial computers: Velodyne Stereo Operator - DEM Building Lidar bench 2 - Lidar-based SLAM - Visual Odometry Hyper- Stereo - Position Manager spectral bench 3 - Data fusion + server camera - ROS bags PTU Controller

  18. Feedback from trials at CNES • First tests performed during the last two weeks • (in fact mostly integration work … ) • Data acquisition in ROS bags with joystick controlled robots • Needed to have some ASN.1 translator nodes here and there... • Single ROS message + ASN.1 helped integration with partners (Magellium) • Detected some latency/bandwidth problems • Less point clouds in the bags than expected (need to investigate why) • Acquired datasets still being analysed.

  19. Conclusion • Not an optimal solution • ROS being used only as communication layer + debugging • Still a work in progress … • Some questions: • Could we generate .msg from .asn files? • Should we use nodelets to reduce message passing? • Are we doing something very wrong here? :)

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.


More recommend