Use frame of NavSatFixMsg about rviz_satellite HOT 23 CLOSED

#53 fixed the original problem, so we can close this issue. As we don't have an application for having a separate frame to load the frames in, I don't see that we will add this feature in this repository. However, we could continue discussion in another issue if this is something that you really want to have included.

from rviz_satellite.

Hey m-naumann,
I think I would like to do the same as you:
I want the coordinate system to be fixed! Plot the latitude longitude position of the robot in the map. And just load those tiles of the that are required if the robot goes over the edges ....

Best
Markus

PS: you can also write me an email at [email protected]

from rviz_satellite.

Hey Markus,

what the plugin currently does is fixing the (lat,lon) of the NavSatFixMsg to the frame robot_frame.

I think it should

• fix the (lat,lon) of the NavSatFixMsg to the frame of the NavSatFixMsg

and

1. either load the tiles only around the frame of the NavSatFixMsg and make the robot frame read only
2. or load the tiles around the frame robot frame, using (lat,lon) corrdinates that are calculated from the deviation of the robot frame to the NavSatFixMsg-frame via UTM

I don't know the validity range of the latlon2xy conversion used here:

• https://github.com/gareth-cross/rviz_satellite/blob/master/src/tileloader.cpp
• http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#X_and_Y

so I cannot say whether it's okay to use UTM, or how far the distance in between the robot frame and the NavSatFixMsg-frame might be. So maybe it's better to chose option 1.

Do you agree Markus and Gareth?

from rviz_satellite.

@m-naumann I rewrote parts of how the frames are being transformed, see the current implementation. Can you confirm that this issue still applies to the current version 1.2.0?

Furthermore, I don't really understand the motivation behind this issue. If it only concerns simulation, couldn't you just publish GPS coordinates inside your simulation?

from rviz_satellite.

Hi @schra

yes, the problem is still the same: you ignore the frame of the NavSatFix-Message and do not list it in the documentation link (current implementation).

There are four relevant frames: The robot's frame, Rviz's fixed frame, the ENU/ NED/ NWU world fixed frame, and the tile frame.

The interesting point is the robot frame: It has two purposes: 1. You don't want to load the tiles of the whole world and 2. You need to know one "base point" for the lat-lon to x-y conversion.

Technically, this can be two separate things: a NavSatFix for the "base point", and a robot_frame_id to load the tiles around. What you do is linking the manually defined robot_frame_id to the NavSatFix-lat-lon-Coordinates and ignoring the frame_id of that message.

What I proposed is

1. either load the tiles only around the frame of the NavSatFixMsg and make the robot_frame_id read only
2. or load the tiles around the frame robot_frame_id , using (lat,lon) corrdinates that are calculated from the deviation of the robot frame to the NavSatFixMsg-frame via UTM or any other projection; see for example lanelet2_projection

From the NavSatFixMsg + a projection method, the map_frame (which I would rather call rviz_satellite_map because there might be different valid map frames) is defined. The tile frame is a frame you don't even define (if I am correct), so I wouldn't mention it.

Furthermore, I don't really understand the motivation behind this issue. If it only concerns simulation, couldn't you just publish GPS coordinates inside your simulation?

The motivation is that currently, the NavSatFixMsg is misused. What I did for using it in simulation is exactly publishing a NavSatFixMsg, but if users changed the robot frame, the hoped that the tiles where loaded according to the position of the robot (Option 2 from above). But what actually happened was that the tiles were attached to the robot.

If not in simulation, you most likely have GPS with something around 1Hz, but some 100Hz Odometry. Currently, the tiles would follow the robot 99 times and at the 100th time, the tile jumps away under the robot.

I hope that this helps clarifying . Feel free to ask further questions.

from rviz_satellite.

I don't quite understand the problem you describe with the current setup. Whatever robot-fixed frame I set, I can't observe any glitches or jumps, even with setting the gps rate to 1 and tf-updates to 100. Can you provide a basic setup/video to reproduce what you mean? Its hard without anything visual. Despite that, are you really sure you're using the latest version? What fixed_frame, what camera frame are you using?

However, its seems indeed a flaw that the NavSatFixMsg's frame_id is ignored. That one should be used instead of the user-selected one. Or is there any specific reason to select this frame? So I vote for option 1:

