Skip to content

Latest commit

 

History

History
174 lines (129 loc) · 11.5 KB

README.md

File metadata and controls

174 lines (129 loc) · 11.5 KB
Raw


IPG-ROS workspace

BCN eMotorsport

Table of Contents
  1. Introduction
  2. Disclaimer
  3. Dependencies
  4. CM Node
  5. Tracker
  6. Others
  7. Workflow
  8. Parameters
  9. Noise
  10. Known Errors

Introduction

Here you can find the ROS workspace used for ROS + IPG simulation. The way this simulation works is quite simple. IPG CarMaker software is based on some pre-compiled c/c++ libraries. The way IPG lets us connect our ROS environment to their simulation workflow is through what they call the CMRosIF (Car Maker ROS Interface). This interface is basically a shared library so we can override the functions we know IPG will call before, during or after the simulation. We can find this interface in cmrosutils.

Disclaimer

If you use this simulation pkgs the only thing I ask for is to ALWAYS REFERENCE the team BCN eMotorsport.

Dependencies

CM Node

This pkg is the one to change if some new functionalities are needed. Within this node a class which inherits from CarMakerROSInterface have been declared. Inside this class we override some of the functions that IPG library calls.

This node is the one that enables us to access to all the IPG simulation data as well as to include user-defined functions into the internal logic of the simulation.

For now on the most relevant CM jobs defined are:

  • Publishers (CMJob::RosPublisher):

    • CAR STATE: this job is defined so we can retrieve car state information from IPG data and publish it via /carmaker/state. We also publish base_link TF with this data.
    • LIDAR: this job is defined so we can retrieve the LIDAR sensor pointcloud and publish it via /carmaker/pointcloud. We also get the current LIDAR position relative to the car and publish a lidar TF.

  • Subscribers (CMJob::RosSubscriber):

    • COMMANDS: we define two jobs for car commands subscribers. One is listening to /AS/C/commands topic for throttle commands and the other one to /AS/C/steering for steering commands. If only one controller for throttle AND steering is used Config/LateralCtrl should be false. Steering + Throttle should be published on /AS/C/commands.

Have a look at cmode.h for more information.

Tracker

