As @haditab pointed out in this MRs, common#20, utilities#27 and core_perception#26, “For GNSS localization, Autoware currently parses the /nmea_sentence, extracts the latitude and longitude and converts them to coordinates in the Japanese rectangular coordinate system”.
Rather than a quick fix to the issue, that will need to be addressed in the near future, having a community-agreed solution would future-proof the implementation.
It looks like this matter falls in-between the Maps and Simulation WG as maps would need to be placed somewhere within the globe and the simulator would produce vehicle coordinates. @Brian_Holt, @Masaya_KATAOKA thoughts?
My initial reaction is that we should do whatever ROS does, i.e. follow REP105 as suggested within the proposed localisation architecture for Autoware.Auto by @cho3. At this point, I’m wondering if we should be actively seeking to make this change to Autoware.AI given that our general focus is shifting to Autoware.Auto? Perhaps @gbiggs or @esteve can comment?
I’m also wondering the same, is it worth it to make large architectural changes (new localization system for example) to autoware.ai if autoware.auto is the future?
Autoware.ai is basically the “proving grounds” for functionality that will eventually go into Autoware.Auto. Auto has very strict guidelines and requirements. Ai is not so strict and allows for “faster innovation” than Auto. While I agree that it is important to work on Auto first and foremost, Ai still has it’s place for the time being. Plus, since Autoware.ai already has an active user base and Autoware.auto does not due to a lack of included functionality (so far), Autoware.ai provides a real-time feedback mechanism from the community that Auto can not (yet).
thank you all for your replies, it seems I did not make the point of the post clear enough, apologies.
What I was referring to is the actual functionality of the GNSS localizer, which at the moment is converting global coordinates to those relative to the Japanese rectangular coordinate system. I would expect Autoware users somewhere else in the world to have developed their own workarounds for the localizer to output coordinates relative to a coordinate system local to their location.
Although many may see making such a change in Autoware.AI a waste of time, as the AWF intends for it to go away eventually, I do see value in making this change in .AI as a prototype to understand the implications and decide what Autoware.Auto should do.
@sgermanserrano Do you mean that a single node for GNSS is outputting Japanese coordinates? If so, I think it would make the most sense to split the GNSS localiser out from any coordinate conversion. Have it produce global coordinates and let a separate node, which can be replaced or dropped as required, handle conversions to local coordinate systems.
MGRS 100km grid coordinates (think of it as UTM divided into smaller grids)
pros: Works similarly to current system. User do not have to keep track of their origin.
cons: value jumps at the edge of grid
ENU (east-north-up) coordinate with user defined lat/lon origin
pros: intuitive
cons: user has to keep the record of the origin used for every experiment to reproduce the same result
Do you mean that a single node for GNSS is outputting Japanese coordinates?
Only gnss(nmea2tfpose) is explicitly asking for georeferenced coordinate, but Autoware is implicitly expecting pointcloud and vector map to be created on georeferenced coordinate.
Currently, all pointcloud map, vector map, and gnss_pose have to be in the same Cartesian coordinate(“map” frame) in order to have localization and planning to work correctly. Technically, this coordinate can be anything, as long as they share the same origin. It can be Japanese coordinate, UTM, or random local coordinate.
Pointcloud map and vector map are already in Cartesian coordinate to begin with so it is up to the map builder to choose which coordinate use. However, gnss driver outputs are nmea_sentence(lat/lon value) so it must be converted into Cartesian frame. Current autoware.ai only has a node to convert lat/lon into Japanese Rectangular coordinate system, which means pointcloud and vector map should also be created in Japanese Rectangular coordinate system in order to use GNSS for localization. Hence autoware.ai only “supports” Japanese Rectangular coordinate system.
I would suggest following REP 105 as Brian originally suggested. This would mean that each map would be referenced to the “earth” frame which is an ECEF frame. Lat/lon to ECEF and vice versa can be done using straightforward closed form solutions and allows you to easily map all data into a Cartesian coordinate system. A common pattern then would be for each HD map to come encoded with the 3D transform to its axis from the ECEF frame. Then Autoware can continue to function in map only coordinates but any geodesic data (lat/lon) that is processed at runtime (such as a GPS fix) could first be converted to ECEF then easily transformed into the map by looking up the transformation on the TF Tree.
My team has already created one implementation of this which works with a tweaked Autoware 1.11 and is publicly available, though it might need to be updated to match Autoware’s design requirements.
@gbiggs Thanks for the encouragement. Before putting up an MR I would like some clarity on what aspect of this is needed first. I could provide the math for doing ECEF <-> lat/lon conversions or would you like a node for converting gps data into the map frame?
I created a “gpsins_localizer” node a while ago to operate autoware without lidar localization and conform to REP-105. It works great, but we were only able to use it for waypoint following since our existing vector maps were not geo-referenced.
The gpsins_localizer has 2 operation modes:
Normal: Conforms to REP-105 (ECEF earth frame), could possibly work with vector maps but not tested.
MGRS mode: This mode was added since the old lanelet2->vectormap converter would use MGRS origins to convert the map. In this mode, you can use vectormaps that have MGRS origins.
You can find the node here:
Do you think I should create an MR into upstream autoware?
If not, please correct me.
In terms of functionality, this is very similar to what my team has and is just as good a starting point, but there are a couple points we should consider.
There is a dependence on the novatel_gps_msgs/Inspva message which is a hardware specific message set. I would suggest using an alternative message like gps_common/GPSFix instead. I believe this provides mostly the same information though the velocity is reduced to a single speed value.
There is no co-variance information. While co-variance information is not required to implement REP 105 it will certainly be needed by any future localization architectures which use GPS/INS information. The co-variance of the INSPVA message is available from the INSPVAX message. I believe if we required maps to have an ENU orientation the co-variance could be transferred linearly using a basic translation. At that point we would want to constrain maps to say 10km squares to avoid build up of excessive error due to earths curvature. Fortunately, following REP 105 allows us to more easily tile maps in this way as the only change is the transform from earth->map.
Let me know your thoughts on this and how we might best continue to move forward.
I would recommend considering having named map frames for each tile that you may be active in and having a static transform setup for the ECEF origin of each tile. With some testing it may be feasible to simply publish all potentially required coordinates statically. Then the vehicle will simply pick the appropriate named map coordinate system to operate in and set that to be it’s parent frame for localization and odometry.
That merge was only an MR into our AStuff fork, not into upstream autoware.ai
I wasn’t aware of gps_common, I thought the only standardized message types were NavSatFix. Thanks for the tip, I’ll see if I can use gps_common in that node instead of the Novatel message.
And I agree about the lack of co-variance info, I’ll see what I can add easily.
Yes, you should be able to reparent it at any time. So whenever you travel between regions your localization can reparent at the transition. The localization will have a jump discontinuity but the odometry should local content should not jump. And content in the old map frame are actually still valid and can be operated upon, though they will be subject to the reprojection errors of the flat grid assumptions. But if all the relevant tiles’ coordinates are published as frames points observed in other tiles past or future can be operated on too. (Maybe historical readings, or observations from other concurrently active vehicles.)
