Instability of AscTec Pelican

alek-b commented 11 years ago

Dear Stephan,

we are currently testing the navigation system of the mav framework. The localization system made with ethz asl sensor fusion works very well, but now when we try to define a waypoint we are facing some problem: the UAV becames very instable. We get the some problem also trying to take the UAV in hovering on a fixed point. So, we would like to ask you a few things:

1 - Could you please send us the list of parameters currently published in the fcu/ssdk_debug topic?

2- Would it be possible to have access to the ssdk model ? (very useful in case we have to add/modify a few things, or consider other debug parameters)

Thanks

Alessandro

markusachtelik commented 11 years ago

Hi Alessandro,

This is usually because of some coordinate mis-alignments and/or wrong yaw. Did you do the checks described here: http://www.ros.org/wiki/asctec_hl_interface/Tutorials/hlp%20position%20control#Sanity_Checks (still hold when using sensor fusion, just skip the acc biases part)

A few other ideas:

is the ~state_estimation parameter set to HighLevel_EKF ?
is ~position_control set to HighLevel ? (like described here: http://www.ros.org/wiki/ethzasl_sensor_fusion/Tutorials/sfly_framework#Parameters_for_the_AscTec_HighLevel_.28HL.29_Interface)
are the topic connected as shown here: http://www.ros.org/wiki/ethzasl_sensor_fusion/Tutorials/sfly_framework?action=AttachFile&do=get&target=sfly_rxgraph.eps

1) you can have a look at the plot_* scripts in the scripts folder of asctec_hl_interface. That should be pretty complete. 2) difficult right now, I'll have to check with asctec.

Best, Markus

alek-b commented 11 years ago

Dear Markus,

In our setup, the update sensor gives the position measurement in the world reference that we choose, so we set up measurement_world_sensor = true.

We have the mentioned values for ~state_estimation and ~position_control.

The sanity check (using the ethz asl sensor fusion) is ok.

We think that the topics are well connected since the Localization system (made with ethzasl sensor fusion) gives good results both for position and velocity.

Our world reference system is ENU, the origin is fixed on the bottom left corner of a rectangle, x positive on the right, y positive on front, z positive toward up.

Since the AscTec IMU coordinate system is NED with the x axis on the left arm with orange marker, while the associated IMU ROS packets is in ENU (same on the x axis), should we need to initialize the filter with the drone x axis along the x axis of the world reference system keeping the initial quaternion value at [1 0 0 0]?

Within this setup we started testing the performance of the control system during the hovering of the UAV. Using the default values for the control system and the feed-forward filter (we just modified the value of the mass according to our payload) we are facing the following problems:

1) Regarding the z control (carried out disabling the control on x and y axis), when we activate the GPS position (with the stick in central position),

if we keep on hand the drone (as suggested on Point 5 of the Hovering procedure, it behaves as expected: the rotors keep the current speed. But if we try to leave it, it starts oscillating around the set-point abruptly (we didn't take the hazard to let the UAV fly freely for more than 5/6 seconds, so we didn't check the convergence)

2) Regarding the x,y control (carried out disabling the control on z axis), when we activate the GPS position (with the stick in central position), the UAV starts moving on arbitrary direction, it seems to try to compensate it but becames suddenly instable.

What do you exactly mean with coordinate misalignement and wrong yaw? Do you think there are some problem with our configuration?

Should be the problem related to the speed of the Sensor Fusion algorithm (update) (that in our case is 10 Hz)?

stephanweiss commented 11 years ago

Alessandro,

I assume you are using the MULTI_sensor module you described earlier in other issues and that this module provides 3D position at 10Hz. Please let me know if these assumptions are incorrect.

Depending on the quality of your measurement, the yaw in this setup is not very well observable - and you need quite a bit of x,y-motion to make it converge. Thus, you want to initialize global yaw as accurately as possible. This might explain the x,y oscillations you observe. As for the z-instability: did you have a look at the raw sensor data? I.e. does the z-measurement spike and are the timestamps correct?

Also, follow closely the instructions in asctec_mav_framework concerning the switches. E.g. the sequence: serial off & control off => switch hight control on => switch serial on => switch GPS on does NOT activate the 6DoF pose controller but stays in hight control. The correct sequence is: serial off & control off => serial on => GPS on. We should change that at some point...

Hope this helps. Stephan

From: alessandro-benini [notifications@github.com] Sent: Tuesday, July 09, 2013 9:05 AM To: ethz-asl/asctec_mav_framework Subject: Re: [asctec_mav_framework] Instability of AscTec Pelican (#7)