using a random, available udp port for sending commands to the drone.
Allow multiple instances of ardronelib to run on the same machine
@kbogert Temporarily, I do not have access to any AR-Drones. I believe this is a backward compatible/transparent change. Right?
@kbogert ... and thank you for this elegant solution
The only change this patch makes is this library will now open three random UDP ports rather than the known ones. This works because as far as I can tell the drone NEVER sends any packets over udp to these ports - they are only used by the client to send control messages to the drone. I've tried with both ardrones 1 and 2, though only with the latest firmware, and they both work perfectly.
Why this wasn't done in the first place is beyond me, as best I can figure it's just bad programming. So yes, this should be backwards compatible and transparent to any users of this library.
Hi All, I haven't had time to test this patch out yet but it would be great to get this merged when possible; I have students who could make immediate use of it.
@kbogert In the meantime, I haven't built ardrone-autonomy since ardronelib was separated out. Is there documentation somewhere that could help guide a student through the build process such that I could point them to that, ardrone-autonomy, and your patched ardronelib branch and have them build it?
To @mani-monaj 's question about transparency, back when I was also working on solutions for this, I noticed that there is a bit of protocol between the client (e.g., ardrone-autonomy instance) and the AR.Drone. For video and navdata (traffic that is sent from the drone to the client), the client initiates the stream by sending a couple UDP datagrams to the drone's IP at the respective UDP port (e.g., 5554 for navdata). Whatever source IP and UDP port is set in those datagrams is what the drone will use to send back its data. Switching from a fixed port to an ephemeral port (as @kbogert did) should be just fine for both the client and the drone. (I believe @kbogert alluded to this in AutonomyLab/ardrone_autonomy#56 (comment))
@mikeclement I haven't built ardrone_autonomy in a while either, and I didn't realize when I opened this PR that there is now no easy way to build it with multiple-drone support. I guess the easiest solution for now is to use my fork at: https://github.com/kbogert/ardrone_autonomy/tree/for_autonomylab , it's still reasonably up to date.
Alternatively, you could use the stock ardrone_autonomy by modifying CMakeLists.txt to pull ardronelib from my fork:
@@ -63,8 +63,8 @@ catkin_package(
- GIT_REPOSITORY git://github.com/AutonomyLab/ardronelib.git
- GIT_TAG bdacd1cbd3fbc54263d29e6e2067265e5941d10e
+ GIT_REPOSITORY git://github.com/kbogert/ardronelib.git
+ GIT_TAG e30f9e0e58a4dbd7b831d487cd630914f01b568d
CONFIGURE_COMMAND echo "No configure"
Sounds great; thanks! Hopefully this will get merged soon, too.
Thank you for the merge, @mani-monaj .
Just a gentle reminder that the GIT_TAG field of ardrone_autonomy's CMakeLists.txt file has to be updated in order for that project to pull any changes from this repository. You might want to consider creating a release with a standard name (ex. "latest") which can be changed as needed so that you don't have to keep updating the GIT_TAG.
You are welcome. Thank you for fixing this issue.
I rather manually update GIT_TAG in the main package to keep things simple (e.g. which ardrone_autonomy version is compiled with which version of the SDK). I will do some cleanups this week and release a new version.
Update SDK to fix multiple instances. Fixes #98
- Original changeset: AutonomyLab/ardronelib#2
- by @kbogert