ITRI bus vehicle model

[WJaworskiRobotec]

Description

Preparation of properly working vehicle parameters model for ITRI Bus

Purpose

To be able to realistically simulate ITRI bus, both in E2E simulators and planning simulator

Definition of Done

• [ ] Parameters provided and tested with planning simulator and AWSIM

[WJaworskiRobotec]

ITRI parameters list

[sglee-morai]

Additional Parameters (for better dynamics)

Rigid Body

• mass (kg)
• drag coefficient
• position of center of mass

Tire

• Tire Peak Friction (Max Acceleration / Deceleration)

Steering Characteristic

• Inertia Bias (which affect whether car would likely to understeer / neutral / oversteer)
• maximum steering wheel angle (deg)
• maximum wheel angle (deg)

How testing is done (two test cases demo)

Youtube Link

[Igata-ctrl]

@WJaworskiRobotec @sglee-morai Tsutake-san @mitsudome-r Sorry, but I wasn't able to edit your comment above, so I'm pasting the correct (but in wrong unit) ITRI file here.

/**:
  ros__parameters:
    simulation:
      simple_planning_simulator:
        simulated_frame_id: "base_link"
        origin_frame_id: "map"
        vehicle_model_type: "DELAY_STEER_ACC_GEARED"
        initialize_source: "INITIAL_POSE_TOPIC"
        timer_sampling_time_ms: 25
        add_measurement_noise: False
        vel_lim: 30.0 kph
        vel_rate_lim: 30.0
        steer_lim: +/-900 deg
        steer_rate_lim: 280 deg/s
        acc_time_delay: 2 sec
        acc_time_constant: 0.5 sec
        steer_time_delay: 0.025 sec
        steer_time_constant: 0.5 sec
        x_stddev: 0.0001 # x standard deviation for dummy covariance in map coordinate
        y_stddev: 0.0001 # y standard deviation for dummy covariance in map coordinate

# Note: vehicle characteristics parameters (e.g. wheelbase) are defined in a separate file.

And this is the file which I sent to ITRI when I asked for the information (with unit description).

/**:
  ros__parameters:
    simulation:
      simple_planning_simulator:
        simulated_frame_id: "base_link"
        origin_frame_id: "map"
        vehicle_model_type: "DELAY_STEER_ACC_GEARED"
        initialize_source: "INITIAL_POSE_TOPIC"
        timer_sampling_time_ms: 25
        add_measurement_noise: False
        vel_lim: 30.0 # vehicle velocty limit [m/s]
        vel_rate_lim: 30.0 # limit of acceleration [m/ss]
        steer_lim: 0.6 # steering angle limit [rad]
        steer_rate_lim: 6.28 # steer angular velocity limit [rad/s]
        acc_time_delay: 0.1 # dead time for the acceleration input [s]
        acc_time_constant: 0.1 # time constant of the 1st-order acceleration dynamics [s]
        steer_time_delay: 0.1 # dead time for the steering input [s]
        steer_time_constant: 0.1 # time constant of the 1st-order steering dynamics [s]
        x_stddev: 0.0001 # x standard deviation for dummy covariance in map coordinate
        y_stddev: 0.0001 # y standard deviation for dummy covariance in map coordinate

# Note: vehicle characteristics parameters (e.g. wheelbase) are defined in a separate file.

[WJaworskiRobotec]

@sglee-morai We have a question about the parameters mentioned above : If all parameters are available to use in MORAI SIM ?

[sglee-morai]

@WJaworskiRobotec Sorry to post the answer to your question too late. Yes, MORAI can use all the parameters listed above to tune vehicles.

For example, values like vel_rate_lim, acc_time_delay, acc_time_constant values are used to tune parameters such as vehicle mass, engine inertia, torque map(engine speed vs. engine torque), gear ratio in MORAI SIM: Drive.

---

Just to give you a broader perspective; simulator providers can handle those values in a very different way. Let's consider the longitudinal vehicle model only for simplification.

[model 1]

• One can choose to implement a very simple model
  • model would be: [linear 1st order delay + dead time + saturation]
  • this model would directly use vel_rate_lim, acc_time_delay, acc_time_constant
  • pros: when vehicle motion isn't that important for simulation, this simple vehicle model will do the job perfectly
  • cons: when vehicle motion is important, this model isn't good enough.

[model 2]

• The other can choose to implement a more complicated model (MORAI way)
  • the model would be a combination of sub-models: [chassis model + engine model + transmission model + tire model]
  • complexity of each sub-model could vary a lot
  • the number of parameters that define each sub-model is much larger than 3 ( vel_rate_lim, acc_time_delay, acc_time_constant)
  • so the simulator should adjust those many parameters so that the resultant model would give a similar response to the simple model (model1) when given inputs like a step function, ramp function, etc.
  • pros: when vehicle motion is important, this is the way to go, obviously.
  • cons: when vehicle motion isn't that important for simulation, this can slow down simulation performance with minimal benefit

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity.