muffinspawn / fms Goto Github PK

When the LT becomes uninitialized, put the component into an "uninitialized" state to force the user to reinitialize.

Need to

1. Define the home position of the propeller.
2. Define the angle of the propeller.
3. Store the home and current propeller angle as Position component properties.

Figure out how the geodicists handle custom coordinate systems after they have located the tracker in the Fermilab coordinate system. Then implement this functionality in the client.

Instructs the Motion component to go home, and then calibrates to this positition using stand reflector measurements.

The tracker should have a mode where it scans the search area for a target.

Detect when the laser tracker needs to be reinitialized and do the following:

1. save state (i.e. current reflector position, etc...),
2. go to ref#1
3. init.cmd --> lasertracker
4. return to previous action (i.e. go to saved reflector position)

1. find and measure all reference targets using configured LTCS coordinates
2. match measured LTCS and configured DTCS coordinates
3. create parameter and value matrices
4. call Calculate Coordinate Transform VI and save
5. invert transform matrix and save
6. log location of the tracker, measured LTCS coordinates, and ???

Important items are how to locate, how the coordinate transforms are calculated, why only three coordinates are required, and communications sequence and event flow.

In order for the client to work in DS coordinates, the client must be able to translate to/from actual coordinates. Since the LT device we have does not support determination of the orientation parameters, we can either

1. Calculate the transform and inverse transform and completely manage the CS translations ourselves, or
2. Calculate the forward transform, obtain the orientation parameters from the matrix, and set the orientation on the device so it can manage CS translations.

Since it's a simple matter of inverting the transform matrix, I will implement option 1.

The LT API Initialize function should allow for setting the weatherMonitorStatus to ReadOnly. Also, functionality should be added to the API to

1. get weather data, and
2. set the refraction index before a measurement.

Furthermore, the LT component should be updated to have a property that indicates which algorithm to use to calculate the refraction index. If it is "Leica:, then weatherMonitorStatus will be set to ReadAndCalculateRefractions, otherwise it will be set to ReadOnly and the component will monitor the environment parameters and set the refraction index properly before each measurement.

Refer to issues #17 for details on manually calculating the refraction index.

Include raw, local, atmospheric readings, and refractive index.

At the moment the Position Client has a basic input for the absolute move distance and rotation angle. It would be better to fetch the HomeDistance and HomeAngle properties from Position after the home operation and have the input distance and angle to be relative to those values.

While I'm at it, a display of the current distance and angle (relative to the home values) would be nice as well.

When one of the synchronous AT4xx COM calls returns an error, it usually just contains a status code. Descriptions of these codes are listed in the TPI manual. Add functionality to the API to parse error messages and substitute the status code description for the raw code.

Implement the Emma event sequence that measures all of the propeller reflector positions.

Create a client that can be used to operate the laser tracker by interfacing with the laser tracker EMMA component.

1. Input: target with ID and nominal coordinates in the Detector Solenoid (DS) coordinate system.
2. Controls to start and stop/abort target acquisition
3. Display target search results in a table with the following information:

• search/target ID
• acquisition time
• settling time
• actual coordinates

4. Configurable settling tolerance
5. Configurable set of calibration targets with

• target ID/description
• nominal coordinates in DS coordinate system
• approximate actual coordinates in the LT's coordinate system

6. Controls for calibrating/setting up the DS coordinate system

• Find calibration targets
• Calculate Least Squares transform matrix
• Apply transform to future measurements

When listening for SystemStatusChange callbacks, the status ES_SSC_MeasStatus_NotReady will be sent if the tracker loses a lock. When it re-gains a lock it will send ES_SSC_MeasStatus_Ready. Set the status between "running" and "ready" on respective notifications.

Things left to do:

1. Define how we determine what the stand position is (i.e. w.r.t. the stand targets).
2. Create working list of stand targets to measure. (MOVE)
3. Get the total number of stand targets. (FIND_STAND_TARGET)
4. Calculate position error. (POST_MOVE)

