RFC: Local frames of reference revision #2
Conversation
Revise MAVLink local frames of reference to create a clear and comprehensive frames system. Agree on the frames naming convention, add some useful frames and correct the descriptions.
| * `ENU` for East-North-Up; | ||
| * `FRD` for Forward-Right-Down, where Forward and Right are tangential to the Earth and Down is normal to it; | ||
| * `FLU` for Forward-Left-Up, where Forward and Left are tangential to the Earth and Up is normal to it; | ||
| * `RPY` for Roll-Pitch-Yaw (fixed in orientation to the moving vehicle, z axis points down when vehicle is leveled, right-handed); |
There was a problem hiding this comment.
Isn't this the same as the BODY_FRD?
There was a problem hiding this comment.
In FRD frames only yaw is fixed to the vehicle, and z axis always stays normal to the Earth (vertical). In other words, FRD frame is the NED frame, rotated about the z axis by the vehicle yaw angle. In RPY all three axes are fixed to the vehicle, i.e. x axis is the vehicle roll axis. So in RPY frame z axis is not normal to the ground when the vehicle is tilted (not level).
|
@TSC21 Continuing discussion started in mavlink/mavlink#869.
Ok, but I'm not against |
Why not |
|
Maybe
We need the NED-oriented frame with the origin fixed to the vehicle, I think |
I don't actually get this. How can we have a NED-oriented frame and at the same time have the origin fixed on the vehicle? If the origin is fixed on the vehicle, then the orientation should be coincident with principal directions set for the body. If it is NED-oriented, then it is space-fixed, so, local frame.
" |
Why not? E.g. it can be useful to specify a position target / waypoint "100 m to the north of the current vehicle posiion". |
From that description, that is space-fixed local NED, where you know the vehicle position and you describe a target 100m North of its position. The definition of North should be applied to Earth-fixed frames, and not to body frames. |
Sometimes it's not possible to apply this translation by yourself — e.g. if you want to create an |
Again, WRT to space-fixed frame, not body frame. Earth has a North, the vehicle does not. |
I can't see the problem here honestly. They are both short-range Cartesian frames, just one has space-fixed origin and the other has body-fixed one. These are separate components: rotation and translation of the frame of reference. |
|
The only problem has to do with the usage of "North", as I already said. If you say move forward 100m, then probably it makes sense - and there you would have |
|
Why can't the vehicle move 100 m to the North from the current location? Why cannot I e.g. send Moreover, |
|
About the first question: If you are in the body frame, what you say will only apply if the 0-degree heading is pointing in the direction of the geographic North - That way, the vehicle would move 20 meters to the left, which corresponds to the geographic East. About the second question: MOCAP and VISION set a new heading, which is different from the magnetic /geographic heading - and that's why you set it as a new Cartesian system, cause they set what is the "Earth"-fixed frame of reference for the coordinates. |
|
Moreover, I point you to ROS REP 103, where you can read: Axis Orientation x forward For short-range Cartesian representations of geographic locations, use the east north up (ENU) convention: X east So in a body frame, you move forward, backward, left, right. So you should not have a mix between a body-fixed frame (FLU, FRD) and a space-fixed frame (NED, ENU). |
|
The cited fragment is about Axis Orientation. In Only the translation of the frame is fixed to the vehicle (to the body). The translation and the rotation are independent components of the transformation, aren't they? At least in Cartesian coordinates. |
And you say it right. So if they say that for the body, you use the body-fixed orientation, why are you using a NED orientation? I mean, you would want to keep conventions close to each other I guess. |
|
For me it is not intuitive to think of fixing the translation on the body and have the orientation related to the space. It's like having the heading of the vehicle completely off. |
No, the standard does not bind orientation of the frame to it's origin (translation) or vice versa. It just sets a convention on the direction of the axes: it proposes z-up convention, that's the whole point of the paragraph. So REP-103 says: if you choose body-oriented frame, you should use forward-left-up axes instead of forward-right-down or right-forward-up. If you choose earth-oriented frame, you should use ENU instead of NED or something else. That's it. I can choose any origin for my earth-oriented frame. Because ENU/NED according to this REP are Cartesian representations, translation is completely independent, as I said. Maybe it can be not very intuitive, but I can't see anything wrong with such a frame. It may be useful in some situations and it's way more clear and straight-forward than the current |
|
By the way, APM currently supports the frame which we are discussing, they use
I just think |
|
What's the current state of this? |
|
Does this RFC need to be updated in light of mavlink/mavlink@527bf53#diff-ceacc1e2390186650146a45be8fcb691 In particular, I would like to understand how MAV_FRAME_BODY_FRD differs from MAV_FRAME_BODY_OFFSET_NED and whether we can work to deprecate the later? |
|
@hamishwillee the "offset" case already makes it different from the first. It's an offset with respect to th body fixed frame. The fact that has NED, means that the X axis is aligned with North. |
@TSC21 I think you're misinterpreting how the frames work (or in this case dont work properly). The whole point of the is RFC is that the naming system is a bit broken, and this is particularly true of MAV_FRAME_BODY_OFFSET_NED The way this is actually used/defined sounds to me like MAV_FRAME_BODY_FRD. This is what ArduPilot docs say:
|
|
I am not discussing what this RFC wants to fix. I am only referring to the current definition of the frame, which is also on the description. |
|
And yes, BODY_OFFSET_NED and BODY_FRD are completely different by definition, starting the on the orientation. |
|
I like this RFC. It works for all the current non-deprecated frames except for My only concern is that I worry "BODY" is anecdotally often used to mean "aligned to frame - ie it's vehicle attitude", while proposal says this means "origin is set to vehicle" and RPY frame would indicate alignment to vehicle. Perhaps we should consider using "COG" instead of "BODY" for origin? Anyway, what can we do to progress this RFC and merge it? |
Summary
Revise MAVLink local frames of reference to create a clear and comprehensive frames system. Agree on the frames naming convention, add some useful frames and correct the descriptions.
Rendered