Pitch control bias
Closed this issue · 4 comments
Hi there,
Recently I've implemented a PD controller on Pelican using ACC control mode for x-direction position control. When I sent 0 deg in pitch, the vehicle started moving forward. So I gradually increased the value to let the vehicle stay still until 3 deg. Then I tried 4 deg, the vehicle started to move backward. I think there might be a bias. Would you please tell me if I have to do some calibration of the vehicle to eliminate this bias? I don't really think is the problem of asctec_hl_interface, cuz this driver is just sending the mapped value to LLP. Not sure if roll control has the same problem, I'll test it tomorrow.
I'm looking forward to hearing from u. Many thanks!
Cheers,
Lyn
The problem ist that attitude solely based on accelerometers and gyros is not very well observable [1], so this might be normal behaviour. It might help if you calibrate your accelerometers again, in order to get better estimates.
[1] Martin, P., & Salaün, E. (2010). The true role of accelerometer feedback in quadrotor control. In Robotics and Automation ICRA 2010 IEEE International Conference on (pp. 1623-1629).
From: rocklinsuv <notifications@github.commailto:notifications@github.com>
Reply-To: ethz-asl/asctec_mav_framework <reply@reply.github.commailto:reply@reply.github.com>
Date: Monday 19 May 2014 10:18
To: ethz-asl/asctec_mav_framework <asctec_mav_framework@noreply.github.commailto:asctec_mav_framework@noreply.github.com>
Subject: [asctec_mav_framework] Pitch control bias (#20)
Hi there,
Recently I've implemented a PD controller on Pelican using ACC control mode for x-direction position control. When I sent 0 deg in pitch, the vehicle started moving forward. So I gradually increased the value to let the vehicle stay still until 3 deg. Then I tried 4 deg, the vehicle started to move backward. I think there might be a bias. Would you please tell me if I have to do some calibration of the vehicle to eliminate this bias? I don't really think is the problem of asctec_hl_interface, cuz this driver is just sending the mapped value to LLP. Not sure if roll control has the same problem, I'll test it tomorrow.
I'm looking forward to hearing from u. Many thanks!
Cheers,
Lyn
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20.
Hi Markus,
Thanks for your advice. Pitch problem sovled by re-calibrating the IMU. However, when I was testing the Roll control today, I discovered a wired behavior of Pelican.
Let's say the X-Positive of Pelican is facing North, Y-Positive of Pelican is facing East, I'm standing right behind Pelican, facing North as well. When I used the RC transmitter, move the Roll stick to the right, Pelican flew toward East, /fcu/rcdata showed a value larger than 2048. Roll stcik to the left, Pelican flew toward West, that value is less than 2048.
But when I used asctec_hl_interface to send a 5 degree in roll to Pelican, it flew toward West, seems like it's reversed. I also print the value ctrlLL.y in "hl_interface.cpp", which is a positive 200 something. Any idea what's going on? I could actually add a "minus" in hl_interface.cpp, but would like to know why :D. Thanks again for your help!
Cheers,
Lyn
hi lyn,
this is a bit counter-intutive unfortunately, we tried to use this one message for all kinds of controls:
please have a look at the comments in https://github.com/ethz-asl/asctec_mav_framework/blob/master/asctec_hl_comm/msg/mav_ctrl.msg: we interpret attitude in terms of acceleration, i.e. positive roll accelerates in the direction of the negative body-y axis, and positive pitch accelerates in the direction of the positive body x axis. I think this explains the behaviour you observed
Thanks Markus,
Issue solved. Just reversed the signs in the codes. I think the issue can be close now.
Cheers,
Lyn