Movement commands not being processed

[LeslieNock]

Hey, I've been developing with the ar-drone library for the past 10 months and got an amazing application for my dissertation at university. One week before the presentation and the software is behaving odd.

It started a few days ago when I noticed the drone was not responding to the joystick controls. I've checked my framework and the signals are definitely getting to the drone. Take off, land, ftrim and other functions seem to be fine but when I try send a directional command, it is not responsive.

A basic test would be to connect to the drone, take off, attempt movement commands and then land the drone before it decided to launch off into the air. The demo data being returned shows that the controlState has the following changes during test:

controlState: CTRL_LANDED, flyState: FLYING_OK controlState: CTRL_TRANS_GOTOFIX, flyState: FLYING_OK controlState: CTRL_HOVERING, flyState: FLYING_COMBINED_YAW controlState: CTRL_FLYING, flyState: FLYING_ALT_OUT_ZONE controlState: CTRL_TRANS_LOOPING, flyState: FLYING_OK controlState: CTRL_LANDED, flyState: FLYING_OK

If anyone can shed light on what these state changes are doing and why it is causing an issue with sending the movement commands.

Any help would be greatly appreciated as I seriously need to fix this issue ASAP! My degree depends on it!!

Thanks

[wiseman]

Leslie, I don't know offhand what the problem could be, so I only have some general recommendations (in order by which things I would try first):

• Do you have another drone you can try, in case it's a problem with your specific vehicle?
• Can you reproduce the problem with a small program that just commands the drone to take off, move around a little (without joystick input), and then land? If you can reproduce the issue with a small program, I'll try running it on my drone and see if I get different results.
• Try using tcpdump or wireshark to sniff the network messages sent between your computer and the drone to confirm that the AT commands are being sent correctly.
• Is it possible the firmware was upgraded recently? If nothing else seems to be working, it might be risky but you may consider trying to downgrade the firmware: http://drone-apps.com/support/ar-drone-firmware/

[LeslieNock]

Hi Wiseman,

Thanks for the response. I purchased a second drone that arrived today that gave the same result.

The simplest test of setting up a client.createRepl() displays the issues. I send a take off command and it returns true. I then send a clockwise(0.5) command and nothing happens. The back two lights go red whilst the front two remain green.

The drone just wants to carry on gaining altitude. I've sent a configuration command to limit the maximum altitude to 500mm to stop the upward thrust but this seems to do nothing. This was all working recently. :(

Since the take off and land commands are processed as expected, I'm fairly certain that the AT commands are being sent correctly. I've tried this test with several versions of ar-drone and with two separate drones.

I'm using a wireless dongle to connect to the drone and wonder if it is failing or placing restrictions on how fast or how much data can be bouncing between my computer and drone. As for the firmware, I've tried this on two drones (one fresh out the box) and still facing the same issues.

It is also worth noting that the AR.FreeFlight app is working as expected with the drone.

I really appreciate all the effort in responding and helping me resolve this!! Thanks again :)

[LeslieNock]

So this morning I set up a createRepl file on a laptop to check if it was a wireless fault happening sporadically. Using the ar-drone library, I could takeoff, land and flat trim but it would not accept ANY movement commands.

@wiseman, would you be able to run a check on your hardware/software with a createRepl to see what behaviour occurs. The only movement I get from the drone is through the AR.FreeFlight app now. Other applications such as Webflight have stopped working for me too.

Thanks

[wiseman]

Sure, I can check that later today.