In order to calculate the transformation between LT coordinate system (LTCS) and the local coordinate system (DSCS), approximate LTCS coordinates must be put in the appropriate section of the Property component INI file so that the Position component can search for the targets and measure them. This requires that someone shoot the targets of the reference network every time the LT device is moved.

To make this easier, we should make a simple LabVIEW VI that records the LTCS coordinates each time a target is locked-in. An INI file can then be generated, and the list can be edited either before (via table manipulation) or after (via direct file editing) creation. This file can then be used as needed to populate the Property component INI.

See comments in issue #20.

Specifiy a set of target with their approximate locations. Automatically measure them.

Instead of a home.nack when a find.nack is received, an error.dat is sent.

1. Send home.cmd to Motion
2. Measure the stand reflectors
3. Set the HomeDistance property to the average z coordinate of the stand reflectors
4. Measure the propeller reflectors
5. For now, set the HomeAngle property to the angle of the first principle component vector of all the propeller reflectors with respect to their centroid.

Add support for loading and saving the calibration target information from/to a configuration file.

Instead of using a CSV file to read reference target coordinates in the local coordinate system (DSCS), use use the Properties component to set LT Client component properties for these values. The standard cluster update scheme will have to be replaced by a dynamic generation of properties held in some sort of map structure.

The tracker is capable of two-face measurements for increased accuracy. These should be used when measuring the network, and so the option should be enabled when the target name begins with "ref#".

Make sure the LT component mini-doc is up-to-date. Make sure to add information on the intricacies of the EMMA calls such as data variants and constraints.

Take all the LT class functions that call the AT4xx COM API and make them into an independent API. The API functions should not be dependent on EMMA or anything else particular to the LT component.

Send position data to data.system via a position.dat event. This command has data consisting of a step ID in the form run#.sequence#.step#. This will be broadcast, needs to be consumed by Position, and attached to the above sent data.

To get the Position component working we need a Motion component that responds to commands. At this point it doesn't matter if the component doesn't actually drive anything.

Implement the Emma event sequence that measures all of the stand reflector positions

Although using the DLL provided with the AT4xx API does not seem to work with Python (IDispatch error), it should be possible to use SWIG to wrap the C++ classes provided, and then manage the network connection natively in Python.

Need a basic client to test out the component.

Create a test app for the LT API that doesn't use EMMA.

Position Client is complaining about variant-to-data conversion in MOVE_NACK after a failed LT find.cmd.

The optional starting of the EMMA dispatcher, mock laser tracker, and laser tracker component clutters the laser tracker client block diagram. Instead of trying to modularizing the application and risking over complicating it, simply create a companion application that starts and stops all of the dependencies for testing purposes.

Both the com component and client should log their activities for auditing purposes.

Based on this paper:
https://ojs.cvut.cz/ojs/index.php/gi/article/view/gi.14.2.2,
the refractive index of the tracker should be calculated manually and updated in a special way to keep it current.

From issue #46:

I have finished the implementation, but I am nervous. If the LT goes uninitialized in the middle of a step (move, find, measure, find, measure.... sequence), the component will have to be re-initialized manually/by the script because it cannot distinguish between find.ack from the re-init or one from a pending step find.

My inclination is to modify the behavior to

save the inputs to the step,
flush the inbound queue,
abort Motion,
abort Laser Tracker
re-init,
flush the inbound queue again, and
redo the step from the start using the saved inputs.
There's a pathological case whereby an exit or abort could be issued during re-init, so it should respond appropriately to these events.

Also, abort will have to be implemented in Motion and Laser Tracker if the default functionality is insufficient.

Add a property that turns on/off the automatic broadcasting of running/ready states.

At least initially we do not want any motion compensation, so we need to be able to turn it on/off (new property).

Additionally, we may want to manually apply a pre-compensation. Thus we need a way to configure motion compensation and modify the requested coordinates accordingly.

Finally, in order to study whether compensation is necessary and what values may be needed, the errors should be exposed in the client.