Map management

[jkaflik]

Goal: Serve a navigation occupancy grid for a static costmap with management capabilities

Requirements:

• [ ] load a map in an easy & well-known format. Consider GeoJSON as a default one

• [ ] save a map

• [ ] expose ROS services to manage the map

  • list areas (optionally filter by area type)
  • get area
  • update area
  • remove area
  • create area
  • get docking station(s)
  • update docking station(s)

• [ ] map visualization using Foxglove specific data types

• the map

  • multiple areas defined with polygon
  • id, name
  • area of type: obstacle, navigation, lawn
  • docking station(s) defined as a two-point line with orientation towards robot's face

[2m]

Good stuff! I am OpenMower user and am closely following progress here. Really great effort! :)

Consider GeoJSON as a default one

Really great to depend on widely used formats. This way maps can be visualized quite easily with a variety of already existing tools (Grafana, GitHub, etc.). Can we use different coordinates than lat/lon in GeoJSON? I assume map is still going to be defined as local coordinates in meters as offsets from some given datum.

multiple areas defined with polygon (obstacle, navigation, lawn)

Would it make sense to have obstacle and lawn areas decoupled? Right now in OM you need to follow a specific sequence of actions for the obstacle areas be recorded properly when recording a new area. Also when reorganizing mowing areas, obstacle areas also need to be rerecorded, but these usually do not change. Separating the two would make recording area process easier to manage (but it might complicate path planning?).

[jkaflik]

Can we use different coordinates than lat/lon in GeoJSON? I assume map is still going to be defined as local coordinates in meters as offsets from some given datum.

GeoJSON will use lat/lon. Those will get translated inside the node logic using robot_localization services. There is no need to bother the user with its internal coordinates. Thinking from the UX perspective, it's just much better.

Would it make sense to have obstacle and lawn areas decoupled?

I already did that in my implementation. It makes overall management simplified.

[jkaflik]

@2m BTW please see this: https://discord.com/channels/958476543846412329/1151460116420362271/1161604512621019187

I created this issue today, but already have done some significant progress in this area in last weeks.

[jkaflik]

@2m

but it might complicate path planning?

It does not make any difference, except the fact you have to find any bounding excluded areas before. It's an easy task.