Skip to content
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

RFC: Local frames of reference revision #2

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@korigod
Copy link
Contributor

korigod commented Mar 21, 2018

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

RFC: Local frames of reference revision
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.

@korigod korigod referenced this pull request Mar 22, 2018

Open

Local and body frames #861

* `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);

This comment has been minimized.

Copy link
@TSC21

TSC21 Mar 22, 2018

Member

Isn't this the same as the BODY_FRD?

This comment has been minimized.

Copy link
@korigod

korigod Mar 22, 2018

Author Contributor

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).

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 23, 2018

@TSC21 Continuing discussion started in mavlink/mavlink#869.

APM developers are open to make their comments and suggest one concept. But, in any situation, the Mavlink spec should go according to a specific meaning and implementation of an autopilot firmware. A good reference to what a "body-fixed" frame is can be found here: https://ccrma.stanford.edu/~jos/pasp/Body_Fixed_Space_Fixed_Frames_Reference.html. So, at my view, FLU and FRD do not have to be normal to the ground, but actually should be coincident with principal directions set for the body. So, everything that is actually aligned with a space-fixed frame should be earth aligned, meaning that it is NED or ENU for our use case. If it is related to the body frame, then it is FLU or FRD.

Ok, but BODY_NED is not described exactly as "body-fixed", it's just "Setpoint in body NED frame". Lots of developers call their ground-normal frames "body frames" is their yaw is fixed to the vehicle, I have some references in the RFC proposal (Prior art).

I'm not against FRD and FLU as body-fixed frames at all. I'm just thinking about how to name "body-yaw z-normal-to-ground" frames in this case because they are also quite useful.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 23, 2018

I'm not against FRD and FLU as body-fixed frames at all. I'm just thinking about how to name "body-yaw z-normal-to-ground" frames in this case because they are also quite useful.

Why not FRD_NORMAL and FLU_NORMAL? BODY_NED should actually be deprecated IMO. Seems it is something like considering the Earth as the body and the vehicle is moving WRT it.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 23, 2018

Maybe FRD_HORIZ and FLU_HORIZ? Looks a bit more clear to me. However, it's quite long designations.

BODY_NED should actually be deprecated IMO.

We need the NED-oriented frame with the origin fixed to the vehicle, I think BODY_NED is quite good name for this. So I think maybe we better deprecate _OFFSET_ frames.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 23, 2018

We need the NED-oriented frame with the origin fixed to the vehicle

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.

Maybe FRD_HORIZ and FLU_HORIZ? Looks a bit more clear to me. However, it's quite long designations.

FRD_HRZ and FLU_HRZ then.

So I think maybe we better deprecate _OFFSET_ frames.

"MAV_FRAME_LOCAL_OFFSET_NED Offset to the current local frame. Anything expressed in this frame should be added to the current local frame position." For me it is clear this is actually a frame that you consider with a transform relative to the LOCAL_NED. So it's like a space-fixed frame with a translation (and maybe a rotation) relative to the LOCAL_NED frame of reference. Deprecating it or not, it does make sense, but probably not really useful.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 23, 2018

How can we have a NED-oriented frame and at the same time have the origin fixed on the vehicle?

Why not? E.g. it can be useful to specify a position target / waypoint "100 m to the north of the current vehicle posiion".

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 23, 2018

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.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 23, 2018

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 AUTO mission "take off, fly 100 m to the North, land".

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 23, 2018

fly 100 m to the North

Again, WRT to space-fixed frame, not body frame. Earth has a North, the vehicle does not.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 24, 2018

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.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 24, 2018

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 FLU or FRD. North relates to geographic North, and that only makes sense to apply to a Earth-fixed Cartesian frame.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 24, 2018

Why can't the vehicle move 100 m to the North from the current location? Why cannot I e.g. send MAV_CMD_DO_REPOSITION in BODY_NED to move the vehicle 20 m to the East (x = 0, y = 20, z = 0)?

Moreover, NED can be also used indoor as e.g. MOCAP_NED. It might be not related to the magnetic/geographic North at all, it's just some selected direction.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 24, 2018

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.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 24, 2018

Moreover, I point you to ROS REP 103, where you can read:

Axis Orientation
In relation to a body the standard is:

x forward
y left
z up

For short-range Cartesian representations of geographic locations, use the east north up (ENU) convention:

X east
Y north
Z up

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).

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 24, 2018

The cited fragment is about Axis Orientation. In BODY_NED frame I suggest to use NED orientation, not the body-fixed one! It could be ENU which you referenced here as well, but not body.

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.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 24, 2018

The cited fragment is about Axis Orientation.

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.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Mar 24, 2018

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.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 24, 2018

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?

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 BODY frames.

@korigod

This comment has been minimized.

Copy link
Contributor Author

korigod commented Mar 24, 2018

By the way, APM currently supports the frame which we are discussing, they use LOCAL_OFFSET_NED for exactly the same behavior:

Positions are relative to the current vehicle position in the North, East, Down (NED) frame. Use this to specify a position x metres north, y metres east and (-) z metres of the current vehicle position.

http://ardupilot.org/dev/docs/copter-commands-in-guided-mode.html#copter-commands-in-guided-mode-set-position-target-local-ned

I just think LOCAL_OFFSET is not the best name here because they use it to specify the vehicle coordinates, not some offset.

@dagar

This comment has been minimized.

Copy link
Member

dagar commented Aug 3, 2018

What's the current state of this?

@hamishwillee

This comment has been minimized.

Copy link

hamishwillee commented Dec 20, 2018

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?

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Dec 20, 2018

@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.

@hamishwillee

This comment has been minimized.

Copy link

hamishwillee commented Dec 20, 2018

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:

  • Positions are relative to the current vehicle position in a frame based on the vehicle’s current heading. Use this to specify a position x metres forward from the current vehicle position, y metres to the right, and z metres down (forward, right and down are “positive” values).
  • Velocity directions are relative to the current vehicle heading. Use this to specify the speed forward, right and down (or the opposite if you use negative values).
@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Dec 20, 2018

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.

@TSC21

This comment has been minimized.

Copy link
Member

TSC21 commented Dec 20, 2018

And yes, BODY_OFFSET_NED and BODY_FRD are completely different by definition, starting the on the orientation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.