cliff safety

[mzillich]

Hi there,

@nilsbore @hawesie @marc-hanheide

We need to ensure cliff safety somehow. A hardware solution using a cliff sensor, as currently investigated by Christian Reuther, will be the best solution, but will take some time to be realised. Until then we need an Asus based solution.

The current solution with negative obstacles in the cost map is a good high level solution, but suffers from two problems:
a) it does not see actual cliffs, only stairs. If there are no negative obstacles below floor level, it will not help
b) if parts of the nav stack go crazy, cost maps are ignored, or whatever, the robot could still go down.

I think a pretty safe approach could look like this:

1. a component floor_observer continuously monitors the space in front of the robot
2. floor_observer continuously sends an OK to ScitosDrive.cpp
3. as soon as some portion of the ground plane (e.g. a 2 x 2 cm hole) in front of the robot is NOT filled by points, it stops sending the OK
4. when not receiving an OK every x milliseconds, ScitosDrive will issue an emergency stop

This will also work if the Asus fails (e.g. cable breaks) or is misaligned, or if the floor_observer crashes, etc.
The only way this could fail is if the Asus is tilted and a "fake" floor is visible in the Asus, e.g. a wall at just the right angle to look like floor. This however is very unlikely.

So we will in the end have 3 redundant levels:
3. Nils' cost map solution, will steer the robot away from cliffs within normal navigation behaviour
2. the floor_observer, will issue an emergency stop if for some reason the robot did come too close to a cliff

1. the hardware cliff sensor, will do the same as 2. but in hardware, directly wired to the motor driver

One more loophole: what if ScitosDrive crashes?
Christian Reuther said we can implement a watchdog scheme between SCITOS and ScitosDrive. As soon as SCITOS does not hear from ScitosDrive for x milliseconds, it will issue an emergency stop.
And SCITOS itself is the most stable thing on the robot. So we can rely on that.

What do you think? I could implement the floor_observer.
Do you see any other way the 3 level solution could fail?

cheers
Michael

[mzillich]

@creuther to also have you in the conversation

[creuther]

As I have already discussed with @mzillich, to have this as stable as possible we need to separate the MIRA framework instance from the scitos_node thread. Right now the MIRA framework is instantiated by the scitos_node and is hence a child process.
It shouldn't be a problem having the MIRA framework running separately and then connecting to the instance using the regular MIRA networking / connectivity functionality. Then this will actually call the emergency stop if ScitosDrive crashes.
@cburbridge were there any issues having ROS node and MIRA framework in separate processes? Shouldn't be but I vaguely remember some library mismatches, but I think that was in the MIRA visualization due to ROS using a newer OpenCV version.

[nilsbore]

Sounds good! The only potential problem that I see is to decide if there are too few depth observations (a real cliff sensor). There are often missing observations in the depth sensors, due to shiny surfaces, sunshine or glass. So we will probably have to make some kind of trade-off between stopping too often and having a safe system. I think we'll be able to strike a balance there though.

[cburbridge]

@creuther I am a bit late in reply, sorry. There was an issue in that the
MIRA binary supplied was compiled with
libogre different to that of rviz. I fixed the problem by compiling MIRA
from source with the same version and using that for the strands package.

Running MIRA in a complete separate process is nice. We did not do this at
the start as it seemed best to keep the overhead as low as possible, but if
you think this is no problem then great.

On 12 February 2015 at 20:39, Christian Reuther [email protected]
wrote:

As I have already discussed with @mzillich https://github.com/mzillich,
to have this as stable as possible we need to separate the MIRA framework
instance from the scitos_node thread. Right now the MIRA framework is
instantiated by the scitos_node and is hence a child process.
It shouldn't be a problem having the MIRA framework running separately and
then connecting to the instance using the regular MIRA networking /
connectivity functionality. Then this will actually call the emergency stop
if ScitosDrive crashes.
@cburbridge https://github.com/cburbridge were there any issues having
ROS node and MIRA framework in separate processes? Shouldn't be but I
vaguely remember some library mismatches, but I think that was in the MIRA
visualization due to ROS using a newer OpenCV version.

