Decisions and documenting axes

During the development of !338 (merged) there was considerable debate about the axes direction.

Currently the code assumed that +z is the objective moving up (towards the sample). As such it starts stacks at the lowest z-position to avoid crashing.

It was noticed that on some hardware motors are reversed and +z was down away from the sample. !338 (merged) has a way that the position as reported by the motor board can differ from the position as used in the rest of the program. It also adds a a way to invert z in the UI.

Debate about the coordinate system.

Some key points from the undecided debate:

• Encouraging +z to move the objective towards the sample makes sense for the normal OFM configuration, but goes against conventions such as the DICOM definition: https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_c.8.12.2.html
• A suggestion of
  • +x moving the objective right from the camera FOV perspective (therefore the sample moves left in the webapp)
  • +y moving the objective up from the camera FOV perspective (therefore the sample moves down in the webapp)
  • This would mean that +z moving the objective towards the sample would create a left handed coordinate system. This could be problematic in the future.
• The direction of x and y can be detected by CSM calibration. The direction of z can be detected from a scan of a flat sample [Providing we know if the microscope is a standard one or an upright]

There is still some debate to be had on the coordinate system. And how it relates to different variations such as the upright and the delta stage.

A final decision should be made and probably documented in an OFEP