[TASK] Landmark Server V3

[EirikKolas]

Description of task

New features for the landmark server. I feel like this should be moved to its own repository after these changes

Suggested Workflow

• [ ] Represent the static and dynamic landmarks in two separate occupancy grids and make them available through the GetPlan service.
• [ ] Make a system for loading landmasked tiles to the map. Either make a separate node for this, or maybe use the LoadMap and SetMap. Having the landmasking be done in a separate node could be a good idea if we want to e.g. extend it to use map data in the future.
• [ ] Providing the map as a Polygon could be useful for the landmasking of the lidar data.
• [ ] Make the landmarkserver show the landmasked tiles in the occupancy grid.

[jorgenfj]

Current plan

Map manager (service procider) -stores origin of map lat lon to send to seapath to get map to odom static tf (service provider) -stores land mask polygon points, can transform lat-long to x-y (map frame) before sending to pcl_detector (service provider) -Creates map(occupancy grid) from land mask points (fill out or just polygon lines?) and sends to landmark_server (service provider) Seapath -Request origin of map lat-lon from map provider (service request) -Origin set by seapath is origin of odom frame, wait until ok data to set? -When origin of odom is set by seapath publish static tf from map to odom. -Rename "world" frame used in seapath to odom, to now publish odom to seapath tf -Map is now effective "world" frame where land mask and landmarks are stored/tracked. LandMark server

• Service request to get map (occupancy_grid) from map manager Send request on startup (blocking request) or in first landmark callback?
• Use map when inserting new static landmarks
• Store dynamic landmarks in seperate map, with or without land mask? Pcl_detector -Service request to get land polygon. On startup or in first callback? -For each callback first apply land mask then run normal wall and cluster detection -Prev wall transformation can use seapath data for transform or lidar imu data. Imu data appears to be of a higher frequency. Orientation changes will reflect lines inliers more the positional changes. However combining them is prob the best if seapath data is accurate and frequent, this also makes lidar imu redundant.

1. Suggest moving seapath driver and landmark server over to xavier beacause they are interconnected.
2. Map origin can be handled with service providere and request or be using joint launch files with origin as param for multiple nodes.

[EirikKolas]

Looks good to me! Don't need to store land mask in the dynamic map. We don't consider the lidar imu. If we want a separate IMU, we should get a dedicated one for this purpose. I like the idea of the map manager. The landmark should then be able to handle multiple maps imo, e.g. one for the manual mask and one for the land mask from map data, either sent to it as a polygon, or as a grid map.

The one thing I don't like is how the seapath is now dependent on the map manager. I think it is best if the seapath stores the map origin as well and provides the transformation between world frame and lat lon