Autoware Coordinate Systems

Ah, my mistake Ian. I look forward to hearing what you think is feasible.

That makes good sense to me.

@msmcconnell, After looking into it a bit closer, the gpsins_localizer will have to keep the dependence on the novatel msgs in the short term. The novatel_span_driver doesn’t use gps_common. The novatel_gps_driver does publish it but it’s missing almost all useful data. This could/should be improved in the driver, but at the moment it’s not useful.

In terms of covariance info, I agree with you, but currently autoware’s architecture is setup to use geometry_msgs/PoseStamped for estimated localizer pose and geometry_msgs/TwistStamped for localizer velocity. So adding covariance would need to be done with message type changes to all existing localizers and subscribers to localizers. Something I feel should be discussed and done later in a larger localization architecture MR (we were sort of working towards that in this thread before it stalled).

I think this is why I didn’t upstream this package in the first place, because I wasn’t sure how best to fit it into autoware’s existing localization architecture.
That being said, I think the gpsins_localizer package still has value as the only localizer in autoware that conforms to REP-105, allows people to use GPS data outside of Japan, and allows people to localize without the need of a lidar.
I’m hoping I’ll have time to do a more formal review of the localization situation in autoware and we can move it towards REP-105, but I can’t guarantee anything unfortunately.

@Ian_Colwell. Thanks for looking into it.

I’ll look into getting a more complete gps_common/GPSFix published from novatel_gps_driver, but it will probably be some time before I can get to it.

I think the consensus of this thread is that REP-105 is the way to go, but as you pointed out it is not clear how we move forward from here without a clearer picture of what the overall localization architecture in Autoware will look like. @gbiggs could you provide us any guidance to this end? Is it time for a Localization WG or is there already some motion in that direction?

This is likely to be done for Autoware.Auto instead. Join the Autoware WG meetings to follow up.

For now, discuss in the Autoware WG. I don’t want to split discussion too early. When the Autoware WG starts regularly running over time it will be worth considering splitting some discussion off to a separate WG.

Hi @Ian_Colwell, I’m working on refactoring the GPSFix generation in novatel_gps_driver in the PR at https://github.com/swri-robotics/novatel_gps_driver/pull/74 ; I pretty recently fixed a bug that was causing covariances to not be filled in properly, and that branch should also add horizontal/spherical error probabilities into the GPSFix and fill out all of the DoP fields. If you’re still working on this, could you take a look at that and let me know if there’s anything else you need that isn’t provided? Thanks!

@tfoote As suggested by @msmcconnell, If all the map tiles are aligned with respect to a single frame of reference like “map” frame, won’t it be easier to transform all at once rather than transforming each individually? Did I get you right?

I’m not familiar with the map tiles you’re specifically referring to, so I can’t speak to the efficiency of transforming them. That will likely be more of a function of memory layout than anything else. But in general I would recommend designing the system to never need to do a bulk transform of map tiles. That’s the point of keeping the different coordinate frames that then can be addressed so you don’t need to ever transform data except at time of use if it’s not already in the frame you’re operating on.

With map tiles, I refer to the submaps of the environment. You may relate this to dividing the map into submap.
What I meant was, the submaps when aligned to a common reference frame will require a common transform. Therefore we can transform the required data only, at a given point of time.
I think this will the same in case we have different coordinate frames for submaps also. But having a common frame of reference frame would be better since all the spatial operations would be uniform throughout the map. What do you think?

Please clarify to something concrete with specific semantic meaning. How to best transform things depends on their semantic meaning.

Yes, if data are in the same coordinate frame at the same time single transform can be applied to all of them.

I don’t agree with your statement that the ability to transform the data is limited to a single point in time.

When doing metric comparisons it is important to make sure to be computing these things in the same coordinate frame. However I don’t think that is is better to store everything in a common frame. This is actually counter productive. Data should be stored in the most appropriate semantically meaningful coordinate frame. Before being operated upon it can be transformed into the most appropriate coordinate frame for completing the operation.

Data with persistence should be stored in the semantically meaningful coordinate frame in which it expected to be unchanged for the duration of it’s persistence.