hi,
I am wondering how hard it is to integrate an external accurate INS device and why there is no such an interface in px4 or ardupilot. is it because the raw IMU measurments are also used in the controllers? but an INS solution could provide such measurements with high update-rates.
I am looking at this because I am trying to design a VTOL tail sitter and noticed that the roll readings are way off and almost random when the autopilot is at 90deg pitch angle.
if there is no issue, can I just replace the ekf2_main.cpp code to read from a serial device and publish the INS attitude?
input: UART like gps module
output:
orb_publish(ORB_ID(vehicle_attitude), _att_pub, &att);
uORB::Publication<vehicle_local_position_s> _vehicle_local_position_pub;
uORB::Publication<vehicle_global_position_s> _vehicle_global_position_pub;
Hi,
While there are examples of projects that have integrated an external INS unit it does not seem like that is what you need.
What you are seeing at 90 deg pitch is just gimbal lock of the Euler angle representation and has nothing to do with the accuracy of the state estimator or the sensors
I appreciate the fast response and I thought the same the first time.
However, based on my previous digging in the code, I noticed that the ekf2 is actually using quaternion and not DCM–> euler calculations which should remove the gimble lock issue as stated in the wiki page you posted. Did I make the wrong observation?
regardless, the issue is that different vehicles have different requirements. for instance, a rover or a submarine could use totally different localization solutions as there is no GPS in water and as robots are usually in 2d flat terrain.
could you point me to those projects that used an INS with px4 or ardupilot?
I only noticed uINS but according to them they dropped the support and the INS is actually feed through GPS port which make me wonder if they even use its orientation or the internal imu for the controller
Yes, the EKF is using quaternions to represent the attitude solution. You stated above that you noticed issues in the roll angle at 90 pitch. I assumed that you were looking at the roll angle converted from the quaternion using a 321 Tait Brian sequence (since this is the standard sequence most open source log analysis softwares use) and in that case you would indeed be in gimbal lock. If you on the other hand meant that the roll angle converted from a 312 Tait Brian sequence was “almost random” at 90 degree pitch there is another problem. Can you please share the logfile?
Interesting! thank you for clearing this up
I pitched the pix 90 deg up and it seems that the yaw and roll are locked at the first 40 sec when I wiggle the pitch back and forth (80 to 100 deg) but the roll readings are not correct even after the first 40 sec when I slowly roll the vehicle from 0 to 360 and back to -360 for 2 times.
regarding the lock, do you mean that this issue is only present on visualization but the quaternions themselves are actually healthy? because I noticed that the Quaternion to eular (321,312,…) conversions in the firmware are only present in 2 main functions dealing with yaw correction using mag or using the gps. (in ekf_helper.cpp & mag_fusion.cpp)
how to resolve this? especially for the roll readings not changing when I roll slowly with 90 deg pitch angle
regarding the lock, do you mean that this issue is only present on visualization but the quaternions themselves are actually healthy?
Yes
how to resolve this? especially for the roll readings not changing when I roll slowly with 90 deg pitch angle
That depends on what you mean with resolve. In order to be able to control the vehicle in any attitude you need to either switch from different Euler angle sequences depending on the current attitude or use a representation that does not experience this problem, e.g. quaternions or rotation matrices. As we already discussed, the EKF is using quaternions.
When it comes to visualizing the attitude the easiest is to use Euler angles. For a tailsitter a 312 Tait-Brian sequence is the best since it regularly is at 90 deg pitch but not 90 deg roll.
what about the 0 to 360 roll not actually making the roll angle change but it strangely make the yaw go to 360 (maybe because my hand is not 100% accurately pitching the pix at 90 deg and a yaw will reflect the heading regardless) but if we have a deadlock, should not the roll and yaw get locked and reflect the same correct 360 deg angle?
maybe because fuseHeading() in mag_fusion.cpp use magnetic compass to correct yaw only and not roll at that particular orientation?
maybe because fuseHeading() in mag_fusion.cpp use magnetic compass to correct yaw only and not roll at that particular orientation?
No, as I said above, the issue you are experiencing is due to gimbal lock of the Euler angle representation of the estimated quaternion, it has nothing to do with the attitude estimate itself.
what about the 0 to 360 roll not actually making the roll angle change but it strangely make the yaw go to 360 (maybe because my hand is not 100% accurately pitching the pix at 90 deg and a yaw will reflect the heading regardless) but if we have a deadlock, should not the roll and yaw get locked and reflect the same correct 360 deg angle?
I don’t really follow this but what you need to understand is that at 90 degree pitch the 321 Euler angle representation hits a singularity, so you need to stop looking at that and looking at a 312 Euler angle representation
Here are the 321 Euler angles from the logfile you posted above
