Configuring TF tree for a system that inherently uses NED (North-East-Down) convention?

asked 2020-03-30 23:08:43 -0500

hashirzahir
228 ●1 ●14 ●7

I know how to perform transforms between an ENU and NED frame (a simple static flip) but my question here is more of how do I configure the TF tree if the existing codebase assumes everything as NED (x forward, y right, and z down). For example the controls algorithms, pose, laser scans and costmaps are assumed to be in NED. I have read REP 103 and REP 105 on conventions to label the TF tree for frames that do not follow the ENU convention, for example, odom_ned frame.

If the TF tree were to look something like this:

map -> odom -> base_link -> (Many static child frames)

how should the TF tree be modified to work with NED convention and without things looking strange in RVIZ?

Is this an accurate TF tree for NED:

map -> map_ned -> odom_ned -> base_link_ned -> (Many static child frames)

where there is a static TF transform between map and map_ned?

answered 2020-03-31 03:36:09 -0500

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

As soon as you appropriately attached a tf frame_id to data. There is no longer any difference between an NED frame and an ENU frame. All data can be transformed in or out of any connected frame.

If you have a data source that works in NED, you can just create the frame which is attached to the tf tree to orient correctly for that sensor. The best example of this is that cameras typically have an *_optical frame attached which is Z forward as that's how vision algorithms users thing about things. But once that frame is attached to the tf tree. It will be transformed into any working frame you desire and no process downstream will care if the original frame was NED, ENU, or Z forward as long as the data is accurately registered with the coordinate frame it's labeled with and that's attached to the tf tree.

If you want to process all data in an NED frame for a flight controller just attach a frame to the standard base_link that's rotated appropriately to be my_frame_NED and transform any data into that coordinate frame.

My point is that you should not try to create a new separate tree with parallel versions of every frame. As long as you have everything well connected in tf rviz and all the other data processing will not care if that data started with NED or ENU.

For adding an NED sensor and an NED processing frame you'd just need the following two additions to the tf tree.

map -> odom -> base_link -> (many frames) -> my_ned_sensor_frame 
                                \_ my_custom_processing_frame (maybe NED)

edit flag offensive delete link

Comments

Thanks for the amazing answer. I realized that I had not understood TFs fully.

I have a another doubt, what if the odom sensor outputs ENU based data and I want to perform a lookup relative to my base_frame in NED coordinates (since codebase works in NED). As typical URDF static publishers follows ENU format, base_link will also be in ENU and hence I will need to create a child frame of base_link called base_link_ned and I perform the lookup from map to base_link_ned. Is this accurate?

odom ------>base_link --> (many frames)
                  |
                  |------> base_link_ned

hashirzahir ( 2020-03-31 08:27:37 -0500 )edit

That sounds right.

tfoote ( 2020-04-03 00:36:37 -0500 )edit

add a comment

Configuring TF tree for a system that inherently uses NED (North-East-Down) convention?

1 Answer

Comments

Question Tools

Stats

Related questions

Configuring TF tree for a system that inherently uses NED (North-East-Down) convention? edit

1 Answer

Comments

Question Tools

Stats

Related questions

Configuring TF tree for a system that inherently uses NED (North-East-Down) convention?