Obstacles and avoidance of obstacles

[dunefox]

I need to simulate agents moving around between points in a certain environment to generate log files according to their contacts (under, say, 1.5 meters generates a log entry with the agent ids): similar to this https://jaantollander.github.io/crowddynamics/multiagent.html#field.

Is this possible currently?

[Datseris]

Hi, no this is not possible "out of the box".

---

Of course you can do everything manually yourself there isn't any inherent limitation from Agents.jl.

You can e.g. create an array that is as large as your grid and has 0s if there is no obstacle and 1s if there is an obstacle. Then it is possible to manually check the distance of Agents from obstacles. Notice however that your description is not adequate for me to understand exactly what you want to do:

to generate log files according to their contacts (under, say, 1.5 meters generates a log entry with the agent ids):

I just cannot imagine what this means and need more information.

[dunefox]

I should have mentioned that I need a continuous simulation, not a grid.

Basically I want to check if two or more agents are closer than 1.5 meters to each other (this should be easy with interacting_pairs(model, 0.015, :all), I think). If this happens I want to log the agent ids and the duration.

Ideally, I would like to have spawn points, target points, and obstacles as well having agents move between the points. Imagine a corona simulation with an event log if people come closer to each other than 1.5 meters. I hope it makes more sense now.

[Datseris]

I see. From what you have said so far, there is only one thing not possible: Automatically avoiding obstacles. The rest you can already do with the API of Agents.jl. As you said interacting_pairs(model, 0.015, :all) gives you what you want, while you can simply orient the agent's velocity to their "target" and then move_agent!.

So yeah, entities that are "obstacles" and "automatically calculating trajectories that avoid them" would be super cool to have, but I fear that it will take considerable development effort (and also the skills to do it, I think this path findingalgorithms like A*) .

[Datseris]

Relevant links from the crowddynamics repo:

https://github.com/jaantollander/crowddynamics/tree/master (seems not active anymore)

https://jaantollander.com/post/how-to-implement-continuous-time-multi-agent-crowd-simulation/ (some blog with guidance/discussion on how to do crowd dynamics)

[Libbum]

Two libraries that may be of assistance here: ConvexBodyProximityQueries CurveProximityQueries https://github.com/JuliaRobotics/EnhancedGJK.jl

[dunefox]

@Datseris Thanks for the links. Regarding the pathfinding: Since I'm under time constraints I don't believe I can implement the logic myself, but I may have to do it anyway. I also found crowddynamics and it seems better for my purpose but I'd still need to adapt it and I'm not yet sure how much effort that takes either.

@Libbum Thanks, although I'm not quite sure how to combine Agents.jl and such a 'foreign' library in practice yet. I'll look into that.

[Libbum]

@dunefox yeah, I'm not sure either just yet.

But this is something we'd like to put into Agents at some stage in the future & it's worth tracking some of the packages that may be of assistance.

My assumption is that we can either use a direct query to a set of convex bodies at each step (the first package), or (if our agents movement is differentiable), generate a path and predict any future interception (the second package). Will have to look into it more thoroughly myself though.

Concave objects are more problematic, so I doubt we''ll be able to cover them with this algorithm at least.

[rmcsqrd]

@dunefox @Libbum An alternative to using a path planning algorithm is something like force based motion planning: https://arxiv.org/pdf/1909.05415.pdf

At a really high/over-simplified level it treats agents like magnets. As agents get closer to each other they experience a repulsive force that is proportional to their proximity. It also has a navigational component built in as well. This video from the above paper is pretty illustrative: https://drive.google.com/file/d/1Od3DK8_4YCIWoQgMfgpfglm_1sMBB6NF/view

I am working on implementing this algorithm for my MS thesis. Is this something that might be useful with this issue? This package has been awesome to use so far - happy to hear any thoughts/suggestions of how I can help out. I am specifically interested in if you think this would be more suited as an example project or some sort of core package functionality.

[Datseris]

Hi there,

great to see you interested

I am working on implementing this algorithm for my MS thesis. Is this something that might be useful with this issue? This package has been awesome to use so far - happy to hear any thoughts/suggestions of how I can help out. I am specifically interested in if you think this would be more suited as an example project or some sort of core package functionality.

Much functionality starts as a contiguous example, and from there it becomes part of the API. This is e.g. what is currently happening for the OpenStreetMapSpace. My suggestion would be to make a simple toy example that works and open a PR adding it as an actual example. Then we discuss on this PR how we can make this part of the main API, if that is possible?

[rmcsqrd]

@Datseris the examples/FMP.jl file in #412 should provide that toy example you mentioned. Let me know how you would like to proceed in terms of potentially "upgrading" it from an example to part of the API. I'm fine following your direction and would be happy to spearhead the "upgrade" initiative if you decide you want to go that direction.

That said, I am torn if it makes sense to include as part of the API. Although it does provide obstacle avoidance as requested in the original issue, it is a fairly niche algorithm and might best be suited as a standalone package that tightly integrates with Agents.jl. Thoughts/comments?

P.S. Sorry for the many issue references - I am new committing to non-personal project repositories and got a little sloppy.

[rmcsqrd]

Just for the record this is what the output looks like - the generated gifs from the example have a faster frame rate, github slowed it down upon upload for some reason.

The small, colorful circles are the agents. The hollow circles are agent goal positions. The big red circles are obstacles (similar to agents but they experience attractive forces only, no repulsive).

Ball moving through line of agents

Agents moving around obstacle

Agents attempting to swap positions around perimeter of a circle