Jupedsim 2025 Development

[Ozaq]

What should we work on in 2025

We have had more than one brainstorming about what we can do next but so far we did not put this down in writing or really committed ourselves to it.

I would like to open the discussion and at some point get us @chraibi / @schroedtert to commit to at least some development.

To be discussed

• Future of unofficial C-API
• Allowing model development in Python
• Distance maps for navigation

What else?

[chraibi]

Future of unofficial C-API

Removing an unmaintained layer would simplify the development workflow of JuPedSim.
Keeping things simple and tidy, we can talk about getting rid of other 'features' that aren't being used, like the dynamic geometry.

Allowing model development in Python

This would be huge!
Prototyping new models in Python would be a piece of cake compared to what we're doing now. Most of the time, people come up with crazy ideas and need to get a prototype up and running ASAP.
A prototype model might be a slow, but once we see that it's useful, we can fully integrate it into the C++ core.

Distance maps for navigation

This is very important! Triangulation was a simple and nice algorithm to get JuPedSim started. But, we know now, that we need a better solution.

Add a model template

Probably, adding a model template that automates much of the heavy lifting is charming! It could involve scripting tools to:

• Generate C++ Boilerplate:
  - Set up appropriate headers and source files.

• Create a Python API:
  - Expose C++ functionality to Python.
  - Include bindings for all parameters and methods.

• Documentation and Testing:
  - Add placeholder example, documentation and unit tests.

JuPedSim-visualizer

Is a good tool! However, it can be even great!
Many details can not be "seen", like for example the radius of the agents, their direction, and stuff that can be helpful for debugging and understanding the dynamics of the model.

Create a pyodide package

It would be great, for educational purposes, if we could run JuPedSim on the browser.
For that we would need a pyodid-package

[chraibi]

https://github.com/sir306/ProjectMobius

Last time I checked, it was still private!

[JetteSchumann]

Regarding the C-API:
Maybe we could have a separate SUMO-JuPedSim branch that contains the C-API for SUMO and JuPedSim functions that are available/configurable in SUMO. This way we are more flexible with JuPedSim and can decide what is relevant for SUMO and should also be available in the SUMO-JuPedSim branch.
Maintenance would be an issue here, as bug fixes and major changes in the code (such as the distance maps) need to be merged into this branch.

[JetteSchumann]

Distance maps:
In my opinion, navigation on distance maps should have the highest priority, as the routing does not work properly with complex geometries (with many obstacles). I have been using v1.1.1 so far. It often works better than 1.2.x, but there are similar problems with the triangles.

[JetteSchumann]

About the visualizer: I agree that the visualizer can become really powerful by adding some features, such as the actual size of the agent, agent ID, coloring by journeys, etc.
But of course it would be great if we could use Peter's tools.

[Ozaq]

@JetteSchumann yeah navigation should be priority one, fully agreed.

[Ozaq]

Direct setting of desired direction

Currently Jupedsim allows control over agent’s destinations by using journeys or “direct steering” both methods invoke our navigation and agents are steered around obstacles.

I would like to allow setting the desired direction directly through the api to allow prototyping of routing algorithms and enable modelers to have even more control over agent’s movements in the hope that this will enable them to simulate more complex behaviors

[Ozaq]

Jülich Copyright in Headers

So @chraibi I know you are not to keen on it either but I have to admit I do not want to contribute if I place my work under the Jülich copyright as in modify code with the Jülich copyright disclaimer. Also I think this discourrages external contribution even more so than the name.

I am well aware that I added most of the headers but this is what was given to us at the time by the "Software Leitlinie". We need to find a good solution here.

[chraibi]

This is a good point.
Probably we could do something as:

© (20YY) Forschungszentrum Jülich GmbH and contributors.
SPDX-License-Identifier: LGPL-3.0-or-later

And then acknowledge all contributors in CONTRIBUTORS.md.

Would that work for you, guys?

[Ozaq]

Fix minor API inconsistencies

• There is the 'v0' vs 'desiredSpeed' issue V0 vs desiredSpeed #1439 / V0 vs desiredSpeed #1441
• camel casing in python properties Social Force Model parameters use wrong naming pattern #1415

[ThoChat]

Implementing Humanoid Agent Paradigm

This will involve modifying the output file structure (to return the limb's position in time), the contact policy and the creation of a dedicated visualiser.
The idea so far is to implement it as another navigation model, but in the future it would be nice to be able to separate the navigation procedure and the body representation paradigm to make simulations more flexible.

[Ozaq]

You can already customise the output by providing your own serialiser, this does not just mean the format the output is written to but also the actual content. If your agent model exposes all the information about limb orientation / positioning you can directly serialise it however you like.

I am not sure if I understand your comment about navigation model. Can you elaborate a bit on this? What exactly do you think we should separate?

A dedicated visualisation is probably worth its own comment and following discussion.

[ThoChat]

Yes, I've already integrated a new serialiser to export limbs motion information. For now, I only work on my fork of the project as the model is not yet ready to be used, but the serialiser is going to be included in the final PR.

We discussed the part about navigation models last time we've seen each other, but it's a good idea to have this written indeed.
The thing is that this project is about a new spatial representation paradigm for agents, not a navigation model like all the other models that are on JuPedSim for now. However, for now, I'm implementing this humanoid shape paradigm as if it was an independent (navigation) model. (For the records, the navigation model implemented with this humanoid paradigm so far is the social force model.)
You recommended I start prototyping this representation paradigm as if it was a new model, since it would not involve any deep modification of the code structure. However, as this representation paradigm could be used with any navigation model, it would be nice to have them as two separate entities in simulations. This would enable the development of new features for the representation paradigm or new navigation models without having to create an extra model every time to merge the two concepts (i.e., the navigation model and spatial representation paradigm).
I hope this is clearer now. As often, I feel like the problem is: what concepts you place behind the word "model".

I do agree regarding the visualization!

[Ozaq]

So far my model definition is rather broad and contains many aspects. We consciously chose to make the models monolithic to allow for more radical differences between models. If we separate, what you referred to as "navigation" from the agents spatial representation we now have to ensure that navigation model and spatial representation model work together and agree on the same "contract".

Right now I think having just a big monolithic model is easier to maintain long-term and allows for easier addition of models. Also there are intermediate steps we can take, for example we can externalise the spatial representation code and reuse the same implementation over differnt models.

Edit: I definitely would like to see your new model added first as monolithic model. Having this makes any discussion about a possible separation much easier. Do you have any ETA? I personally would like to release a new 1.3 version with the AVM model soonish but think we can also wait a bit to include your model as well if we can get it done until March.

[Ozaq]

Multimodal Simulation

We had repeated discussions about multi-modal simulations, i.e. a simulation where different agents use different models.

Suggestion

The goal should not be to require every model to be compatible with every other model, although we should aim to provide it as complete as possible. Also we want to allow future models to be so different that they do not match our current expectations, hence compatibility should remain optional.

Since we are not certain how a possible solution should look like in the end I suggest to incrementally address the issue:

1. All currently implemented models read some state of their neighbours to compute their update. We need to identify the neighbour state each model relies on and document this / add this information to the model interface.
2. Extend the current implementation to work with multiple models if they already satisfy each other's neighbour state requirements.
3. Discuss on a case-by-case basis how the differences can be mitigated and prototype a possible solution. (I am pretty unsure right now how this could look, we need to list exactly where the issues are)