Implementation of trajectory

[lemmer-fzi]

Describe the feature

For different use cases the concept of trajectories is needed. Therefore it is suggested to have a general implementation of trajectory (for example in the osi_common.proto). A major difficulty is that trajectories can be defined in different ways and on different layers of abstraction.

Describe the solution you would like

The minimal information a trajectory should contain for each state:

• Timestamo
• Position
• Orientation

Describe alternatives you have considered

Additional informations that could be added to a trajectory message:

• velocity
• acceleration
• orientational velocity
• orientational acceleration

[caspar-ai]

@lemmer-fzi thanks for raising!

This affects the work being done by me (WP10), @clemenshabedank (WP11) and @Krishna626 (WP14). I believe we are all happy with just containing the minimum information, i.e. time and pose. The velocity, acceleration can then be derived from those if required.

The addition of a StatePoint message which acts as a single point in a trajectory is being added under https://github.com/OpenSimulationInterface/open-simulation-interface/pull/409 although isn't in a common file. The move to place it in a common file and use it also in the MovingObject to a define a future_trajectory is covered by https://github.com/OpenSimulationInterface/open-simulation-interface/pull/401 and Krishna has started looking at using something identical in here: https://github.com/OpenSimulationInterface/open-simulation-interface/blob/WP-14-Agent-Model/osi_trajectory.proto#L51

Hope that is helpful! It would certainly be interesting if other places required additional information, otherwise, we are hopefully settling on a shared understanding.

[clemenshabedank]

I think what would be really valuable here, would be to learn how people implement trajectories. So are the alternatives @lemmer-fzi desribes ways to specify trajectories? Are there other ones?

Since I personally haven't been doing much with trajectory planning. I don't really know. As @caspar-ai writes, I also thought that a statepoint would be the lowest common denominator, therefore putting it into osi_common.proto and extending it in other messages which import osi_common.proto if needed.

[lemmer-fzi]

For communication between the simulator and a driving function a state point with positions is sufficient. For communication between a driving function and a motion controller their might be situations where you want to tell the vehicle to reach specific velocities, accelerations, orientations etc. This can be necessary if the distance between two state points is rather large. This could for example be done by defining a trajectory with MovingObject instead of StatePoint messages.

From my point of view their is no information necessary in a trajectory that is not present in MovingObject.

@ThomasNaderBMW Do you have any additional suggeestions what sould be in a trajectory? If i rember correctly you had some suggestions.

[Krishna626]

Hi @lemmer-fzi,

https://github.com/OpenSimulationInterface/open-simulation-interface/blob/WP-14-Agent-Model/osi_trajectory.proto#L51 reflects the idea we discussed in our last WP meeting. I am only concerned about the following question. What happens to the DesiredState message in case Trajectory option is activated in the simulation. Do we have to care about the content at all?

[caspar-ai]

@Krishna626 and @lemmer-fzi this is what I was mentioning about "oneof" feature: https://developers.google.com/protocol-buffers/docs/proto#oneof

Then protobuf itself forces you to only have one of desired state or trajectory set, and will automatically clear one if you set the other one.