How AirSim is managing a lot of RPC calls?

[alexandrelombard]

I have an application written in Java which uses msgpack-rpc to send commands to AirSim (I use Windows with Unreal). I'm trying to set-up a multiagent based simulation using AirSim to manage the physical environment, while the behavior of the agents is externalized in my Java app. I have several questions about how are managed the RPC calls by AirSim.

My simulation works like this:

• I pause the simulation at the beginning
• Then, in a loop:
• I emit several API requests to AirSim (getting data, sending commands to vehicles)
• I continue the simulation for a given amount of time

The amount of requests emitted can be important and is not constant.
If the load is heavy, usually after some time, my API requests are failing with a timeout exception.

My questions are :

• Is the way I'm managing my simulation correct? I mean, is it okay to emit instructions while the simulation is paused?
• Is there a kind of buffer storing the different requests? Is it possible that I'm flooding this buffer?
• Is there a way to increase the buffer size if it exists? Or to change how it is managed?
• How are managed simultaneous and conflicting requests (example: two moveByVelocity requests with different directions)?

Thank you for your answers.

[ironclownfish]

You can emit several API requests to airsim in this way, but as you have observed, too many may cause a crash. Some API requests--the ones that need to be run on the game thread--are buffered using an internal Unreal Engine game thread queue. (i.e. there is an Unreal Engine api to request running something on the game thread) There is no way to increase the size of this buffer since it's internal in the engine, but I also think the risk of a crash for these apis is lower, since they are buffered in the first place.

By contrast, rpc calls in general are each processed on a new thread, which is a crash hazard if there are any race conditions or non-re-entrant functions. We have improved this a little; most notably reset() has been made re-entrant so it can be safely called at high frequency.

In general, you just have to be cautious about seinding too many commands. A good workaround is to control different agents from their own, separate clients.

As for conflicting commands, the latest command will override the last one. i.e. whichever moveByVelocity() command is processed second will cancel the first one.