Notes about hexapod control software

Reference Documents

• CAN 616f001e. "Rotation of M2" Algorithm
• CAN 616a046d: ADS "M2 Hexapod Software Protocol"
• TURBO_SRM.pdf: Delta Tau UMAC Reference

---

Here follows further controls and security checks to prevent damages to the secondary mirror.

Introduction

During the tests in the Arcetri lab it became evident the need to add a number of security checks in the hexapod control software (which is part of the OSS). For this reason it was decided to implement a standalone version of the hexapod control software including all necessary safety controls and this is used in the solar tower lab instead of the ortiginal OSS version.

A few points must be taken into account:

1. All safety controls added to the Arcetri version of hexapod software are necessary also for the operation at the telescope, moreover there (at the telescope) space constraints are more strict than in the solar tower.
2. The safety controls which are needed are not only restrictions in the volume of hexapod motion, but in order to detect dangerous conditions essentially due to partial failures in the hardware, it is also necessary to verify the status of a number of data bits from the hexapood electronics. This is an area where documentation provided by ADS is heavily insufficient. (Note: Rick Demers has contacted Danielle at ADS about additional documentation about the hexapod)
3. We discovered the meaning of some of those data bits, but without documentation we are not confident that the final behaviour of the hexapod ontrol software is correct. E.g.: we observed once a funny behaviour: after a following error" on a leg and a subsequent "open brake" command, all the status flags where cleared (also those non related to brakes); and we do not know wether this is a feature or a bug.
4. Another area of uncertainity is related to the procedures needed to come out from failure conditions (as explained below in the note, we worked around this point by using brute force).
5. We can anyway use hexapod control software as developed here because, after the modification of some mechanics in the devices installed in the solar tower, software failures will not cause dangerous situations. This is not the case at he telescope where, as stated in point 1., constraints are stricter and moreover you need safe procedures to recover from errors.

Added safety controls

Here follows a list and brief discussion of the added controls and safety checks we have set up in Arcetri's code but, as stressed above it must not be considered as exaustive.

1. boundary control: we discard move commands if the final absolute position is outside of a cylinder parallel to the z axis centered in the origin of the hexapod's absolute reference system and having radius 5mm and height 10mm. otation around Z-axis is forced to 0, rotations around X-Y axes is limited to +/-900 arcsec.
2. commands that ask for a movement of the hexapod are discarded if the brakes are closed.
3. commands that ask for a movement of the hexapod are discarded if the hexapod is moving.
4. any command is discarded if the hexapod firmware has not been properly initialized.
5. any command is discarded if one or more legs signals the "amplifier fault" condition.
6. any command is discarded if one or more legs signals the "positive HW limit switch" condition.
7. any command is discarded if one or more legs signals the "negative HW limit switch" condition.
8. any command is discarded if one or more legs signals the "following error" condition.
9. any command is discarded if one or more legs signals the "open loop" condition.
10. we added two more functions: isinitialized() and ismoving() to test for the corresponding conditions.

NOTE 1: because of conditions 5-9 any error is unrecoverable and requires manual interaction with the low level UMAC control software. Our implementatrion of the hexapod control software does not include safe recovery procedures.

NOTE 2: The limits to hexapod movements specified in point 1. above, should be values defined in a configuration file, to allow adjustments during commissioning.

More about the hexapod

Boundary control

The following controls on absolute hexapod positions must be added:

1. Position: If [x, y, z] is the requested absolute position, and MAX_RADIUS is the limit cylinder radius and MAX_Z is one half of the cylinder heigth, then the following must be verified:

sqrt(x*x+y*y) < MAX_RADIUS and abs(z)<MAX_Z

2. Rotations: if a,b,c are the rotation angles around x,y,z axes, respectively, and MAX_ANGLE is the angular limit, then the following must be fulfilled:

abs(a)<MAX_ANGLE and abs(b)<MAX_ANGLE

The value of c is ignored, i.e.: always taken as 0 (zero)

Safety checks

As of today (jun 9th 2009) referring to OSS (svn version 6701) at a first look to the code a number of checks seems to be missing. e.g.:

• in moveAbs() apparently only enumStateUnknown, enumStateOff, enumStateStandby, are controlled before performing the movement, (no conditions on brakes or errors are checked)

• in openBrake() before opening the brake the error conditions should be tested in order to avoid errors to go unnoticed

The OSS seems to perform polling on the error bits and set flag accordingly, even though error control is based on this polling mechanism (this is not clear to me after the quick look to the code), race conditions may prevent the proper detection of errors and robustness of operation would suggest to esplicitly perform checks just before sending commands.