night time exploration

[marc-hanheide]

So, we can do some night time exploration (and also at public holidays), but only in some part of the environment. I suggest to implement this in the following way:

• We implement a specific action (like logging_server_start), called configure_day and configure_night, the return immediately with success, but they trigger a change in the topo map meta data (see below)
• we tag nodes in the topo map as "info_point_day" and "info_point_night" (or similar, whatever they were labelled as so far, here I assume the label was "info_point", but I know it was something else and @Jailander will know what it was). Then, upon execution of the configure_day action all nodes that are labelled "info_point_day" will also be labelled "info_point", so that info-terminal considers them. All nodes that are not "info_point_day" will have their "info_point" meta tag removed. Same for night.
• This means, the info_terminal explorer (@gestom) needs to check the node set and not assume it remains static (Problem: How long into the future do we schedule?)

Better Alternative?:

• we make rosparam changes in the google calendar, e.g. we introduce the tag that info_terminal is looking for a rosparam, and the google calendar interfaces changes that rosparam. More generally, we could implement a rosparam special action, that takes some YAML input on the calendar frontend, allowing any rosparam to be changed from there.

[marc-hanheide]

I am looking for input/thoughts from @cdondrup @Jailander @gestom and a plan who's doing what?

[gestom]

Hi, the scheduling is performed on a daily basis at midnights, so I could simply read a rosparam that will tell me the start and end time for exploration of the next day ?

[marc-hanheide]

Well, the problem is we need to restrict where it goes. Somehow, nodes need to be marked, don't they?

[gestom]

Ahh, yes. But if some parts of the environment are inaccessible, then it means that not only the info-terminal should not schedule them, but also the navigation should not pass through these. This basically means that each node should point to a specific schedule, which specifies its inaccessibility, which is actually independent of the task performed.

[marc-hanheide]

Is map switching easily possible?

[Jailander]

yes, its only calling a service

[marc-hanheide]

So, if we were to implement two specific switch actions we could schedule this, even making sure the robot is in the valid place and not moving, before switching?

[Jailander]

the map could still have a route out of the forbidden area but not into it so you really don't need to make sure the robot is in a valid place. However not sure how strands Executive can manage this, we would need @bfalacerda opinion.

[marc-hanheide]

Well. we don't need it. If we implement it as an action the robot is stationary. So no need to "hot-swapped", but of course the policy needs updating, too. So, please get @bfalacerda involved in this and see if it's possible and try ;-)

[Jailander]

Ok, to summarise for @bfalacerda we need some parts of the care house banned from the navigation at night, the idea is to switch topological maps when the prohibition starts leaving no edges into the forbidden areas just out of it.
So Bruno can you tell us two things:

• Can the MDP handle a topological map change?
• How does it deal with unreachable nodes?

[marc-hanheide]

If it's easier, we also delete all the nodes there, right? We don't need them.

[Jailander]

well to go out of there only, but if you make sure you leave before then you don't need them

[bfalacerda]

there are some extra services on the MDP side that would allow you to do that:

https://github.com/strands-project/strands_executive/blob/hydro-release/strands_executive_msgs/srv/AddDeleteSpecialWaypoint.srv allows you to add and delete "forbidden" waypoints. The policy generation will be guaranteed to not plan through them after this is done.

Then you can use https://github.com/strands-project/strands_executive/blob/hydro-release/strands_executive_msgs/action/ExecutePolicy.action , with the LEAVE_FORBIDDEN_AREA argument to take the robot out of the forbidden area (in case he is)

Then, during execution he will never plan routes through forbidden wps, but if he ends up there, execution will abort (and you would have to tell him to leave the forbidden area again)

Would this work for you?

This would just require some routine to add the forbidden waypoints at night time, and remove them at day time.

I just tested and everything works fine, excep atm he doesnt stop when he gets to a forbidden waypoint - that's just an extra if though, I can do it now

[Jailander]

hmm ok, this is another way to do it, @marc-hanheide and @gestom what do you think?

[bfalacerda]

strands-project/strands_executive#221 makes the robot stop in case he reaches a forbidden waypoint

[marc-hanheide]

sounds good to me... Then we would have to write an action that calls that service. As I said, I think, the leave part is secondary if at all. So, maybe just a config yaml file with forbidden waypoints which is used to call the service on thos nodes?

[bfalacerda]

If you send a goal to the mdp server that tells it to visit a waypoint (the default thing that we always do), it'll turn that into "avoid all forbidden waypoints until you reach the target". If he starts on a forbidden waypoint, the spec is broken immediately, and he won't move.

So, with this implementation you do need to explicitly tell the robot leave the forbidden area by sending a goal to the mdp server with the task_type argument set to LEAVE_FORBIDDEN_AREA.

[cdondrup]

To create the list of forbidden waypoints you can just use: https://github.com/strands-project/aaf_deployment/blob/indigo-devel/aaf_logging/config/white_list_aaf.yaml or get all the nodes with the tag recording_white_list. Then get the list off all nodes and remove the ones in the white list. Therefore the robot would only patrol where we are also allowed to film. I guess that would be the correct area already.

[marc-hanheide]

Maybe @TobKoer can comment and describe the exact area we are allowed to visit at night/holidays? @Jailander could you upload a screenshot of the topomap here so we can see all the nodes?

[Jailander]

Hi, the forbidden area is in the red square so the nodes on the whitelist are all other nodes, is that right @TobKoer ?

[TobKoer]

@ Jailander, @marc-hanheide
Hi, thus looks correct. At night and holidays/weekends use the Y1 area which was the lobby and the 'administration wing'.