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
This is an aggressive launch file, you should turn down the
euler_angle_max, control_vz_max and control_yaw if you are not
interested in aggressive flight!
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.
Optimally this would be calculated before being published to Navdata,
but for backwards compatibility lets document the format for now, and
discuss an additional unpacked time
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.
Mike Hamer