I'm just curious what could have changed. As mentioned in another issue recently, it's been about 2 years since the last commit to this code. That leads me to think that the problems are related to a change in your environment, of which the most likely might be an updated drone firmware. Just so I can compare, what firmware version are your drones running? (See http://www.dronezon.com/diy-drone-repair-videos/parrot-drones/how-to-upgrade-the-firmware-on-your-parrot-ar-2-0-drone/ for instructions on checking your version.)

Doing network-level sniffing using tcpdump or Wireshark should be a good way of (relatively) definitively seeing what is different between the FreeFlight app, which works, and using node-ar-drone, which doesn't. It's labor intensive, but it's a method I've used successfully before (using Wireshark).

Basically, you look at the packets being sent to the drone on TCP port 5556, which will contain all the AT commands being sent. Wireshark has a feature where you can select one packet, tell it to follow that stream, and it will show you all the traffic to/from that port. You do that while running software that works with the drone, then do it again with node-ar-drone, and look for differences.

[LeslieNock]

That would be a great help!

As regards to the firmware, both drones are up to date according to the AR.FreeFlight application.

AR Drone Hardware: 2.2 AR Drone Software: 2.4.8 Inertial Hardware: 2.3 Inertial Software: 5.34

I will look at doing the packet sniffing this evening and see how I get on. I've not used Wireshark before but I hope with a bit of fiddling around, I can get some data that explains the differences between the applications.

An old version of my software was tested earlier today and I found I could get the commands to work with the drone after resetting the drone prior to loading the software. This worked on both drones but didn't feel smooth. It feels like all commands are being pummelled across to the drone at once and it just wants to keep gaining altitude. I put the altitude down to the bottom sensor disliking carpet so now I have a hard surface offering a better read out on the altitude.

I've gone back to the core basics in the application to minimise any interference and using that as a test bed. I'll write another update this evening to let you know how I get on!

Thanks :)

[wiseman]

Just FYI I used createRepl to takeoff() and clockwise(0.5) and everything worked fine. I have the same versions of everything except AR.Drone Hardware is 2.1.

[LeslieNock]

Thanks for the test.

I've looked at the packets to trace the AT commands and can confirm that both my application and AR.FreeFlight are sending fine. The yaw left command was sent to both applications but only the AR.FreeFlight had an effect on the drone.

Wireshark for the pc application: https://gyazo.com/a507d64baf1d8f50973c7f60213a17c9

Packet Capture for AR.FreeFlight: https://gyazo.com/ee30590584e88cd91da45d7579a94e6f

My last test tonight will be to analyse all the data packets and see if there is something abundantly wrong. I'm starting to lose faith in a solution appearing now! Maybe I should just implement what I can and plead with my supervisors that is "was" working. If you have any further suggestions, that would be amazing!

Thanks :)

[wiseman]

I'm closing this for now since I can't reproduce, but if you have any new information feel free to reopen.

[lelmac]

@LeslieNock did you fix your Problem? I am currently experiencing a similar Problem: I can rotate, raise and lower the drone via the node module, but not tilt in any direction. It was also working ~half year ago, but now it doesn't for some reason.

[BCaven]

@LeslieNock @TheOssi Do you still have this problem? I had a similar problem where the drone worked but after a few weeks it would not respond to motor controls.

I did some researching and found that you could reset the drone and that may work to solve the problem.

When I reset my drone by pushing the reset button with the battery in, the drone responded normally to my commands.

FYI: I also have drone hardware 2.2

[LeslieNock]

@TheOssi @BCaven Hi both, sorry about the delay in replying! Unsure if you are still experiencing these issues but the root of my issue was the application I built was not closing the session to the drone correctly. This meant that after resetting the drone, it would work fine on the first flight but the second one would not respond correctly. I had to trigger a safe disconnect from the drone and my software to avoid this problem again.

Another issue that resulted in some sporadic changes in if the drone was accepting movement commands was a bottleneck on the Web sockets. It transpired that I was sending the movement commands to frequently and triggering more than three asynchronous functions that fired off movement commands resulted in no commands getting through.

If I this doesn't solve your problem, please be sure to reply as I will actively try to respond.

Looking to pick up my old application and improve the GUI. Then... I guess I could release it on Git. I'll keep you informed on that front :)

[BCaven]

Thank you for that information, it is very helpful.

Do you remember the code to trigger a safe disconnect?