either load the tiles only around the frame of the NavSatFixMsg and make the robot_frame_id read only

@m-naumann would you be willing to provide a PR for that?

from rviz_satellite.

I've created this PR #53. As far as I know the frame_id can safely be deduced from the frame_id in the header of the gps message. Please let me know if I misunderstood.

from rviz_satellite.

You are right, that's option 1. The only thing I would change is keep the robot frame property but make it read-only, such that one sees what frame is currently used.

from rviz_satellite.

I think that making robot frame a read-only property would also be fine. However, wouldn't having a robot frame property at all, may already be confusing? I think that it would be safe to expect that the frame_id of the Topic would be used, like for other common rviz plugins.

If there would be a selectable frame property, then I would expect it to be an option for world frame. Somehow the AerialMapDisplay needs to know which frame is aligned with geographic coordinates (ENU/NED/NWU). This is currently hard-coded to be map [1]. However, I think it's a good default value, since it conforms to REP-105 [2].

In addition, I also observe the tile jumping a little bit, probably because the frequencies of tf and the NavSatFix do not match. It happens with my fixed frame is set to the (ENU-aligned) map frame, subscribing to a gps/filtered topic containing the filtered location robot’s world frame position, transformed into GPS coordinates, which must be consistent with the map->robot tf's [3].

[1] https://github.com/gareth-cross/rviz_satellite/blob/master/src/aerialmap_display.cpp#L494
[2] https://www.ros.org/reps/rep-0105.html
[3] http://docs.ros.org/melodic/api/robot_localization/html/navsat_transform_node.html

from rviz_satellite.

I think that making robot frame a read-only property would also be fine. However, wouldn't having a robot frame property at all, may already be confusing? I think that it would be safe to expect that the frame_id of the Topic would be used, like for other common rviz plugins.

If there would be a selectable frame property, then I would expect it to be an option for world frame. Somehow the AerialMapDisplay needs to know which frame is aligned with geographic coordinates (ENU/NED/NWU). This is currently hard-coded to be map [1]. However, I think it's a good default value, since it conforms to REP-105 [2].

Sounds reasonable. I vote for using the frame_id of navsat for the robot frame (I agree, this is fair to assume and default everywhere) - and either replace "robot frame" with "map frame", or remove it completely and set "map" as default (as is).

In addition, I also observe the tile jumping a little bit, probably because the frequencies of tf and the NavSatFix do not match. It happens with my fixed frame is set to the (ENU-aligned) map frame, subscribing to a gps/filtered topic containing the filtered location robot’s world frame position, transformed into GPS coordinates, which must be consistent with the map->robot tf's [3].

@schra we also observed this, would you open an issue'?

from rviz_satellite.

If there would be a selectable frame property, then I would expect it to be an option for world frame. Somehow the AerialMapDisplay needs to know which frame is aligned with geographic coordinates (ENU/NED/NWU). This is currently hard-coded to be map [1]. However, I think it's a good default value, since it conforms to REP-105 [2].

