microsoft
Drone-drone collision detection
Is there a way to get information about drone-drone collision. simGetCollisionInfo() seems to work only in case of collision with environment.
When drone collides with another drone, the chasing drone is disqualified. Do you need this feature for your training your algorithm?
Second this. I would also like to have this API function, and also an API for gate crossing, because right now I'm computing all this by hand (and disqualification behaves weirdly so this doesn't always work as expected).
For gate passing, you can also build on the log_monitor.py script to handle gate passed. https://github.com/microsoft/AirSim-NeurIPS2019-Drone-Racing/blob/master/scripts/logging/log_monitor.py#L51
Here's a little snippet from a log file:
drone_2 time 17621 gates_passed 2
drone_1 time 17646 odometry_XYZRPY (5532.530,3097.350,-1060.876,0.022,-0.014,86.657)
drone_2 time 17646 odometry_XYZRPY (5743.078,3784.857,-1049.107,-0.513,0.909,88.947)
drone_2 time 17646 gates_passed 2
drone_1 time 17675 odometry_XYZRPY (5533.286,3110.519,-1063.196,0.000,0.000,86.654)
drone_2 time 17675 odometry_XYZRPY (5743.477,3798.413,-1047.432,-0.494,0.942,88.916)
drone_2 time 17675 gates_passed 2
drone_1 time 17705 odometry_XYZRPY (5534.041,3123.677,-1065.532,-0.059,0.016,86.651)
drone_2 time 17705 odometry_XYZRPY (5743.883,3811.943,-1045.770,-0.476,0.975,88.884)
drone_2 time 17705 gates_passed 2
drone_1 time 17735 odometry_XYZRPY (5534.796,3136.823,-1067.882,-0.138,0.037,86.647)
drone_2 time 17735 odometry_XYZRPY (5744.297,3825.446,-1044.122,-0.458,1.007,88.851)
drone_2 time 17735 gates_passed 2
drone_1 time 17759 odometry_XYZRPY (5535.400,3147.332,-1069.773,-0.201,0.058,86.644)
drone_2 time 17759 odometry_XYZRPY (5744.631,3836.228,-1042.815,-0.444,1.033,88.825)
drone_2 time 17759 gates_passed 2
drone_1 time 17784 odometry_XYZRPY (5536.006,3157.833,-1071.673,-0.257,0.081,86.641)
drone_2 time 17784 odometry_XYZRPY (5744.971,3846.993,-1041.517,-0.431,1.059,88.799)
you can run the log_monitor.py in a separate python thread and keep track of which drone passed which gate
We're looking into adding a gate-gate collision API and a gate pass API as well
Well I am not sure whether my current solution is better but I preferred disabling the logs and use only the API because I assumed this would run faster than reading expanding log files, and I preferred not having to manage their storage when I run a big number of episodes.
Is there any progress being made on the "which drone is disqualified" API function, please? This is very important, because drone-drone collision often does not behave as expected.
I will work on trying to find a way to do this since there are a couple people interested, but I'm not sure I understand what the advantage is. The intended functionality is to read the state of the race from log_monitor, which tracks the state by consuming new lines in the log as they are written. A client can delete the log file between episodes to preserve memory, and there should be no slow down with expanding size since log_monitor.py merely consumes incremental lines as they are written, never the whole file.
By the way, do either of you happen to plan to submit entries in the Game of Drones competition?
@ironclownfish I do but I don't have anything convincing yet
My main personal concern with the log files is that it is not clear how synchronous it is with the current state of the simulation, and I run the simulation as fast as possible. Also it seems like a waste of cpu/communication to write this file continuously during training, so I disable it.
I can't claim we've measured it but my intuition says writing to an open file will be faster than querying for updates over rpc. I would expect it to be less CPU intensive too, since rpc requires packing messages. I wouldn't expect latency to be too essential either way when it comes to detecting disqualifications or checking off gates. But that is just my speculation.
It's a little nontrivial to do this (by design, since racing is not part of core AirSim), but I'll see if I can make it work. Then people can use their preference.
Well, latency is a problem for me because I discretize time and I need to determine which last action (time-step) is responsible for the disqualification, but I believe you are right about the CPU usage.
On a separate note, for me, collision between the drone and the 'StartBlock' goes undetected even if the contact is more than tcw (=1 second). Is this the intended behaviour? Note that airism.simListSceneObjects() does have 'StartBlock' in the list; this suggests that the behaviour I'm noticing is buggy.
Apologies if this is the wrong thread to ask.
@layman-n-ish It's intentional, since the drones start resting on the start block. We felt it was a little harsh to penalize for collisions before you really start racing.
@ironclownfish Yes, I kind of figured that. Although don't you think the collision for the 'StartBlock' should be "enabled" once, say, the drone takes off? Is it possible to do that?
It takes a toll at how I've structured my reward currently; the drone simply rests on the block with the collision going undetected.
@layman-n-ish, why not just use the takeoff API / moveOnSpline to takeoff first, and then start your RL policy. My personal opinion on this is that it would be wasted effort to "learn to takeoff" if your goal is to have a good standing on the leaderboard. It would be cool, nonetheless.
Hmm, on second thought, while shaping rewards for such behaviour - one would usually add a "progress to goal" component and a "(constant) time penalty" at every step. Those two reward function components would ideally nudge your drone to do something instead of sitting on the start block.
Apologies for being ambiguous earlier but that's what exactly I'm doing. I am indeed using the takeoff API and not expecting the agent to learn to takeoff.
You're right; I had those components in my reward structure but later on, after some insights, amended it such that the agent gains positive rewards for every time step its "alive" (not collided). I thought this made more sense in nexus with the "goal" component in the reward structure.
But, I do get your point. I'll make appropriate amendments for it to not sit on the 'StartBlock'. Thank you for the insights.
I think convergence to the optimal policy would be faster if I could explicitly tell the drone (by imposing negative rewards) on detecting collision with the 'StartBlock'. Please do correct me if I'm wrong.