Thanks for the great work! Can you help me understand why my drone goes right(ish) when I use moveForward()? Is this related to trim configuration / calibration?
Thanks,
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know what you mean, I had this problem myself. The drone reacts like this, when the propellers are damaged. Maybe you noticed, that the drone also drifts to a side or need a lot of space while turning. Changing the propellers is not a big deal.
The drone calibrates its sensors while it is booting and with the command "trim()" of cause.
The firmware does normally a really good job, even if the ground is not completely horizontal. I guess there is a second calibrating-step while starting, using the data of the accelerator.
By the way: when the drone is turning, is the stabilization isn't using the accelerator-sensors and the drone wobbles, depending on the condition of the propellers more or less. Maybe Parrot will fix it some when (the mechanisms are pretty complicated, so I don't think so)
Guess I am in smart ass today X-D
Have a great day,
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick reply!
Unfortunately, replacing the propellers had no effect. Perhaps it is damage to the hull (indoor shell)? Or perhaps it is some internal sensors that were physically shifted in a crash? Anyways, doing callibration / trim has had no effect either :(
Thanks,
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm...I can't imagine, that your problem is caused by sensor or calibration-failures. Maybe a gear-weels is damaged, dirty or something like that.
Personally, I would change the propellers, gear-weels and maybe the controller-boards from one limb to an other and see what happens.
Does the drone hold position when its just hovering ? If you let it turn, does it glide away (it may fly a circle with a diameter of one meter, that's OK). Walls or large objects nearby could violate the air-flow and "suck" the drone in its direction. Did you try to let fly the drone to the opposite direction...this may sound weird, but may help to find the problem. And does it drift to the right while flying forward and backward ?
One of my indoor-shell is also pretty damaged, but I never noticed its causing a drift...but maybe ;-)
Sure that the central cross is OK ? (take the drone at a left and a right limb, everything has to be fix and no movement at all)
So I am getting this strange flying right behavior no matter what command I give the drone. Commands like turnRight and moveUp do the same thing. Here are some tests I have done:
Ran your library on my Mac and on a Virtual Ubuntu install. (Bad Move Right Behavior)
Ran python-ardrone-master demo. (Bad Move Right Behavior)
Ran the Test-Flight App on iOS (Good flying, no wierd move right stuff)
Ran the Node-Copter.js library. (Good flying, no wierd move right stuff)
Is it possible that the firmware is the issue? ['general:num_version_config', '1'] ['general:num_version_mb', '34'] ['general:num_version_soft', '2.4.8'] ['general:soft_build_date', '2013-09-16 14:49']
Thanks,
Sebastien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
wow...you really took care of that problem and to be honest: I am out of ideas right now.
The comparisons you did are really interesting.
In a nutshell: The drone (or its firmware) flies always by itself, controlled by some movement-commands. So the running client-system and software shouldn't have an effect on the flight-behavior.
Especially the movement-part is less magical than the rest. Of cause, I believe you and your test-results, so let's brainstorm:
With the firmware 2.3.3, there was a self-alternation of the slope-sensor-values, individual for every drone and depending on the temperature in the room (about 0,0019°/s, -0,0055°/s and 0,0258°/s for X-, Y- and Z-axis...I muttered about this in my master-thesis). The drone stood still but it was a problem to calculate directions (so I added the command getSelfRotation()). Parrot fixed this value-self-alternation with firmware 2.3.3, but then the drone rotaded about 1°/s. With firmware 2.4.8 they fixed it again, now it's better, but not perfect. Anyway, this is the only case I know the firmware messed the movement up.
PS-Drone, python-ardrone and programs based on Parrots SDK (like Freeflight) work the same way. The programs command the drone to fly this or that direction and the firmware takes care of executing it. So there are some basic commands which always work (these commands also still work with parrot-ardrone). The protocols and (most) commands are described in Parrot's Developer Guide for SDK 2.0.
In a nutshell, they are structured like this:
AT*<cmd>=<num>,<param1>(,<param2>,<param3>…)
Parameters must be strings, covered in quotes or integer (IEEE-754 floating-points have to express as a 32-bit signed integer).</param3></param2></param1></num></cmd>
Basically you just need this commands to make the drone move: takeoff() ATREF=3,290718208 moveForward(0.2) ATPCMD=4,3,0,-1102263091,0,0 drone.land() AT*REF=5,290717696
That's all what happens...or these are the basic commands to make the movements. PS-Drone does a bit more to make sure everything runs perfectly, but python-ardrone does (nearly) just these steps shown above.
Change the value of showCommands (3.8, page 42) to True (drone.showCommands=True) before using other drone-commands, so all commands to the drone (and between the processes) will be displayed (ok, I confess, the keep-alive-commands are missing).
By the way, the keep-alive command is: AT*COMWDG=6
You will also notice two commands will be sent at the beginning:
ATPMODE=1,2
ATMISC=2,2,20,2000,3000
I sniffed them from the network while playing around with the parrot-demo-programs, but the meaning of their parameters are not documented. I decided to send them too, but there is no noticeable visible benefit.
After that, PS-Drone sets NavData to demo-mode (to prevent unexpected behavior) and the Session-ID to “-all” and downloads the drone's configuration.
I have my drone not here right now to describe it exactly, but you may see also something like this:
AT * CTRL=6,4,0 Download the actual configuration of the drone.
AT * CTRL=7,5,0 Reset the confirmation-bit of the drone
Setting the NavData-Demo-Mode will look something like this:
AT*CONFIG=8,”general:navdata_demo", "TRUE" Set a configuration
AT * CTRL=9,5,0 Reset confirmation
AT * CTRL=10,4,0 Download new configuration
AT * CTRL=11,5,0 Reset configuration
I hope you agree that there shouldn't be a different behavior using different APIs. So the question is, why the drone behaves different to Note-Copter.js and Test-Flight, I am sure they're working the same way as PS-Drone, but I also believe your testings.
Of cause, there is another way to control the drone's movement:
The second part of my master-thesis was a program to make the drone fly fully controlled by the client (without firmware) using the pwm()/thrust()-command, but I haven't it published until now. It's a proof of concept anyway, with a subset of the drone's sensor-values, because the drone keeps staying in landed-mode...but that's another loooong story.
Anyway, I am absolutely sure, that no API-developer is insane enough to even think about implementing a movement-control as in my proof-of-concept into something like PS-Drone or Node-Copter.js...really, this guy would also try to invade russia...in winter...alone and naked...riding a hamster. X-D
I still guess there might be a problem with at least one of your propellers, but its a good idea to think about an auto-correction of the direction, in case the accelerator-sensors measure some unexpected movements - but it might be pretty complicated, if you don't move to a basic direction (forward/backward/left/right)...so a solution may take a while.
Did you try to correct it manually, using move() ? (e.g. move(-0.01,0.5,0.0) )
Did you try mantrim() ? (It may not be supported by the AR.Drone 2.0 (anymore))
Is it possible to capture the command-network-stream (UDP Port 5556) while using Node-Copter ?
I hope my answer was more helpful than confusing. You are very welcome for more brainstorm, of cause also by direct e-mail.
Best wishes,
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AT*MISC=2,2,20,2000,3000
** Vid -> Com : showCommands
AT*CONFIG=13,"general:navdata_demo","TRUE"
AT*CTRL=14,5,0
AT*CONFIG=15,"custom:session_id","-all"
AT*CTRL=16,5,0
AT*CTRL=17,5,0
AT*CTRL=18,4,0
Got 140 Configdata 0.00542187690735
Taking Off
AT*REF=19,290718208
Moving Forward
AT*PCMD=92,3,0,-1102263091,0,0
Landing
AT*REF=102,290717696
AT*REF=103,290717696
AT*PWM=104,0,0,0,0
** Com -> Nav : die!
** Com -> Vid : uninit
** Com -> Vid : die!
** Vid -> Com : uninit
Last edit: Sebastien Siva 2015-10-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there seems all OK as fare I can see.
The commands to the drone are absolutely correct, no strange configuration or something like that.
The consiguration seems OK, too (wow, your drone is pretty new). The offset-values are a litte bit different, e.g.
Yours: ['control:accs_offset', '{ -3.9437852e+03 4.0887598e+03 4.2412783e+03 }']
Mine: ['control:accs_offset', '{ -3.9962664e+03 4.1537573e+03 4.1192974e+03 }']
...but absolutely nothing to worry about.
Strange problem...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
regarding your sliding-problem, it may be indeed the firmware.
Seems that the self-alternation of the slope-sensors I mentioned are a big problem and firmware 2.4.8 does not fix the problem good enough.
I suggest to downgrade to firmware 2.2.6, it works as it should, without any strange corrections by the system (especially like version 2.3.3). The command getSelfRotation() will help to count out that self-alternation, the measured value will also respected at the turnAngle()-command.
Have a great day,
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Thanks for the great work! Can you help me understand why my drone goes right(ish) when I use moveForward()? Is this related to trim configuration / calibration?
Thanks,
Sebastien
Hi Sebastien,
thank you :-)
I know what you mean, I had this problem myself. The drone reacts like this, when the propellers are damaged. Maybe you noticed, that the drone also drifts to a side or need a lot of space while turning. Changing the propellers is not a big deal.
The drone calibrates its sensors while it is booting and with the command "trim()" of cause.
The firmware does normally a really good job, even if the ground is not completely horizontal. I guess there is a second calibrating-step while starting, using the data of the accelerator.
By the way: when the drone is turning, is the stabilization isn't using the accelerator-sensors and the drone wobbles, depending on the condition of the propellers more or less. Maybe Parrot will fix it some when (the mechanisms are pretty complicated, so I don't think so)
Guess I am in smart ass today X-D
Have a great day,
Philipp
Thanks for the quick reply!
Unfortunately, replacing the propellers had no effect. Perhaps it is damage to the hull (indoor shell)? Or perhaps it is some internal sensors that were physically shifted in a crash? Anyways, doing callibration / trim has had no effect either :(
Thanks,
Sebastien
Hmmm...I can't imagine, that your problem is caused by sensor or calibration-failures. Maybe a gear-weels is damaged, dirty or something like that.
Personally, I would change the propellers, gear-weels and maybe the controller-boards from one limb to an other and see what happens.
Does the drone hold position when its just hovering ? If you let it turn, does it glide away (it may fly a circle with a diameter of one meter, that's OK). Walls or large objects nearby could violate the air-flow and "suck" the drone in its direction. Did you try to let fly the drone to the opposite direction...this may sound weird, but may help to find the problem. And does it drift to the right while flying forward and backward ?
One of my indoor-shell is also pretty damaged, but I never noticed its causing a drift...but maybe ;-)
Sure that the central cross is OK ? (take the drone at a left and a right limb, everything has to be fix and no movement at all)
Good luck,
Philipp
So I am getting this strange flying right behavior no matter what command I give the drone. Commands like turnRight and moveUp do the same thing. Here are some tests I have done:
Is it possible that the firmware is the issue?
['general:num_version_config', '1']
['general:num_version_mb', '34']
['general:num_version_soft', '2.4.8']
['general:soft_build_date', '2013-09-16 14:49']
Thanks,
Sebastien
Hi Sebastien,
wow...you really took care of that problem and to be honest: I am out of ideas right now.
The comparisons you did are really interesting.
In a nutshell: The drone (or its firmware) flies always by itself, controlled by some movement-commands. So the running client-system and software shouldn't have an effect on the flight-behavior.
Especially the movement-part is less magical than the rest. Of cause, I believe you and your test-results, so let's brainstorm:
With the firmware 2.3.3, there was a self-alternation of the slope-sensor-values, individual for every drone and depending on the temperature in the room (about 0,0019°/s, -0,0055°/s and 0,0258°/s for X-, Y- and Z-axis...I muttered about this in my master-thesis). The drone stood still but it was a problem to calculate directions (so I added the command getSelfRotation()). Parrot fixed this value-self-alternation with firmware 2.3.3, but then the drone rotaded about 1°/s. With firmware 2.4.8 they fixed it again, now it's better, but not perfect. Anyway, this is the only case I know the firmware messed the movement up.
PS-Drone, python-ardrone and programs based on Parrots SDK (like Freeflight) work the same way. The programs command the drone to fly this or that direction and the firmware takes care of executing it. So there are some basic commands which always work (these commands also still work with parrot-ardrone). The protocols and (most) commands are described in Parrot's Developer Guide for SDK 2.0.
In a nutshell, they are structured like this:
AT*<cmd>=<num>,<param1>(,<param2>,<param3>…)
Parameters must be strings, covered in quotes or integer (IEEE-754 floating-points have to express as a 32-bit signed integer).</param3></param2></param1></num></cmd>
Basically you just need this commands to make the drone move:
takeoff() ATREF=3,290718208
moveForward(0.2) ATPCMD=4,3,0,-1102263091,0,0
drone.land() AT*REF=5,290717696
That's all what happens...or these are the basic commands to make the movements. PS-Drone does a bit more to make sure everything runs perfectly, but python-ardrone does (nearly) just these steps shown above.
Change the value of showCommands (3.8, page 42) to True (drone.showCommands=True) before using other drone-commands, so all commands to the drone (and between the processes) will be displayed (ok, I confess, the keep-alive-commands are missing).
By the way, the keep-alive command is: AT*COMWDG=6
You will also notice two commands will be sent at the beginning:
ATPMODE=1,2
ATMISC=2,2,20,2000,3000
I sniffed them from the network while playing around with the parrot-demo-programs, but the meaning of their parameters are not documented. I decided to send them too, but there is no noticeable visible benefit.
After that, PS-Drone sets NavData to demo-mode (to prevent unexpected behavior) and the Session-ID to “-all” and downloads the drone's configuration.
I have my drone not here right now to describe it exactly, but you may see also something like this:
AT * CTRL=6,4,0 Download the actual configuration of the drone.
AT * CTRL=7,5,0 Reset the confirmation-bit of the drone
Setting the NavData-Demo-Mode will look something like this:
AT*CONFIG=8,”general:navdata_demo", "TRUE" Set a configuration
AT * CTRL=9,5,0 Reset confirmation
AT * CTRL=10,4,0 Download new configuration
AT * CTRL=11,5,0 Reset configuration
I hope you agree that there shouldn't be a different behavior using different APIs. So the question is, why the drone behaves different to Note-Copter.js and Test-Flight, I am sure they're working the same way as PS-Drone, but I also believe your testings.
Of cause, there is another way to control the drone's movement:
The second part of my master-thesis was a program to make the drone fly fully controlled by the client (without firmware) using the pwm()/thrust()-command, but I haven't it published until now. It's a proof of concept anyway, with a subset of the drone's sensor-values, because the drone keeps staying in landed-mode...but that's another loooong story.
Anyway, I am absolutely sure, that no API-developer is insane enough to even think about implementing a movement-control as in my proof-of-concept into something like PS-Drone or Node-Copter.js...really, this guy would also try to invade russia...in winter...alone and naked...riding a hamster. X-D
I still guess there might be a problem with at least one of your propellers, but its a good idea to think about an auto-correction of the direction, in case the accelerator-sensors measure some unexpected movements - but it might be pretty complicated, if you don't move to a basic direction (forward/backward/left/right)...so a solution may take a while.
Did you try to correct it manually, using move() ? (e.g. move(-0.01,0.5,0.0) )
Did you try mantrim() ? (It may not be supported by the AR.Drone 2.0 (anymore))
Is it possible to capture the command-network-stream (UDP Port 5556) while using Node-Copter ?
I hope my answer was more helpful than confusing. You are very welcome for more brainstorm, of cause also by direct e-mail.
Best wishes,
Philipp
So this program:
Created this output:
Last edit: Sebastien Siva 2015-10-21
Here is my config output if someone can see if some fundamental setting is incorrect.
Battery: (69, 'OK')
['general:num_version_config', '1']
['general:num_version_mb', '34']
['general:num_version_soft', '2.4.8']
['general:drone_serial', 'PS721003AJ5C120879']
['general:soft_build_date', '2013-09-16 14:49']
['general:motor1_soft', '1.43']
['general:motor1_hard', '6.0']
['general:motor1_supplier', '1.1']
['general:motor2_soft', '1.43']
['general:motor2_hard', '6.0']
['general:motor2_supplier', '1.1']
['general:motor3_soft', '1.43']
['general:motor3_hard', '6.0']
['general:motor3_supplier', '1.1']
['general:motor4_soft', '1.43']
['general:motor4_hard', '6.0']
['general:motor4_supplier', '1.1']
['general:ardrone_name', 'My ARDrone']
['general:flying_time', '2119']
['general:navdata_demo', 'TRUE']
['general:com_watchdog', '2']
['general:video_enable', 'TRUE']
['general:vision_enable', 'TRUE']
['general:vbat_min', '9000']
['control:accs_offset', '{ -3.9437852e+03 4.0887598e+03 4.2412783e+03 }']
['control:accs_gains', '{ 1.9606570e+00 1.2555313e-02 -2.6172021e-02 -4.8873393e-04 -1.9554956e+00 -1.8910773e-02 -4.7443885e-02 6.0357885e-03 -2.0014458e+00 }']
['control:gyros_offset', '{ 3.6246250e+01 8.9333748e+01 -1.8285000e+01 }']
['control:gyros_gains', '{ 1.0690530e-03 -1.0612491e-03 -1.0754864e-03 }']
['control:gyros110_offset', '{ 1.6625000e+03 1.6625000e+03 }']
['control:gyros110_gains', '{ 1.5271631e-03 -1.5271631e-03 }']
['control:magneto_offset', '{ 3.6478796e+02 2.7571460e+02 0.0000000e+00 }']
['control:magneto_radius', '4.2629150e+02']
['control:gyro_offset_thr_x', '4.0000000e+00']
['control:gyro_offset_thr_y', '4.0000000e+00']
['control:gyro_offset_thr_z', '5.0000000e-01']
['control:pwm_ref_gyros', '500']
['control:osctun_value', '0']
['control:osctun_test', 'TRUE']
['control:altitude_max', '100']
['control:altitude_min', '50']
['control:outdoor', 'FALSE']
['control:flight_without_shell', 'FALSE']
['control:autonomous_flight', 'FALSE']
['control:flight_anim', '0,0']
['network:ssid_single_player', 'ardrone2_120879']
['network:ssid_multi_player', 'ardrone2_120879']
['network:wifi_mode', '0']
['network:wifi_rate', '0']
['network:owner_mac', '00:00:00:00:00:00']
['pic:ultrasound_freq', '8']
['pic:ultrasound_watchdog', '3']
['pic:pic_version', '184877090']
['video:camif_fps', '30']
['video:camif_buffers', '2']
['video:num_trackers', '12']
['video:video_storage_space', '20480']
['video:video_on_usb', 'FALSE']
['video:video_file_index', '4']
['leds:leds_anim', '0,0,0']
['detect:enemy_colors', '1']
['detect:enemy_without_shell', '0']
['syslog:output', '7']
['syslog:max_size', '102400']
['syslog:nb_files', '5']
['general:localtime', '0']
['gps:ephemeris_uploaded', '']
['gps:fw_upload_trigger', '0']
['flightplan:default_validation_radius', '3.0000000e+00']
['flightplan:default_validation_time', '1.0000000e-03']
['flightplan:max_distance_from_takeoff', '1000']
['flightplan:gcs_ip', '3']
['flightplan:video_stop_delay', '10']
['flightplan:low_battery_go_home', 'FALSE']
['flightplan:automatic_heading', 'TRUE']
['flightplan:com_lost_action_delay', '0']
['flightplan:altitude_go_home', '0.0000000e+00']
['flightplan:mavlink_js_roll_left', 'x-']
['flightplan:mavlink_js_roll_right', 'x+']
['flightplan:mavlink_js_pitch_front', 'y+']
['flightplan:mavlink_js_pitch_back', 'y-']
['flightplan:mavlink_js_yaw_left', '4']
['flightplan:mavlink_js_yaw_right', '5']
['flightplan:mavlink_js_go_up', '0']
['flightplan:mavlink_js_go_down', '1']
['flightplan:mavlink_js_inc_gains', '6']
['flightplan:mavlink_js_dec_gains', '7']
['flightplan:mavlink_js_select', '8']
['flightplan:mavlink_js_start', '9']
['general:gps_soft', '0.0']
['general:gps_hard', '0.0']
['general:localtime_zone', '0000-00-00T00:00:00+0000']
['general:timezone', '-429496729200']
['general:battery_type', '1']
['general:gps_soft_update', '4.1.2-P6']
['general:navdata_options', '65537']
['control:control_level', '0']
['video:bitrate', '1000']
['video:bitrate_ctrl_mode', '0']
['video:bitrate_storage', '4000']
['custom:application_desc', 'Default application configuration']
['control:euler_angle_max', '1.0000000e-01']
['control:control_iphone_tilt', '0.0000000e+00']
['control:control_vz_max', '7.0000000e+02']
['control:control_yaw', '8.0000001e-01']
['control:manual_trim', 'FALSE']
['control:indoor_euler_angle_max', '1.0000000e-01']
['control:indoor_control_vz_max', '7.0000000e+02']
['control:indoor_control_yaw', '8.0000001e-01']
['control:outdoor_euler_angle_max', '5.0000001e-02']
['control:outdoor_control_vz_max', '7.0000000e+02']
['control:outdoor_control_yaw', '1.7453293e+00']
['custom:profile_desc', 'Default profile configuration']
['control:flying_mode', '0']
['control:hovering_range', '1000']
['video:codec_fps', '30']
['video:video_codec', '129']
['video:video_slices', '0']
['video:video_live_socket', '0']
['video:max_bitrate', '1000']
['video:video_channel', '0']
['video:exposure_mode', '0,0,0,0']
['video:saturation_mode', '0']
['video:whitebalance_mode', '0,0']
['detect:groundstripe_colors', '16']
['detect:detect_type', '3']
['detect:detections_select_h', '0']
['detect:detections_select_v_hsync', '0']
['detect:detections_select_v', '0']
['userbox:userbox_cmd', '0']
['gps:latitude', '5.0000000000000000e+02']
['gps:longitude', '5.0000000000000000e+02']
['gps:altitude', '0.0000000000000000e+00']
['custom:application_id', '00000000']
['custom:profile_id', '00000000']
['custom:session_id', '00000000']
['custom:session_desc', 'Default session configuration']
['control:flying_camera_mode', '0,10,1500,0,1000,0,0,0,0,0']
['control:flying_camera_enable', 'FALSE']
['gps:accuracy', '0.0000000000000000e+00']
['rescue:rescue', '0']
Hi Sebastien,
there seems all OK as fare I can see.
The commands to the drone are absolutely correct, no strange configuration or something like that.
The consiguration seems OK, too (wow, your drone is pretty new). The offset-values are a litte bit different, e.g.
Yours: ['control:accs_offset', '{ -3.9437852e+03 4.0887598e+03 4.2412783e+03 }']
Mine: ['control:accs_offset', '{ -3.9962664e+03 4.1537573e+03 4.1192974e+03 }']
...but absolutely nothing to worry about.
Strange problem...
Hi,
regarding your sliding-problem, it may be indeed the firmware.
Seems that the self-alternation of the slope-sensors I mentioned are a big problem and firmware 2.4.8 does not fix the problem good enough.
I suggest to downgrade to firmware 2.2.6, it works as it should, without any strange corrections by the system (especially like version 2.3.3). The command getSelfRotation() will help to count out that self-alternation, the measured value will also respected at the turnAngle()-command.
Have a great day,
Philipp