-
Notifications
You must be signed in to change notification settings - Fork 13.6k
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
Scale obstacle distance with vehicle attitude for varying sensor orientations (Collision Prevention) #24107
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks ok, but there is a more efficient way to do this without passing by euler angles. You can compensate for a tilt by taking the last element of
PX4-Autopilot/src/lib/matrix/matrix/Quaternion.hpp
Lines 521 to 541 in 4db55cd
/** | |
* Corresponding body z-axis to an attitude quaternion / | |
* last orthogonal unit basis vector | |
* | |
* == last column of the equivalent rotation matrix | |
* but calculated more efficiently than a full conversion | |
*/ | |
Vector3<Type> dcm_z() const | |
{ | |
const Quaternion &q = *this; | |
Vector3<Type> R_z; | |
const Type a = q(0); | |
const Type b = q(1); | |
const Type c = q(2); | |
const Type d = q(3); | |
R_z(0) = 2 * (a * c + b * d); | |
R_z(1) = 2 * (c * d - a * b); | |
R_z(2) = a * a - b * b - c * c + d * d; | |
return R_z; | |
} | |
}; |
Thanks! I am having a look now, but it's not intuitive to me how I could use this. I don't know if I am misinterpreting it but: Say I have a forward facing sensor, and I compute the quaternion of the rotated sensor (from the vehicle attitude) w.r.t the initial vehicle frame (FRD). Then taking the last element of |
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: -88 byte (-0 %)]
px4_fmu-v6x [Total VM Diff: -96 byte (-0 %)]
Updated: 2024-12-20T13:33:24 |
https://review.px4.io/plot_app?log=777e5193-7f40-40f5-a52d-d4f6fb519eba Log for flight test today with 45 degree mounted sensor, everything seems to work fine, no weird behaviour. @bresch is this ok to merge into main? |
src/drivers/distance_sensor/lightware_laser_i2c/lightware_laser_i2c.cpp
Outdated
Show resolved
Hide resolved
src/drivers/distance_sensor/lightware_laser_i2c/lightware_laser_i2c.cpp
Outdated
Show resolved
Hide resolved
src/drivers/distance_sensor/lightware_laser_i2c/lightware_laser_i2c.cpp
Outdated
Show resolved
Hide resolved
|
Solved Problem
Scaling of distance_reading to an obstacle was done under the assumption that the sensor was always mounted facing forward, so distance_reading was only scaled for pitch.
Solution
Orientation of sensor w.r.t vehicle body frame is taken into account, and the relevant vehicle attitude angles (pitch and/or roll) are used to scale the outputted distance.
Changelog Entry
For release notes:
Alternatives
We could also ...
Test coverage
Simulation/hardware testing logs: (Indoor, giving pitch/roll input manually for different sensor orientations @ fixed distance to flat wall)
Front facing:
Left facing (270 deg):
Roll scaling not super accurate in the 45deg case, probably because the placement of the sensor wasn't very exact. Can see it works well in the Left facing scenario.