-
Currently we disregard the acknowledgements the drone sends us. The api on the drone is poorly designed, but it exists. The reason we don't use it is that we would have to cross boundaries between control and navdata. Ugly, but no way around it.
-
Right now, all at-commands are treated equally - they are pushed into an array, and when flush() is called by the interval vom Client.js, a udp packet of all outstanding at-commands is assembled and sent to the drone. But config commands need special handling:
-
Certain configuration options are only available when using the "multiconfig" option. That is: declare a session, profile and application-id upfront and send it prior to every config command within the same UDP packet (config options custom:application_id, profile_id, session_id)
-
All the really interesting config options are only available with this "multiconfig" approach, like switching video codecs, switch cameras, adjust bitrate, and so on.
- split config handling away from generic at commands, while reusing the global command counter.
- add all config requests to a queue, add a callback for the ack receipt to the function signature
- when processing the queue of config commands:
- send session ids (AT*CONFIG_IDS) + config cmd in one udp packet
- wait for navdata.data.droneState.controlCommandAck to become 1
- notify caller via callback
- send ('CTRL', 5, 0) to reset ack bit
- wait for navdata.data.droneState.controlCommandAck to become 0
- continue until queue empty
- queue all incoming navdata packets, so we don't lose any
- check sequence counter contained in navdata header
- I've implemented the multiconfig stuff (encoding and such) enough to confirm it does not work with the current system.
- Will probably start hacking on the queuing over the next days.
Maybe this should go into @felixge's new_api branch, which I have absolutely no clue of.
Comments or pull requests to node-ar-drone welcome!