The Hexapod failures we experienced can be divided in two main slot:

1. Lost of current kinematic position
2. Not safe homing procedure

Case 1)

In this case the hexapod is in known position in his 3D space or it is moving toward a commanded position. If a "power off" command is sent to the Adaptive Secondary electronics (f.e.: electronic temperature out of range) the hexapod is switched off as side effect (the power line inside the cabinet is on the same remote switch). At the moment, the only recovery procedure is to call the "homing procedure" that is no safe.

Case 2)

The homing procedure performs the following steps:

1. extend the legs untill the HW limit switch are reached
2. the hexapod is positioned to Z axis mid range
3. the kinematics now is initialized and ready to be used

We experienced faults in the 1) and 2) steps.

Step 1)

We had a broken limit switch connector ("touch - not touch contacts"). We asked for a homing procedure to the UMAC firmware and the hexapod moved on side instead going down, because the limit switch activated. The recovery procedure was: measure leg len, simulate the kinematics with Matlab and find the correct movements to ask to each len, command "by hand" a movement for each legs untill a good safe position has been reached. After: substitute the damaged limit switch, verify the input signals, start the homing procedure.

Step 2)

The hexapod here is moving blindly toward the Z-axis mid range. If something happens to the shell (es: too much wind, one actuator fault ....) a closeBrake() command is sent to the hexapod. It stops reporting a following error on at least one leg. In this condition is no clear how to recover without recalling the unsafe homing procedure. Moreover the kinematics value are in this case almost zero and that can be mis-understood by the SW if you don't refer to the right UMAC flags.

-- MarcoXompero - 2009-08-10