Proof of concept for calling FTRIM before takeoff().

[janl]

(cleaned up version of #25)

Based on the Drone Manual:

AT_FTRIM
Summary : Flat trims - Tells the drone it is lying horizontally Corresponding API function : ardrone_at_set_flat_trim
Syntax : AT_FTRIM=%d,
Argument 1 : the sequence number
Description :
This command sets a reference of the horizontal plane for the drone internal control system.
It must be called after each drone start up, while making sure the drone actually sits on a horizontal ground. Not doin
g so before taking-off will result in the drone not being able to stabilize itself when flying, as it would not be able t
o know its actual tilt. This command MUST NOT be sent when the AR.Drone is flying.
When receiving this command, the drone will automatically adjust the trim on pitch and roll controls.

[janl]

Tests fail, obviously, I need some help with fitting right into the lib.

[bkw]

Great idea!
Maybe we should warn against using takeoff() on unleveled ground in the readme and mention takeoffUnstable().
5s delay for every takeoff seems to be a quite a tradeoff for the trimming, we need to find a way get an ack of some sorts before we merge this, imho.

[saibayadon]

This is useful, specially after a crash. The drone won't takeoff in a stable manner after one of those and it needs to bo rebooted.

[bkw]

I'm all for it, just a bit hesitant to make all takeoffs (as opposed to only crash recoveries) take an extra 5s longer.

[janl]

On Nov 10, 2012, at 22:24 , Bernhard Weißhuhn [email protected] wrote:

I'm all for it, just a bit hesitant to make all takeoffs (as opposed to only crash recoveries) take an extra 5s longer.

This is basically due to my relative inexperience with the drones and programming them. I just observed the net traffic for the _repeat(10) ftrim commands to be sent and added a little padding to make sure we don’t ftrim while taking off.

I just copied what takeoff() does in terms of using _repeat() to work around UDP. I think we all agree that some sort of backchannel for control would be desirable.

This PR is mostly to share my research, please feel free to take this and integrate it more properly :)

[felixge]

I've looked into this before and was unable to figure out how to get an ACK for this. One possibility might be to send the command over TCP on the TCP port (5559), but I have not tried this yet.

Anyway, yes, we need to get this integrated.

[bkw]

One possibility might be to send the command over TCP on the TCP port (5559), but I have not tried this yet.

I'm trying to do exactly this right now, no success so far.
But I managed to get acks for AT*CONFIG messages, which should be usefull. Unfortunately not for this case.

[felixge]

But I managed to get acks for AT*CONFIG messages, which should be usefull.

How? Via TCP?

[bkw]

No, you send at_ctrl with params 5,0, which resets the flag controlCommandAck in the navdata to 0.
Then when you send the next at_config, this flag switches back to 1. You then send another at*ctrl 5,0 to reset.

Described here: https://projects.ardrone.org/boards/1/topics/show/2364

[felixge]

Sweet find!