This pkg is the one that publishes the chosen Track/Circuit as well as it keeps track of seen cones (that's why its called that way :) ). The main idea for this pkg is to be able to simulate the AS Control pipeline without using the LiDAR raw data from IPG. It is an "elegant" way of keeping the simulation light (so it can be used in a low performance computer) and having similar results.

NOTE: If simulated LiDAR raw data is needed for some reason a LiDAR RSI sensor must be defined using IPG GUI. This repo holds the necessary code to be able to detect whether a LiDAR is being used and publish its raw data via /carmaker/pointcloud topic.

This pkg is divided into two different nodes:

  • tracker_start: it reads the chosen track from the yaml files and publishes its cones in /carmaker/track. It is defined in start.py.

  • tracker: it reads the whole track published by tracker_start and fakes a perception pipeline so the cones keep appearing depending on the car's position and orientation. There are some parameters to adapt this faking perception pipeline to your needs: radius, vision_angle and likelihood. You can find them here. You can also add some gaussian error to this cone appearance in order to improve its correlation with a real perception pipeline of BCN eMotorsport :)

This pkg also has THE launch file called by IPG when its GUI is started. This launch file runs both nodes and sets all necessary parameters.

EXTRA: This pkg also keeps count of the hit cones ( via /carmaker/conesdown ) and it has its own lapcount, meaning it publishes the laptimes updating them with the penalties for each cone down (+2s). This laptime is published in /carmaker/lapinfo. Finally, it also updates the cones positions if they're hit by the car (just because its cool). The moving cones are published by tracker_start, a node ment to run at a really low freq. If you want to get a fancy and faster update of the moving cones increase its frequency.

Others

Other pkgs just like camera_msgs or carmaker_rsds_client are currently not used. They are kept within this repo in order to be used in a near future.

Workflow

Here you can see an example workflow of this workspace with tracklimits, planner and controller algorithms running (urinay, palanner and tailored_mpc respectively).

workflow

Parameters

Here you can find an explanation to the multiple parameters set for this simulation as well as the different launch files. The explanation will be in order of execution.

  1. tracker.launch : This is the main launch file called by IPG when Extras > CMRosIF > Launch & Start Application is clicked. Within this launch file we can find the following parameters:

    • track_name : where you have to specify the track you want to run. All available tracks are inside tracks folder. Have a look and choose one :).
    • use_sim_time : pre-defined ROS param. We set this to true as we want IPG to have control over ROS time, so we can stop (F2) and restart the simulation.

    This launch file also runs tracker_start & tracker nodes (see Tracker section for more info).

    • Topics : Input & Output topics
    • Service : Srv topic name
    • Noise : Mean and Std for the added Gaussian error to the cone positions.
    • Detection : Cone detection Radius, VisionAngle and Likelihood for the fake perception pipeline.
    • Lapcount/MinVel : Lapcount parameters (min vx to consider the car started moving).
    • BoundingBox : BB for car-cone collision check. Different from vehicle dynamics car dimensions in that these should include aerodynamic devices.
    • ConesMoving : whether you want to move the hit cones.
    • cone_daes : Whether we want to visualize the cones .dae files. If false, cones markers will be cylinder shaped.
    • freq : start.py frequency. If you want to move cones when they're hit by the car, you should increase this frequency up to 10Hz.

  2. cmnode.launch : This launch file sets the cmnode.yaml file to the param ROS srv. Within this yaml file we can find the following parameters:

    • Config :

      • LateralCtrl : whether we are using a high level lateral control pipeline or not. In other words, if we are using two different AS controller (longitudinal and lateral) or we have a coupled solution (one only controller).
      • Driver : whether we want to use the IPG driver or not (true for manual or false for autonomous).
      • HidraulicBrake : whether we want to use Hidraulic Braking or not.
      • EBS : whether we want to switch on EBS braking when in finish state or not.
      • LLC : whether we are simulating with Low Level Control :
        • 0 == false.
        • 1 == motor control via torque commands.
        • 2 == motor control via angular velocity commands.
      • 4WD : whether we are using 4 Wheel Drive (true) or 2 Wheel Drive (false).

    • Noise : Mean and standard deviation for the added Gaussian noise to the sensors.

    • Steering : Here we can find the MAX and MIN dynamic limits of the steering (in wheel frame). These are needed because IPG steering controllers need the commands in steering wheel frame, so a linear interpolation from high level controller commands (wheel frame) to final steering wheel angle is made.

    • Subscribers : Here we can find all the topics that cmnode will be subscribed to. For each topic we have its value (string) and its frequency (yes, in IPG we must specify a cycle time for subscribers).

    • Publishers : Same as Subscribers but for all the topics that cmnode will be publishing.

Noise

IPG sensors have very little error, in fact you can actually integrate/derivate their IMU/Odom data and expect to have accurate results on velocity/position estimation. That's not possible with real car data. Because of that, Gaussian noise (Random Walk) is added to IMU and Odom sensors in order to work with a more realistic environment.

For the moment only /carmaker/state topic has this Gaussian noise added to its velocity and acceleration output.

A part from that, Gaussian noise is also added to the "detected" cones seeking a better correlation with a real perception pipeline.

Known Errors

Here all known errors/issues will be written down with their solution (if it can be solved ;) ).

⚠ Time-out

Sometimes (after simulating for a long time) IPG GUI starts to lag and time-out errors raise as it is taking so long to start the application.

Solution:

  • Open Ubuntu System Monitor program and look for CarMaker.linux64 process. There should be only one process called that way. If there are more than one end all processes called that way and restart IPG GUI.

⚠ New node registered with same name [cmnode]

A ROS warning with this message:

[ WARN] [1680943413.460482209]: Shutdown request received.

[ WARN] [1680943413.461420181]: Reason given for shutdown: [[/carmaker/cm_node] Reason: new node registered with same name]

is printed in the terminal where ./CMStart.sh is run and you cannot start the simulation because of a CarMaker time-out error.

Solution:

  • Open Ubuntu System Monitor program:
    • Look for CarMaker.linux64 process. There should be only one process called that way. If there are more than one end all processes called that way and restart IPG GUI.
    • Look for a process called apobrokerd. If there is a process called that way, probably Ubuntu has killed IPG simulation because something wasn't working as expected. End this process.
  • If the above solution doesn't work, the last thing to do is reseting your computer. This always fix this issue.

NOTE: An alternative of openning System Monitor is running pkill command on a new terminal specifying the name of the process you want to end/kill.