Velocity and acceleration relative to host vehicle coordinate system seems to be missing

[fhirmann]

Describe the problem

I want to do sensor fusion with inputs based on OSI. The inputs would have been multiple sensors with type osi3::SensorData (with moving_object in it) and data of the host vehicle where I planned to use the type osi3::HostVehicleData with location.velocity and location.acceleration (no position has to be set as I do not need that)

At the description all data of HostVehicleData is stated as:

All coordinates and orientations are relative to the global ground truth coordinate system.

It also says that the field osi3::HostVehicleData::location is from GPS/GNSS/INS and therefore it is of course relative to some global (ground truth) coordinate system.

For my usecase it would be beneficial if there is a field which gives the velocity and acceleration relative to the host vehicle coordinate system. For me this seems also more the natural approach because in real world, the velocity and acceleration would often be measured by a wheel spin sensor and IMU, respectively.

Describe what you have already tried

All velocities and acceleration related to the host vehicle seem to be relative to global (ground truth) coordinate systems.

However, I am also unsure at osi3::SensorData::host_vehicle_location (documentation) what this should mean:

The parent frame of host_vehicle_location is the sensor frame.

At osi3::BaseMoving (documentation) the frame seems then to be different again, which confuses me:

All coordinates and orientations from ground truth objects are relative to the global ground truth frame. All coordinates and orientations from detected objects are relative to the host vehicle frame (see: MovingObject vehicle reference point).

I also checked a future extension of host vehicle data in issue #350 but here it also looks like the velocity and acceleration is relative to a global (ground truth) coordinate system.

Describe your research

• Checked documentation of osi3::HostVehicleData (documentation)
• Checked documentation of osi3::SensorData::host_vehicle_location (documentation)
• Checked documentation for other matching fields
• searched other similar issues and found osi_vehicle: A deeper description of a vehicle #350 which does not solve my problem

Ask your question

So my questions are now:

• What should be used for sensor fusion as input of host vehicle velocity and acceleration?
• Is velocity and acceleration of the host vehicle really never given relative to the host vehicle coordinate system?
• How would sensors like IMU and wheel spin sensor be included in OSI descriptions? (there seems no matching field in osi3::SensorData)

Many thanks in advance!

Additional context

none

[pmai]

Without getting into the remainder of the related questions, maybe there is some confusion as to the meaning of the term "relative"? Or in other words of course the host vehicle acceleration and velocity is given relative to the global coordinate system and not the host vehicle coordinate system, because relative to the host vehicle coordinate system they would always be 0.

The vehicle sensors for position/velocity/acceleration are giving values relative to the global coordinate system (ignoring for now that the vehicle might be moving on top of another vehicle, like a train/boat, which would make the global coordinate system for wheel-spin based sensors different than the "real/true" global coordinate system of a GPS sensor).

So to answer the questions under question:

• HostVehicleData is supposed to carry the vehicle's idea of what it thinks its position/velocity/etc. are, so that is what one would normally use as additional input to sensor fusion (if that is needed for ones fusion algorithm, e.g. if that is not using sensordata data to estimate such things).

• It would be 0, so that never needs transmission (but maybe there is a miscommunication at work here, since it seems obvious that this is not a useful coordinate system for vehicle data).

• Currently there is no specified way of how the data that ends up in HostVehicleData is being generated (i.e. there is currently no standardized way of having e.g. a separate IMU "sensor" model or GPS "sensor" model with GPS/IMUSensorView and GPS/IMUSensorData) since it is more or less assumed that this data is generated inside the vehicle physics model, and then made available directly to the other sensors via HostVehicleData. There could in the future be a standardized way for doing this, however the need for separate modeling and exchange of such models would have to be demonstrated.

[fhirmann]

Thank you for your fast and very informative response.

You are right, with "relative" I gave room for misinterpretation. In my case, I solely meant that the velocity and acceleration will be rotated into the host vehicle's coordinate system, i.e. the velocity/acceleration in x-axis will be along the driving direction and the velocity/acceleration in y-axis will be along the rear axle similar to the figure drawn at the documentation of HostVehicleData.

Will this be the case at HostVehicleData?

This would then mean that at the documentation of HostVehicleData I misunderstood it and

All coordinates and orientations are relative to the global ground truth coordinate system.

means that, only HostVehicleData::location::position and HostVehicleData::location::orientation are fully (including rotation) in the global (ground truth) coordinate system while all the other fields at HostVehicleData::location are rotated in the host vehicle's coordinate system (as described before). Am I right about that?

[pmai]

@fhirmann I think the illustration in the documentation is misleading at best. As far as I'm aware the location and orientation are to be in the global coordinate system, without any additional rotation (there is no place in OSI where we have in-between coordinate systems: Either it is global, vehicle-relative, or logical or physical sensor-relative), so I think the illustration was wrongly chosen...

[fhirmann]

@pmai Thank you for the clarification. Now I understand how the current implementation is intended. It is also nice to see that improvements are welcomed and that this discussion even led to a new bug issue to prevent other similar misunderstandings for new users.

For my original problem, I will then simply use HostVehicleData::location::velocity in combination with HostVehicleData::location::orientation to get the velocity rotated into the vehicle's driving direction.

From my point of view, I still find it unusual that the orientation is needed to get the velocity in driving direction but the current definition of the coordinate systems also makes sense for me.
Therefore I will close this issue and again thanks for the very fast help.