Proposed changes to LTP

[Jailander]

Hi Linda has been running the long term patroller since Friday, we have seen some issues than can be improved by adding the following changes to the SMACH:

Upon start:

Check if she is charged and if not, go to the last waypoint and search for the charger. (Now she just searches for the charger, which might be outside of the detection radius.)

If she is charged, check if she is on the charging station and if yes, start with undocking instead of the move_base command. (Now she simply assumes that she is outside the charging station and starts with move_base, which is incapable of moving her out of the charger).

During operation:

1) Linda got stuck a few times when she got in a place which was impossible to leave without going backwards. Maybe that might be solved with a special recovery behaviour.

2) Some of the ROS nodes might get too slow or even stuck over time. There should be some self diagnostics that monitors and restarts the faulty modules if needed.

The question is if somebody else has been working on this or has any comments about it. @gestom has created a bash script that we have been using for patrolling supports these behaviours, so we know they work fine.

[bfalacerda]

The start up enhancements make sense, I can add them soon.

The navigation problems have also been reported and slightly discussed on issue #70, @AlexanderHermans, did you guys add something new?

Regarding the monitor do you know which nodes are more problematic?

Doing the self-diagnosis from SMACH would be a bit messy I think. Given that @gestom already has something, maybe we could run it in parallel with the state machine. When the script decides to restart a node, you can try to use the state machine pause service

rosservice call /pause_resume_patroller

to avoid having components trying to use nodes that are being restarted

[Jailander]

Thanks Bruno, we will add rosservice call /pause_resume_patroller to the script and tell you how it works.

[Jailander]

Hi, one last suggestion that is not urgent, maybe the parameters in the PatrollerTresholds.cfg file could be loaded directly from the strands_datacentre using the config manager. what do you think?

[bfalacerda]

I'm not sure I understand your suggestion. You want to have default values for the thresholds in the datacentre? The .cfg file is needed, so we can dynamically reconfigure these parameters on run-time

[Jailander]

Hi it was because we agreed that one of the purposes of the datacentre is to store all the parameters for the robot, so we don't have to look at individual files for setting different parameters, the config manager script loads all parameters on the ROS param server and then you can use them from there.

[bfalacerda]

We can store the default values in the datacentre, I can take a look at that also. However the cfg file is needed for the dynamic reconfiguration, so it should stay as it is. You are not supposed to edit it, you should use

rosrun rqt_reconfigure rqt_reconfigure

if you want to change the values of the parameters during a run. This is especially useful for debugging, because we can force the robot to go to the charging station whenever we want.

[Jailander]

Yes, I am sorry you are completely right, in this case is not easy, I will take a look into it to see if I can think of something for making it work.