Still working on trying to reproduce in a minimalistic example (no luck so far). However, one thing I did notice and fix, which seemed to make things a bit better, was the placement of the arena walls, which I discovered after some visual inspection and placing with arena wall placement in the input...

I also tried setting the max speed to 5 cm/s, as in the example for using multiple physics engines, and the simulation ran for a MUCH longer time (~3 hrs), but then still crashed with the same exception. So the issue may be related to the speed of the robots, but just making the robots move slower m...

I set their max speed to 10 cm/s, which works fine for lower counts of robots in the arena.

I would also add that I know the condition that is triggering the exception is that there is no engine available to house the entity (the exception text was modified to that effect), which can happen if the robot's position is outside of the bounds of the arena. Interestingly, I've seen robots someh...

The crash I get is an exception in the "AddEntitiesToPhysicsEngine()" function in space.cpp: [FATAL] No physics engines available to house entity "fb4882" (the name of the footbot is different each time) Here is the .argos file I'm running (project-specific bits removed) <argos-c...

So I've been trying to track down why robots are able to escape from physics engines, and have gotten stuck. I'm not sure if this is a configuration error on my part, or a bug in ARGoS (I'm leaning toward the latter, though I am not sure). Here's what I've seen so far: - It does not happen with less...

Where should I start looking if I wanted to add said feature in ARGoS and the Qt documentation. Graphical stuff is not my forte, so I'm sure where to even begin.

Thanks!
- John

Is there a way to have ARGoS collect frames of video without connecting to an X-server on linux? My development machine is headless, and so I can't run graphical stuff on it (well I can, but over ssh it takes forever to render even with just a few robots).

- John

I removed the range and bearing and LED sensors/actuators from the robots, as those were not being used for the simulations I was running, or were only for visual debugging purposes (I didn't realize that including sensors/actuators but not using them still resulted in ARGoS performing lots of updat...

Also, I've been playing with disabling the FSM the robots are using altogether (i.e. the ControlStep() now just returns without doing anything), as well as removing all the bits in the loop functions that I added, and I have been able to get close to real-time performance with a swarm of 1024 robots...