—
Reply to this email directly or view it on GitHub
#98 (comment)
.

[creuther]

An update on this as discussed with my boss and @mzillich:
MLAB will construct two 3D printed brackets that integrate with the screw holes already existing in the front shell of the robot. They will allow mounting two TeraRanger One sensors to watch the floor at a distance of about 150% of the emergency break distance. As long as no direct hardware controller for this exists, the sensors will be monitored by a MIRA module running in the dedicated MIRA framework mentioned above. A MIRA driver for this sensor already exists.

These mounting brackets will be sent to UoB together with suitable screws to mount them. If on stock, two TeraRangers will also be sent for testing purposes. A UoB requisitioning request for this sensor is still pending but it seems to be quite a pain according to Claire. Will keep you all updated on the progress and developments of this solution.

[marc-hanheide]

Have we got an ETA for this, @creuther ? I'm asking because I'd like this to be ready for the pre-deployment at AAF, i.e. 11/03/2015

[creuther]

I hope to get it ASAP for development and evaluation here in BHAM, but I have yet to hear back from my colleague. I will try to get you an ETA soon; also good to have a deadline for when it should be ready.
The implementation and integration shouldn't be too complicated, so I think it's only a matter of designing, printing and shipping those mounting brackets and the sensors, as well as creating a suitable cable for the electrical integration.

[denisehe]

@mzillich - hey: when is it possible for you to come over to our site so that we can check the magnetic strip?

[Jailander]

@denisehe yesterday @cdondrup and me installed the magnetic strip in the stairs in our lab I asked people from the lab if they had noticed it or it made them trip or feel insecure none of them had noticed it whilst walking on it just noticed it because they saw it. however they are all young mostly fit people so not sure how well it relates to AAF, but it might be useful for you to know.

[denisehe]

hey thanks for the pictures and the information - the thing is that most elderlies do not lift their feet properly when walking but rather drag them along.

but if we could get such a strip we could see how it fits in our environment etc. :-)

[cdondrup]

This is why I thought that we could put them where there is mainly staff, e.g. where Werner killed himself last year. Most of the other stairs seem to have large barriers any way.

[denisehe]

hey - we got the magnetic strip today and put it out for testing - so far no coincidences!

how far away from the edge of the strairs do we need to stick the strip?

[mzillich]

I think 1 m or so. @creuther what is the braking distance?

[denisehe]

ufff thats far, the shorter the needed distance the better I can argue with staff responsible for security issues

[Jailander]

Hi, we put ours at 40 cm, however when Linda was stopping around because of some magnets on the floor the braking distance was very short, but I would definitely not put it less than 30 cm away from the stairs, as it may also go backwards towards the stairs (now that I've said it).

think about it this way @denisehe the furthest away from the stair the less dangerous it is as people have more reaction time.

[denisehe]

hm okay. well sure - but the thing is if we stick it half a meeter away the magnetic strip is in den middle of the corridor - and than not a single strip is sufficient as we then have to conect the strip back with the staircase on the left and right side.

the staircases that are situated in Henry's driving area are actually emergency stairways => they are not regularly used (exept by the robot ;-) )

thus a shorter distance might is okay.

could henry be adjusted with a second magnet-sensor on his back (for quicker reaction if he really drives backwards towards the staircase)?

[denisehe]

Positive News!!!! :-D

We can use the magnetic strips!

Best thing would be to stick them as close to the stairways as possible! Could you therefore test with what minimum distance safety is still guarateed?

Cheers Denise

[mzillich]

Excellent! you saved me a bunch of grey hair |-)

[denisehe]

hey, how can I get the picturs of the sensor up here?

[cdondrup]

Drag and drop into the text field.

[denisehe]

that, I like :-)

[denisehe]

[marc-hanheide]

guys, we really need progress on this for the AAF pre-deployment, @mzillich @ToMadoRe !