Allow multiple instances of ardronelib to run on the same machine #2

Merged
merged 1 commit into from Nov 9, 2014

Projects

None yet

3 participants

@kbogert
Contributor
kbogert commented Sep 21, 2014

using a random, available udp port for sending commands to the drone.

was AutonomyLab/ardrone_autonomy#98

Kenneth Bogert Allow multiple instances of ardronelib to run on the same machine
using a random, available udp port for sending commands to the drone.
e30f9e0
@mani-monaj
Member

@kbogert Temporarily, I do not have access to any AR-Drones. I believe this is a backward compatible/transparent change. Right?

@mani-monaj
Member

@kbogert ... and thank you for this elegant solution

@kbogert
Contributor
kbogert commented Sep 29, 2014

No problem,

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.

@kbogert kbogert referenced this pull request in AutonomyLab/ardrone_autonomy Oct 30, 2014
Open

Using Multiple Instances of ardrone_autonomy #56

@mikeclement

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))

@kbogert
Contributor
kbogert commented Oct 30, 2014

@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:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -63,8 +63,8 @@ catkin_package(

 include(ExternalProject)
 ExternalProject_Add(ardronelib
-       GIT_REPOSITORY git://github.com/AutonomyLab/ardronelib.git
-       GIT_TAG bdacd1cbd3fbc54263d29e6e2067265e5941d10e
+       GIT_REPOSITORY git://github.com/kbogert/ardronelib.git
+       GIT_TAG e30f9e0e58a4dbd7b831d487cd630914f01b568d
        PREFIX ${CMAKE_BINARY_DIR}/ardrone
        CONFIGURE_COMMAND echo "No configure"
        BUILD_COMMAND make
@mikeclement

Sounds great; thanks! Hopefully this will get merged soon, too.

@mani-monaj mani-monaj merged commit 2f98702 into AutonomyLab:master Nov 9, 2014
@kbogert
Contributor
kbogert commented Nov 10, 2014

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.

@mani-monaj
Member

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.

@mani-monaj mani-monaj added a commit to AutonomyLab/ardrone_autonomy that referenced this pull request Jan 14, 2015
@mani-monaj mani-monaj Update SDK to fix multiple instances. Fixes #98
- Original changeset: AutonomyLab/ardronelib#2
- by @kbogert
194c6e7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment