Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing parameters will now affect the drone, rather than doing nothing! #26

Closed
wants to merge 24 commits into from

Conversation

mikehamer
Copy link
Contributor

I fixed the bug I reported a few days ago, whereby changes to parameters (from CAT_USER, CAT_APPLI, CAT_COMMON) would not affect the drone at all.

Previously, the drone was setup using a call to ardrone_tool_main(), this is no longer recommended by Parrot. I wrote a custom initialization routine. Now the driver correctly initializes its application and profile config files on the drone. Then, once initialized, the driver pushes the new configuration values to the drone.

I have tested this in flight. This also solves the problem with onboard tag detection not working (because now you can turn it on and change what it detects!), and allows control parameters of the drone to be adjusted (eg, euler_angle_max, control_vz_max, etc). This allows more aggressive flight with the drone.

I have also extended the parameter system to allow any user-editable parameter to be changed, rather than the limited set available on the previous driver. For possible keys, see the AR.Drone SDK manual, or the file ARDroneLib/Soft/Common/config_keys.h.

Mike Hamer and others added 2 commits November 7, 2012 14:31
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).
@@ -0,0 +1,22 @@
<launch>
<node name="ardrone_driver" pkg="ardrone_autonomy" type="ardrone_driver" output="screen" clear_params="true">
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add the clear_params="true" line to your launch file, otherwise removing parameters will have no effect as the values still exist in the ros parameter server.

@mani-monaj
Copy link
Member

Thank you very much @mikehamer for the interesting patch. I will test the changes today.

@mani-monaj
Copy link
Member

I merged your proposed changes into dev-unstable branch. I also modified your code a little bit. My initial tests using the new code were all good. I would really appreciate it if you test the dev-unstable branch yourself a little bit more.

I also have a question. Is the current README file's claim about configurations still hold:

The parameters listed below are named according to AR-Drone's SDK 2.0 configuration. Unless you set the parameters using rosparam or in your launch file, the default values will be used.

I also think that that the sample launch file should include values close to default values. I added a warning to the beginning of the file because I think novice users may get confused. What is your opinion?

@mikehamer
Copy link
Contributor Author

I agree about the default launch file, perhaps (see end of this msg), we just include the suggested parameter changes, and set them to the default values? Important is the clear_params="true" though, it took me a while to realise why the drone parameters weren't getting reset to default if removed from the launch file.

The README is correct, if the parameters are not set using rosparam or in a launch file, they will remain at drone default. The list of configurable parameters can however be extended to include all modifiable parameters of the AR.Drone, namely:

GENERAL
num_version_config
num_version_mb
num_version_soft
drone_serial
soft_build_date
motor1_soft
motor1_hard
motor1_supplier
motor2_soft
motor2_hard
motor2_supplier
motor3_soft
motor3_hard
motor3_supplier
motor4_soft
motor4_hard
motor4_supplier
ardrone_name
flying_time
navdata_demo
navdata_options
com_watchdog
video_enable
vision_enable
vbat_min

CONTROL
gyro_offset_thr_x
gyro_offset_thr_y
gyro_offset_thr_z
pwm_ref_gyros
osctun_value
osctun_test
control_level
euler_angle_max
altitude_max
altitude_min
control_iphone_tilt
control_vz_max
control_yaw
outdoor
flight_without_shell
autonomous_flight
manual_trim
indoor_euler_angle_max
indoor_control_vz_max
indoor_control_yaw
outdoor_euler_angle_max
outdoor_control_vz_max
outdoor_control_yaw
flying_mode
hovering_range
flight_anim
travelling_mode
travelling_enable

NETWORK
ssid_single_player
ssid_multi_player
wifi_mode
wifi_rate
owner_mac

PIC
ultrasound_freq
ultrasound_watchdog
pic_version

VIDEO
camif_fps
codec_fps
camif_buffers
num_trackers
video_codec
video_slices
video_live_socket
video_storage_space
bitrate
max_bitrate
bitrate_ctrl_mode
bitrate_storage
video_channel
video_on_usb
video_file_index

LEDS
leds_anim

DETECTION
enemy_colors
groundstripe_colors
enemy_without_shell
detect_type
detections_select_h
detections_select_v_hsync
detections_select_v

SYSLOG
output
max_size
nb_files

USERBOX
userbox_cmd

GPS
latitude
longitude
altitude

Many of these parameters should probably not be changed... however they are exposed for advanced users to change if they want. Of course, if they are not set, they will remain default.

Perhaps a good idea would be to provide a list of "suggested parameters to change", which would include

Suggested Parameter Changes
euler_angle_max
altitude_max
altitude_min
control_vz_max
control_yaw
outdoor
flight_without_shell

video_codec
bitrate
max_bitrate
bitrate_ctrl_mode

enemy_colors
groundstripe_colors
enemy_without_shell
detect_type
detections_select_h
detections_select_v_hsync
detections_select_v

Of course, the SDK manual details all of these parameters and how they should be changed.

I'll test the changes and get back to you on Monday with results.

Cheers,
Mike

@mani-monaj
Copy link
Member

Thank you very much for helping me with this.

One more thing needs to be considered. Not all params are writable, things like firmware version are read only according to SDK2 manual.

= and others added 3 commits November 12, 2012 16:21
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
@mikehamer
Copy link
Contributor Author

@mani-monaj: No problems – I'm using the driver for my master's project and needed to be able to change drone parameters; these changes are as much beneficial to me, as they are to the other users!

In #27 you will find a pull request that implements a fix to your comment – now only the writable subset of parameters will be loaded from ros parameters.

@mikehamer
Copy link
Contributor Author

Now only the following parameters will be checked:

ardrone_name
navdata_demo
navdata_options
com_watchdog
video_enable
vision_enable
control_level
euler_angle_max
altitude_max
altitude_min
control_iphone_tilt
control_vz_max
control_yaw
outdoor
flight_without_shell
autonomous_flight
manual_trim
indoor_euler_angle_max
indoor_control_vz_max
indoor_control_yaw
outdoor_euler_angle_max
outdoor_control_vz_max
outdoor_control_yaw
flying_mode
hovering_range
flight_anim
travelling_mode
travelling_enable
ssid_single_player
ssid_multi_player
wifi_mode
wifi_rate
owner_mac
ultrasound_freq
ultrasound_watchdog
codec_fps
video_codec
video_slices
video_live_socket
bitrate
max_bitrate
bitrate_ctrl_mode
bitrate_storage
video_channel
video_on_usb
video_file_index
leds_anim
enemy_colors
groundstripe_colors
enemy_without_shell
detect_type
detections_select_h
detections_select_v_hsync
detections_select_v
output
max_size
nb_files
userbox_cmd
latitude
longitude
altitude

mikehamer and others added 4 commits November 12, 2012 17:12
I reset the very aggressive flight parameters to the defaults (eg
relatively slow and controllable)
I forgot to remove the debug output from the launch file last time
@mikehamer
Copy link
Contributor Author

Regarding testing the dev-unstable branch, I flew for an hour today (multiple flights) using my modifications (above) to the dev-unstable branch and had no issues.

mikehamer and others added 2 commits November 13, 2012 11:42
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
Now only loads the writeable subset of drone parameters
@mani-monaj
Copy link
Member

Thank you very much. I merged #27 into dev-unstable. The last thing is to update the README file. My proposal is to remove all the information in "parameters" section. Instead add the fact that every READONLY configuration key listed in SDK2 manual can be configured via rosparam using the same name.

I think the only difference is that, the "multi-configuration" is implemented different than what SDK2 recommends. The driver will reset all the configurations (SESSION/APLI/COMMON) to default at startup, then reads rosparam to apply the user changes.

@parcon
Copy link

parcon commented Nov 20, 2012

Updating the README with all the available variables to be included in a launch file would be very helpful considering the density of the SDK reference.

@mikehamer
Copy link
Contributor Author

Thanks for the feedback @parcon. I'll try and update it this week (at least on my fork). I'll also be adding some more functionality on the navdata side of things.

For both of these changes I will submit a pull request to this main repository.

@mani-monaj
Copy link
Member

@parcon @mikehamer Do you mean listing only the name of all params? I was thinking of including the default values (or maybe a short description) as well, but I am afraid that it will take lots of space in the README file.

@mikehamer Is the claim in my previous comment correct to be included in the README?

@mikehamer
Copy link
Contributor Author

@mani-monaj The list I posted in my previous comment is the list of all parameters which are checked. The list is all the drone's Read/Write (not readonly as you stated) parameters.

@parcon
Copy link

parcon commented Nov 20, 2012

I feel either the list or a list with explanation would be helpful for those interested in getting the drone to work under ROS. The more the drivers don't seem like a blackbox, the more contributions to the code I would expect.

@mani-monaj
Copy link
Member

The list I posted in my previous comment is the list of all parameters which are checked. The list is all the drone's Read/Write (not readonly as you stated) parameters.

Thanks.

I feel either the list or a list with explanation would be helpful for those interested in getting the drone to work under ROS. The more the drivers don't seem like a blackbox, the more contributions to the code I would expect.

I will include the small list in the REAMDE. I may create a wiki page for the long list with explanation and default values. In the meantime people can use the SDK2 manual to find the explanations and default values.

@mikehamer
Copy link
Contributor Author

I've just generated the following, perhaps it will be of help for the wiki page. These are all the parameters which are checked, along with their default values, both as defined through macros if applicable, and numerically, as should be entered in a launch file.

altitude (Default = 0)
altitude_max (Default = 3000)
altitude_min (Default = 50)
ardrone_name (Default = My ARDrone)
autonomous_flight (Default = 0)
bitrate (Default = 1000)
bitrate_ctrl_mode (Default = 0)
bitrate_storage (Default = 4000)
codec_fps (Default = 0)
com_watchdog (Default = 2)
control_iphone_tilt (Default = (20000.0f * (MDEG_TO_RAD)) = 0.349066)
control_level (Default = 0)
control_vz_max (Default = 700)
control_yaw (Default = (100000.0f * (MDEG_TO_RAD)) = 1.745329)
detect_type (Default = CAD_TYPE_NONE = 3)
detections_select_h (Default = 0)
detections_select_v (Default = 0)
detections_select_v_hsync (Default = 0)
enemy_colors (Default = (ARDRONE_DETECTION_COLOR_ORANGE_GREEN) = 1)
enemy_without_shell (Default = 0)
euler_angle_max (Default = (12000.0f * (MDEG_TO_RAD)) = 0.209440)
flight_anim (Default = 0,0)
flight_without_shell (Default = 0)
flying_mode (Default = 0)
groundstripe_colors (Default = (ARDRONE_DETECTION_COLOR_ARRACE_FINISH_LINE) = 16)
hovering_range (Default = 1000)
indoor_control_vz_max (Default = 700)
indoor_control_yaw (Default = (100000.0f * (MDEG_TO_RAD)) = 1.745329)
indoor_euler_angle_max (Default = (12000.0f * (MDEG_TO_RAD)) = 0.209440)
latitude (Default = 500)
leds_anim (Default = 0,0,0)
longitude (Default = 500)
manual_trim (Default = 0)
max_bitrate (Default = 1000)
max_size (Default = 102400)
navdata_demo (Default = 0)
navdata_options (Default = ( ( 1 << (NAVDATA_DEMO_TAG) )|( 1 << (NAVDATA_VISION_DETECT_TAG) ) ) = 65537)
nb_files (Default = 5)
outdoor (Default = 0)
outdoor_control_vz_max (Default = (1000.0f) = 1000)
outdoor_control_yaw (Default = (200000.0f * (MDEG_TO_RAD)) = 3.490659)
outdoor_euler_angle_max (Default = (20000.0f * (MDEG_TO_RAD)) = 0.349066)
output (Default = (UART_PRINT|WIFI_PRINT|FLASH_PRINT) = 7)
owner_mac (Default = 00:00:00:00:00:00)
ssid_multi_player (Default = ardronenetwork)
ssid_single_player (Default = ardronenetwork)
travelling_enable (Default = 0)
travelling_mode (Default = 0,10,1500,0,1000)
ultrasound_freq (Default = ADC_CMD_SELECT_ULTRASOUND_25Hz = 8)
ultrasound_watchdog (Default = 3)
userbox_cmd (Default = 0)
video_channel (Default = 0)
video_codec (Default = (UVLC_CODEC) = 32)
video_enable (Default = 1)
video_file_index (Default = 1)
video_live_socket (Default = 0)
video_on_usb (Default = 1)
video_slices (Default = 0)
vision_enable (Default = 1)
wifi_mode (Default = WIFI_MODE_INFRA = 0)
wifi_rate (Default = 0)

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.
Still to do is add a flag to disable the default navdata and imu
messages
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.
This flag allows us to turn off the legacy navdata/imu/mag topics,
favouring usage of the actual packets
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!
@mikehamer
Copy link
Contributor Author

@mani-monaj The changes above this comment do a few things:

1. Allow ALL data sent back from the drone to be accessed, rather than the very small subset available through the /ardrone/navdata channel.
To use this, consult the new launch file, you will see many new flags such as enable_navdata_references. These flags control whether the contents of this particular navdata message will be published (if not specified, the topics won't be published). For message contents, consult the new messages in /msg, or the SDK file navdata_common.h. I am using it to receive additional information about the drone's internal controller (navdata_references) for mathematical modeling purposes.

2. Turn off combined navdata messages
By default, the navdata, mag and imu topics will always be published. This can be turned off by setting enable_legacy_navdata to false in the launch file (if not specified, defaults to true).

3. Disable hover mode
As per @parcon 's request, by specifying command_disable_hover=true in the launch file, hover can be disabled (the drone will not try to control to vx=vy=0 when not actively being flown)

4. Always send hover commands (even unchanged ones)
Setting command_always_send in the launch file will force the sending of hover commands. This only has an effect if the hover mode is not disabled.

Regarding testing: I have been flying with change 1 for about a week now and it works as expected.

I flew with change 3 and 4 this afternoon after making the change, and they both worked as expected. Recorded flight data shows that the drone never left flying mode (state==3). Visually, the drone also did not stabilize velocity after commanding to 0 body angle, as is expected when not entering hover.

@mani-monaj
Copy link
Member

@mikehamer thank you very much for your contributions. Is it possible for you to move the new commits to a new pull request? We will discuss them in the new place.

My roadmap was to merge the current dev-unstable to master today. I guess the new pull request should be sent afterwards.

@mani-monaj
Copy link
Member

I forgot to mention, please create the new pull request to dev-unstable branch.

@mani-monaj
Copy link
Member

dev-unstable is now on 13145dc, I think anything after that (starting from efaa64c ) should be moved to a new pull request.

@mikehamer
Copy link
Contributor Author

New pull request submitted in #31, lets discuss there.

@mikehamer mikehamer closed this Nov 21, 2012
garyservin added a commit to garyservin/ardrone_autonomy that referenced this pull request Sep 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants