-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple AR.Drone 2.0 near each other results in unexpected behaviour #193
Comments
This behaviour is most likely due to sonar interference. Try passing the |
Yeah I already had telnet and changed to 7 and 8 in vi /data/config.ini. |
The driver might be resetting them when you run it. |
I will try thx. I will reply this week when I test. |
btw, do you know the minimum and max values of ultrasom_frequency? |
It's either |
Do you have any idea what's watchdog = 3 is for? Should I leave it both at 3? Thanks |
No unfortunately |
Ok thx. One more question. If I have 4 drones, I can only use 2 different sonar frequencies? That will cause interfere between 2-2. |
That is true. However you can spread them apart such as the neighbouring drones use different frequencies. |
Seems to be better now. But I cant control very well because every 2min or so they lose connections and reconnect again. I'm running tum_ardrone and if It starts reconnecting it will hold the last command and if it's movement and it starts reconnecting the drone can go into a wall. Any idea?
|
It's probably due to wifi interference. How does your setup look like? One PC per drone or multiple drones connected to a router? |
I tried one pc per drone and one pc with a router and both do the same. Maybe I need to lower the nao data frequency? I set it to 200hz |
Navdata* |
Are you placing them on wifi channels as far away from each other as you can? (think 1 and 11) The drones are very sensitive to wifi interference thanks to transferring video over TCP (don't ask). In comparison the navdata is a tiny UDP packet, even at 200hz it's not that big of a problem, and lowering it may cause trouble with tum_ardrone. In your ardrone.launch file, remove the bitrate config option and set max_bitrate down to 1000. Another thing you might try is turning on dynamic bitrate, edit line 93 of src/ardrone_sdk.cpp to be: ardrone_application_default_config.bitrate_ctrl_mode = VBC_MODE_DYNAMIC; |
Hello. I have the wifi router in a complete different channel than the nearby wifi. I did what you said and it's even worse.
|
By nearby wifi you mean the second wifi adapter for drone #2, or another access point nearby? What channels are you using? I've never gotten more than 3 drones flying at the same time, and then I only did so by moving them to an area with no wifi AP's nearby (in a park) with two laptops and an access point set to channels 1, 6, and 11. Also, the log you sent still says the max_bitrate is 4000, is this when you were trying with dynamic bitrate enabled? |
I agree with @kbogert 's suggestions. We've had a lot of problems with Wifi interference among drones previously. Also please note that some access points perform poorly under load, you can for example check the experiments section of this work by our group to see how bad the situation can become in a similar condition. |
I'm having this exact same issue. Did anyone ever resolve this problem or find a way around it? When running 2 drones I can't even issue commands after takeoff because of this. |
@sagerd Have you tried changing the ultrasound frequency and examining the possibility of wifi interference? |
@mani-monaj I'm pretty sure it's wifi interference, all of the ultrasound readings seem to be accurate. From my understanding, it just seems like the wireless hardware used in the drone is just really bad and prone to dropping connections. Is this your experience? Do you have any suggestions? |
Unfortunately yes. A good wireless router (access point) makes a huge difference. Also you can change the channel manually to a non-crowded channel (i.e. using the Wifi Scanner on Android). What is your configuration like now? |
I am using 2 AR.Drones and one of them starts going up and one down for example. I though it's was the sonar frequency and I telnet into each AR drone and changed vi /data/config.ini - > ultrasound_frequency so they are different and both have ultrasound_watchdog = 3 and one of them still going up into the ceiling when they are near each other.
The text was updated successfully, but these errors were encountered: