Support for vehicle dynamic models (e.g. CarSim)

[tanisxu]

As describe in title, vehicle dynamic model is important in car simulator. Is there any plan to add this feature?

[nsubiron]

Vehicles use Unreal's default vehicle dynamics, which is NVIDIA's PhysX vehicle model. For now we don't plan to support other models.

[nsubiron]

I have noticed there is already a CarSim plugin for UE4. It is only available for Windows and requires a licensed copy of CarSim, but it will probably make fairly easier the task of adding support for CarSim.

However, since we are primarily focused on Linux and CarSim is an expensive software, it's not a priority for us now to add support for it. Said that, we encourage anyone familiar with CarSim to give it a try and we'll be very happy to hear of any progress on that :)

[tanisxu]

@nsubiron Great plugin, thank you!! I've taken a look into it and wrote like at least four email to Mechanical Simulation to ask how exactly this plugin can be used because I can't even run their example project, seems it needs maintaining. Whatever, thank you !

[xie-dongping]

Just to hint there's an open interface widely used in simulation tools called Functional Mock-up Interface. It is also supported by CarSim.

So intergrating this model on the binary level could be done, provided that CarSim support an FMU export on Linux.

[awischnewski]

As an intermediate step to the introduction of full vehicle dynamics models:

Is it possible, to design a flat surface level and set the pose of the vehicle from an external vehicle dynamics simulation (relating to #280) ? This would enable the use of classic Real-Time HiLs for vehicle dynamics and chassis control and Carla can be used as an perception backend. I am aware the fact, that this approach does not allow to include physics simulation. Most likely, one would bypass the physx engine completly. However, taking into account that one would try to avoid crashes this might be a valid intermediate step. It would be possible, to simulate several evasion maneuvers and lane keeping scenarios on flat surfaces with arbitrarly detailed vehicle models (and up to 500 - 1000 Hz sensor devices)

This would enable to test full autonomous driving systems, including perception, planning and control.

[nievsamolina]

Hello @onethird !

Were you able to introduce in the simulator an other vehicle with different dynamics than the default ones? Or, in the other hand, to connect an external vehicle model (like, for example, Simulink tool)?

Thank you very much for your answer!

[lijecaru]

Hi @nievsamolina @nsubiron any news regarding this topic? I am also interested in implementing different dynamic models for the vehicles, and using Simulink would be a great way to do it.

[daohu527]

It seems that using a game engine to simulate environment, using carsim or other software to simulate a dynamic model is a better method.

The interaction of the two modules is a problem and they require a uniform interface and parameter definition.
It's a really good discuss about do better simulator!

[aakashsehgal]

So I have my own vehicle dynamic model which i want to integrate with CARLA. To integrate any vehicle dynamic model with any environment simulation model the following signals should be necessary : We feed into env.Sim(CARLA in this case) the position of the reference point in x/y/z, current heading, global roll and pitch angle. And from env.Sim we would need the intitial x/y/z position + initial heading/Roll/Pitch and current road gradient/banking...or if they deliver the z-position of each wheel we don't need the gradient and banking, this can be than calculated.

So now the question is if CARLA provides these attributes externally ?

[germanros1987]

Coming soon: Targeted as part of 0.9.10 sprint.

[svanimisetti]

I am looking at a pretty similar implementation as @aakashsehgal. I looked at the API and found VehiclePhysicsControl and WheelPhysicsControl can independently control the vehicle body and wheels - but I realized that the NVIDIA PhysX engine is used when installed through Vehicle actor initialization. Openloop controls is managed through VehicleControl. I was wondering if there is a way to position the vehicle body and individual wheel separately without using NVIDIA PhysX as I managed the vehicle dynamics externally? Currently, I have each of the wheels as a different actor and position/rotate it independently - this is less than an ideal solution.

@germanros1987 Could you detail on what is targeted as a part of the 0.9.10 sprint?

[germanros1987]

@svanimisetti this is not possible yet.

[KunanonxGithub]

So, for now, we cant use or adjust vehicle dynamic model except using NVIDIA PhysX engine which is default mathematical model for any vehicles in Carla. Am I wrong? Where can we look for vehicle dynamic model of any actors? Thank you for your help.

[jamesthurley]

I'm also very interested in this. We have our own C++ vehicle model which we plug in to various DIL simulator environments, rfPro, etc, and I'd very much like to get it working with CARLA as well. It would be great if the solution being worked on supported any external vehicle model via a well defined interface.

[s-hillerk]

This issue has the help wanted label and depending on what exactly this is about I'd be willing to help. Could you please detail on what your goal with this issue is exactly (i.e. which interface/standard you aim for, features, constraints on the implementation)? Is there already some work done?

[jamesthurley]

Hi @s-hillerk . As a starting point in the discussion, the following is a basic interface that is representative of what you might see for a driver-in-the-loop simulator. Implementing this interface, or one like it, would allow our model to be used in a particular simulator and to be driven by a human driver. For Carla the driver is an algorithm rather than a human, but the principle is the same. The inputs might or might not be different depending on how the control algorithm interacted with the particular vehicle.

In the interface below the Step function takes the Input data and the PositionAndVelocity data along with a set of pointers to output data, which are populated by the implementor using their vehicle model.

The PositionAndVelocity data is populated by the host when there is a collision, during which a simpler rigid body collision model would take over (provided by the host application), and our model would temporarily take positions and velocity from that system.

#ifndef DIL_GENERIC_INTERFACE_HPP
#define DIL_GENERIC_INTERFACE_HPP
​
#include <string>
​
#ifndef DllExport
    #define DllExport   __declspec( dllexport )
#endif // !DllExport
​
union Input
{
    struct
    {
        // These inputs vary depending on car type, could be 4 torque inputs, or 1 throttle, or individual brake torques etc.etc.
        double m_throttle_or_MPowerUnit; // rThrottle [0, 1]
        double m_brake;                  // rBrake [0, 1]
        double m_steeringAngle;          // aSteerWheel (rad, rightwards = +ve)
        double m_shiftRequestInput;      // shiftRequestInput (+1 = up, -1 = down, 0 = current gear)
        double m_drsActivation;          // rDRSActivation [0, 1]
​
        // These inputs are always required, regardless of specifics of car, they constitute the basic interaction with the world model
        double m_zTrackFL;             // zTrackFL (m, ISO, track height under wheel)
        double m_zTrackFR;             // zTrackFR (m, ISO, track height under wheel)
        double m_zTrackRL;             // zTrackRL (m, ISO, track height under wheel)
        double m_zTrackRR;             // zTrackRR (m, ISO, track height under wheel)
        double m_nTrackFL[3];          // nTrackFL0, nTrackFL1, nTrackFL2 (m, ISO, x-y-z-components of track normal under wheel)
        double m_nTrackFR[3];          // nTrackFR0, nTrackFR1, nTrackFR2 (m, ISO, x-y-z-components of track normal under wheel)
        double m_nTrackRL[3];          // nTrackRL0, nTrackRL1, nTrackRL2 (m, ISO, x-y-z-components of track normal under wheel)
        double m_nTrackRR[3];          // nTrackRR0, nTrackRR1, nTrackRR2 (m, ISO, x-y-z-components of track normal under wheel)
        double m_zTrackUnderTrayFront; // zTrackUndertrayFront (m, ISO, track height under chassis)
        double m_zTrackUnderTrayMid;   // zTrackUndertrayMid      (m, ISO, track height under chassis)
        double m_zTrackUnderTrayRear;  // zTrackUndertrayRear  (m, ISO, track height under chassis)
        double m_trackGripFL;          // rTrackGripFL [0, Inf] track grip under wheel
        double m_trackGripFR;          // rTrackGripFR [0, Inf] track grip under wheel
        double m_trackGripRL;          // rTrackGripRL [0, Inf] track grip under wheel
        double m_trackGripRR;          // rTrackGripRR [0, Inf] track grip under wheel
​
    };
    double m_inputs[_N_INPUTS];
};
​
struct PositionAndVelocity
{
    // these inputs are for collisions which are handled by a separate rigid body model, not the normal vehicle physics model.
    bool m_bTakeExternalPosVel = false;  // bTakeExternalPosVel, should we pay attention to the externally provided position and velocity inputs or not.
​
    // All externally imposed position and velocity components are ISO and use _intrinsic_ Euler angles
    double m_posExternal[3];
    double m_angPosExternal[3];
    double m_linVelExternal[3];
    double m_angVelExternal[3];
};
​
void DllExport Start(const char* carFilePath, double rhoAir, double v0, bool bManual, double* xyz0, double aYaw0, int CarType);
​
void DllExport Step(double dt,
    Input* pu,
    PositionAndVelocity* posAndVel,
    double* xyzCar,               // position of car CoG (m, ISO)
    double* dxyzCar,              // velocity of car CoG (m/s, ISO)
    double* d2xyzCar,             // accelertion of car CoG  (m/s2, ISO)
    double* aRollaPitchaYawCar,   // intrinsic euler angles of car (rad, ISO)
    double* daRollaPitchaYawCar,  // intrinsic euler angular velocities of car (rad/s, ISO)
    double* d2aRollaPitchaYawCar, // intrinsic euler angular accelerations of car (rad/s2, ISO)
    double* RCarWorld,            // orienation matrix of car in world coordinates (ISO)
    double* nEngine,              // engine speed (rad/s, used for sounds)
    double* NGear,                // gear number [-1 = reverse, 0 = neutral, 1:n = forward gears]
    double* MSteerWheelNoPAS,     // steering wheel torque (N/m, ISO)
    double* rSlipTyreFL,          // slip ratio of tyre [-1, Inf] (used for rendering skid marks/burnout marks/smoke)
    double* rSlipTyreFR,          // slip ratio of tyre [-1, Inf] (used for rendering skid marks/burnout marks/smoke)
    double* rSlipTyreRL,          // slip ratio of tyre [-1, Inf] (used for rendering skid marks/burnout marks/smoke)
    double* rSlipTyreRR,          // slip ratio of tyre [-1, Inf] (used for rendering skid marks/burnout marks/smoke)
    double* aSlipTyreFL,          // slip angle of tyre (rad, ISO)
    double* aSlipTyreFR,          // slip angle of tyre (rad, ISO)
    double* aSlipTyreRL,          // slip angle of tyre (rad, ISO)
    double* aSlipTyreRR,          // slip angle of tyre (rad, ISO)
    double* nWheelFL,             // wheel rotational speed (rad/s, +ve = rolling forwards)
    double* nWheelFR,             // wheel rotational speed (rad/s, +ve = rolling forwards)
    double* nWheelRL,             // wheel rotational speed (rad/s, +ve = rolling forwards)
    double* nWheelRR,             // wheel rotational speed (rad/s, +ve = rolling forwards)
    double* xyzHubFL,             // position of hub (m, ISO)
    double* xyzHubFR,             // position of hub (m, ISO)
    double* xyzHubRL,             // position of hub (m, ISO)
    double* xyzHubRR,             // position of hub (m, ISO)
    double* RHubFLWorld,          // orientation matrix of hub (ISO)
    double* RHubFRWorld,          // orientation matrix of hub (ISO)
    double* RHubRLWorld,          // orientation matrix of hub (ISO)
    double* RHubRRWorld,          // orientation matrix of hub (ISO)
    double* xyzUndertrayFront,    // position of undertray contact point (m, ISO)
    double* xyzUndertrayMid,      // position of undertray contact point (m, ISO)
    double* xyzUndertrayRear,     // position of undertray contact point (m, ISO)
    double* dxyzHubFL,            // velocity of hub (m/s ISO)
    double* dxyzHubFR,            // velocity of hub (m/s ISO)
    double* dxyzHubRL,            // velocity of hub (m/s ISO)
    double* dxyzHubRR,            // velocity of hub (m/s ISO)
    double* dxyzUndertrayFront,   // velocity of undertray contact point (m/s, ISO)
    double* dxyzUndertrayMid,     // velocity of undertray contact point (m/s, ISO)
    double* dxyzUndertrayRear,    // velocity of undertray contact point (m/s, ISO)
    double* telemChannelValues);  // list of telemetry output values (various - defined in csv produced by test exe)
​
void DllExport Terminate();
​
#endif // !DIL_GENERIC_INTERFACE_HPP

[svanimisetti]

@germanros1987 @nsubiron - I am reviving my question from last year (6/25/20). I see that the latest version of CARLA has CarSim integration incorporated into the binary release (0.9.13). This implementation seems to work fine for cases where CARLA and CarSim communicate exclusively. If I have other custom interfaces in CarSim, this arrangement does not seems to work well.

The CarSimMovementComponent implements GetAndApplyWheelRotationToTransform, but this is not exposed though the Python API. Currently, I am able to apply transforms to the vehicle body, and not the wheels. So, revisiting my previous question - can you provide Python API functionality to apply wheel transforms to CarlaWheeledVehicle? I am not sure if what I am asking is feasible, but I think there should be a more generic interface implemented - and made available via the Python API. I can explain the thought process in more detail if required - and would be more than happy to help in the implementation (I see the help wanted tag on the question).

[panpan-77]

@germanros1987 @nsubiron - I am reviving my question from last year (6/25/20). I see that the latest version of CARLA has CarSim integration incorporated into the binary release (0.9.13). This implementation seems to work fine for cases where CARLA and CarSim communicate exclusively. If I have other custom interfaces in CarSim, this arrangement does not seems to work well.

The CarSimMovementComponent implements GetAndApplyWheelRotationToTransform, but this is not exposed though the Python API. Currently, I am able to apply transforms to the vehicle body, and not the wheels. So, revisiting my previous question - can you provide Python API functionality to apply wheel transforms to CarlaWheeledVehicle? I am not sure if what I am asking is feasible, but I think there should be a more generic interface implemented - and made available via the Python API. I can explain the thought process in more detail if required - and would be more than happy to help in the implementation (I see the help wanted tag on the question).

Hi, I'm also very interested in it. Do you have any follow-up work for this?

[broflowsky]

@s-hillerk @germanros1987 Similarly to @jamesthurley, I'd like to use a Simulink model instead of PhysX for some of the vehicle physics. Any updates on a possible C++ interface for that purpose ? Thanks

[ajohnston356]

It’s been some time since anyone has commented on this. I am interested in testing Carla in a VI-Grade Driver-in-the-Loop Simulator using VI-CarRealTime for vehicle dynamics. Have there been any changes to the APIs that allow an external model to overwrite the Ego vehicle‘s position? Should I create a new feature request? Thanks!