Now I am a little confused: The purpose of the NavSatFixMsg is to provide exactly this information, or am I wrong? It states which frame('s origin 0,0,0) corresponds to which geographic(lat/lon/ele) coordinates. If there was one fixed transformation, such as "the UTM base frame is map", then why do you need a NavSatFixMsg, you can as well load tiles around a PoseStamped (by computing where this Pose is within the map frame and re-projecting these x/y/z coordinates into lat/lon/ele). Right?

In addition, I also observe the tile jumping a little bit, probably because the frequencies of tf and the NavSatFix do not match. It happens with my fixed frame is set to the (ENU-aligned) map frame, subscribing to a gps/filtered topic containing the filtered location robot’s world frame position, transformed into GPS coordinates, which must be consistent with the map->robot tf's [3].

That's why I rather prefer the above mentioned "option 2", where this fixed transformation is set by the NavSatFixMsg (which should not change), but in order to determine which tiles you load, you look at where the robot frame is with respect to the NavSatFixMsg-frame

from rviz_satellite.

Now I am a little confused: The purpose of the NavSatFixMsg is to provide exactly this information, or am I wrong? It states which frame('s origin 0,0,0) corresponds to which geographic(lat/lon/ele) coordinates. If there was one fixed transformation, such as "the UTM base frame is map", then why do you need a NavSatFixMsg, you can as well load tiles around a PoseStamped (by computing where this Pose is within the map frame and re-projecting these x/y/z coordinates into lat/lon/ele). Right?

The NavSatFix message does not provide orientation. If you would be able to configure the fixed frame to any frame (#54), then the visualization could have an incorrect orientation. Suppose that you would set your fixed frame to the frame of the NavSatFix (the robot) and your robot moves (rotates) around a corner, the visualization will not rotate accordingly, making it look like the robot moves sideways.

I think that using only the tf's, including utm and a selectable robot frame, and avoiding the use of the NavSatFix at all, would also avoid the jumping behaviour. Or is this also what you mean with the statement below?

That's why I rather prefer the above mentioned "option 2", where this fixed transformation is set by the NavSatFixMsg (which should not change), but in order to determine which tiles you load, you look at where the robot frame is with respect to the NavSatFixMsg-frame

from rviz_satellite.

@m-naumann You may want to take a look at this commit (tud-cor@a8d2e20) which requires a tf containing utm frame which is connected to your robot, downloads the tile according to the NavSatFix messsage, and allows any frame to be selected as the fixed frame.

This basically means that all that the NavSatFix does is defining which tile to use. Transforming the tile to the right position and orientation is done using tf.

from rviz_satellite.

@RonaldEnsing I implemented my suggestion starting from what you did. See the PR for details.

#55

from rviz_satellite.

I think that using only the tf's, including utm and a selectable robot frame, and avoiding the use of the NavSatFix at all, would also avoid the jumping behaviour. Or is this also what you mean with the statement below?

Why would that prevent the jumping?

from rviz_satellite.

I think that using only the tf's, including utm and a selectable robot frame, and avoiding the use of the NavSatFix at all, would also avoid the jumping behaviour. Or is this also what you mean with the statement below?

Why would that prevent the jumping?

Suppose that your NavSatFix sensor is rigidly attached to your robot, your fixed frame is set to map and you publish the map->robot using tf. The tile should now have a static position in rviz (until you drive into another tile number of course), and the robot moves. Every time a NavSatFix message is received, the tile is transformed and visualized. Both tf [1] and the NavSatFix message itself [2] is used to transform the tile. The tf did not yet have the time to update based on the latest NavSatFix message, while you do transform the tile based on the latest NavSatFix message and an older tf.

This [3] modified version of the AerialMapDisplay fixes that. And PR #55 is a continuation of that. I still need to take a closer look at PR #55.

[1] https://github.com/gareth-cross/rviz_satellite/blob/master/src/aerialmap_display.cpp#L518
[2] https://github.com/gareth-cross/rviz_satellite/blob/master/src/aerialmap_display.cpp#L547
[3] tud-cor@a8d2e20

from rviz_satellite.

What I proposed is

1. either load the tiles only around the frame of the NavSatFixMsg and make the robot_frame_id read only
2. or load the tiles around the frame robot_frame_id , using (lat,lon) corrdinates that are calculated from the deviation of the robot frame to the NavSatFixMsg-frame via UTM or any other projection; see for example lanelet2_projection

Just to summarize the current situation:

• #53 is implementing the first proposal. Additionally it also completely removes the robot_frame_id which I also prefer.
• #55 is implementing the second proposal.

If there would be a selectable frame property, then I would expect it to be an option for world frame.

According to http://www.ros.org/reps/rep-0105.html#map the map frame has to exist. Thus I don't see why we should make this frame configurable?

@schra we also observed this, would you open an issue?

I created #56

from rviz_satellite.

What I proposed is

1. either load the tiles only around the frame of the NavSatFixMsg and make the robot_frame_id read only
2. or load the tiles around the frame robot_frame_id , using (lat,lon) corrdinates that are calculated from the deviation of the robot frame to the NavSatFixMsg-frame via UTM or any other projection; see for example lanelet2_projection

Just to summarize the current situation:

* #53 is implementing the first proposal. Additionally it also completely removes the robot_frame_id which I also prefer.

* #55 is implementing the second proposal.

If there would be a selectable frame property, then I would expect it to be an option for world frame.

According to http://www.ros.org/reps/rep-0105.html#map the map frame has to exist. Thus I don't see why we should make this frame configurable?

@schra we also observed this, would you open an issue?

I created #56

That's true, however #55 also allows for the first option, by simply setting the robot frame to the NavSatFix frame.

from rviz_satellite.

If there would be a selectable frame property, then I would expect it to be an option for world frame.

According to http://www.ros.org/reps/rep-0105.html#map the map frame has to exist. Thus I don't see why we should make this frame configurable?

I agree. It does not have to be configurable. I could have emphasized the "If". I wanted to make clear that I do not expect a configurable robot frame if it has to be set to the frame_id of the NavSatFix message anyway. However, in #35, the robot frame is sometimes referred to as the frame to load the tiles around. See this #35 (comment) for more details:

The interesting point is the robot frame: It has two purposes: 1. You don't want to load the tiles of the whole world and 2. You need to know one "base point" for the lat-lon to x-y conversion."

PR #53 is much simpler because it keeps the current behavior of loading the tiles around the NavSatFix instead of a selectable frame. I think that PR #53 is quite safe to merge. PR #55 is basically a continuation of PR #53. It re-introduces the robot frame, but then with another meaning: The frame to download the tiles around.

from rviz_satellite.

If there would be a selectable frame property, then I would expect it to be an option for world frame.

IMHO the world frame cannot be configurable, because the NavSatFix defines it.

PR #53 is much simpler because it keeps the current behavior of loading the tiles around the NavSatFix instead of a selectable frame. I think that PR #53 is quite safe to merge. PR #55 is basically a continuation of PR #53. It re-introduces the robot frame, but then with another meaning: The frame to download the tiles around.

True, PR #53 keeps the current behavior regarding where to load the tiles.

But it also regards rviz' fixed frame as the frame where the ENU (or any other) convention is applied. Thus, it contraints the usage a lot, because you cannot set any moving frame as fixed frame (for example the frame of LIDAR scanner on a vehicle, because you want to speed up the pointcloud visualization). So it has strong assumtions regarding the fixed frame, which are fixed again in #55

from rviz_satellite.

IMHO the world frame cannot be configurable, because the NavSatFix defines it.

The NavSatFix gives the geographic coordinates of the receiver (the associated frame_id) [1]: "header.frame_id is the frame of reference reported by the satellite receiver, usually the location of the antenna. This is a Euclidean frame relative to the vehicle, not a reference ellipsoid." A map or world frame would be static w.r.t. geographic coordinates. I agree that we can expect users to follow REP 105 [2] regarding the naming convention of their tf frames so that it does not need to be configurable.

PR #53 is much simpler because it keeps the current behavior of loading the tiles around the NavSatFix instead of a selectable frame. I think that PR #53 is quite safe to merge. PR #55 is basically a continuation of PR #53. It re-introduces the robot frame, but then with another meaning: The frame to download the tiles around.

True, PR #53 keeps the current behavior regarding where to load the tiles.

But it also regards rviz' fixed frame as the frame where the ENU (or any other) convention is applied. Thus, it contraints the usage a lot, because you cannot set any moving frame as fixed frame (for example the frame of LIDAR scanner on a vehicle, because you want to speed up the pointcloud visualization). So it has strong assumtions regarding the fixed frame, which are fixed again in #55

I agree that this version has contraints. However, these constraints are not the result of PR #53, but these constraints were already there. I think it wouldn't be a bad idea to incrementally fix different issues.

[1] http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatFix.html
[2] https://www.ros.org/reps/rep-0105.html

from rviz_satellite.

I agree that this version has contraints. However, these constraints are not the result of PR #53, but these constraints were already there. I think it wouldn't be a bad idea to incrementally fix different issues.

So then, why not use #55 which extends #53 which extends the current version?

I just want to use the NavSatFix message + orientation convention to clearly and uniquely define the geo-coordinates to tf conversion/projection without any further specifications that confuse people.

What you propose is to use some parts of the NavSatFix and then also other frames, tf's, ... If you provide a NavSatFix with utm as base frame for example, that's a conflict. What do you do then?

from rviz_satellite.

@schra this is done, right? with which commit/PR?

from rviz_satellite.