Should fix bug introduced in 5969064, where legacynavdata_msg was moved to a member variable. Because of this we need to clear vector datatypes, otherwise they accumulate over time through .push_back()
Will now publish video frames as soon as received if fullspeed_video=true. Unfortunately to do this we needed to do a few dirty hacks, implying that our architecture is no longer so suitable for the future direction of the driver. We need to talk about an architectural redesign perhaps...
Before, we were stamping the /ardrone/navdata,mag,imu messages with the time that they were processed in the main ros loop. This caused unnecessary delays in the timestamp. Now we save the time of navdata reception in the navdata handling loop, which is then used to stamp the output messages when processed by the loop.
This bug was introduced when moving local scope message variables to class-level. This move meant that messages wouldn't be reset after being sent. This was not a problem for non-array type message members, which were reassigned before being sent. However for array-type message members, which are filled using .push_back, no reset occurred. This fix appropriately clears these members before re-filling them on every send-loop.
Two new parameters have been added:
* `fullspeed_navdata`, which controls whether new-style navdata is published when received, or at `looprate`
* `looprate`, which controls the speed of the internal ros-loop. Note that legacy navdata is always published at `looprate`
Also made various speed improvements to the navdata processing pipeline to enable this faster processing.
Also fixed a problem with `enable_legacy_navdata`, whereby it wasn't read correctly and thus had no effect. Also mentioning it here because I forgot to mention it when I added it ages ago.
Also updated and commented the launch file to reflect these changes.
Regarding testing, I've flown with this for three batteries, with `fullspeed_navdata=true`, `looprate=50`, while rosbagging everything and experienced no unusual behaviour.
Conflicts:
src/ardrone_driver.h
Removed ros params command_disable_hover and command_always_send, in
favour of disabling hover manually by setting cmd_vel.angular.x=1 or
cmd_vel.angular.y=1
As per parcon's suggestion, I'm adding the ability to disable the hover
mode to allow for more predictable and thus modellable drone dynamics.
This should also be useful for my purposes.
We now have the ability to access any of the navdata structs which are
sent back by the drone. Still to do is to enable/disable the drone
sending based on whether we're interested in receiving the message.
I put a further check on the parameter parsing code, which checks the
parameter definition to see if it is writeable before trying to find a
ros parameter
I've fixed the bug causing parameter changes to have no effect on the
drone. Now we do a proper setup of the drone tool (rather than using
the factory default), which includes setting up application and user
profiles on the drone to hold our settings. We then actually send the
parameters to the drone, rather than doing nothing. The parameters
system has been extended to allow all user-modifyable parameters to be
changed (see AR.Drone SDK manual).
Calling ros::Time::now() doesn't guarantee timestamps are matched as
ros::Time::now() can change between calls. This fix sets the timestamps to be
equal, to ensure consistency.
This addresses issue #13.
Mani Monajjemi