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 notifications@github.com
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?