Rotation start omega uses the wrong sign

[DominicOram]

When GDA gives a start angle for rotation e.g. 90 deg the rotation actually starts at -90 from GDA's perspective. This is likely because the co-ordinate system in GDA is inverse to that in EPICS e.g. 90 in GDA is -90 in EPICS.

Acceptance Criteria

• From GDA's perspective a rotation starting at +90 deg starts at +90 deg

[DominicOram]

Look at fixing this in dodal, if we fix it at this level we will need to account for it in the rotation scan.

[DominicOram]

If the user says start at 90 it should start at 90 in EPICS

[d-perl]

• we should throw this away and fix it properly in epics:

  • add an alias to allow GDA to keep looking at -omega
  • use the correct one in Hyperion

• we should just convert the start position GDA sends to hyperion so that hyperion can always stay in epics coordinates

we think XS

[rtuck99]

https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/42572

[DominicOram]

We just need to try the above on the beamline - we will do it this afternoon

[rtuck99]

Tested on the beamline with the following results:

Hyperion Collection - without omega_start flip in hyperion request
==================================================================

https://ispyb.diamond.ac.uk/dc/visit/cm37235-5/id/16081963 - ins_5_4_master.h5
GDA UI: 10 - 190
omega_start = 10
2024-12-05 11:06:10
motor from +10 to -170
master file:
/entry/data/omega +10 to +190
entry/sample/transformations/omega:
    Attribute: vector {3}
        Type:      native double
        Data:  -1, 0, 0


Hyperion Collections - with omega_start flip in hyperion request
================================================================

https://ispyb.diamond.ac.uk/dc/visit/cm37235-5/id/16060744 - ins_3_12_master.h5
GDA UI: 60 - 240
omega_start = -60 (GDA 60)
2024-12-04 15:31:13
motor from ~ -60 to -240
master file:
/entry/data/omega -60 to +120
entry/sample/transformations/omega:
   Attribute: vector {3}
        Type:      native double
        Data:  -1, 0, 0
 

https://ispyb.diamond.ac.uk/dc/visit/cm37235-5/id/16060771 - ins_3_13_master.h5
GDA UI: 30 - 210
omega_start = -30 (GDA 30)
2024-12-04 15:32:38
motor from -30 to -210
master file:
/entry/data/omega -30 to +150
entry/sample/transformations/omega:
    Attribute: vector {3}
        Type:      native double
        Data:  -1, 0, 0

GDA Collections
===============
https://ispyb.diamond.ac.uk/dc/visit/cm37235-5/id/16060960 - ins_3_16_master.h5
GDA UI: 60 - 240
omega_start = 60
2024-12-04 15:44:07
motor from -60 to -240
master file:
/entry/data/omega +60 to +240
entry/sample/transformations/omega:
    Attribute: vector {3}
        Type:      native double
        Data:  -1, 0, 0

https://ispyb.diamond.ac.uk/dc/visit/cm37235-5/id/16061026 - ins_3_17_master.h5
GDA UI: 30 - 210
omega_start = 30
2024-12-04 15:46:02
motor from -30 to -210
master file:
/entry/data/omega +30 to +210
entry/sample/transformations/omega:
    Attribute: vector {3}
        Type:      native double
        Data:  -1, 0, 0

What was stored in ISPyB:
MariaDB [ispyb]> select axisStart, axisEnd, axisRange, imagePrefix, dataCollectionNumber, omegaStart from DataCollection where dataCollectionId in (16060744,16060771,16060960,16061026,16081963);
+-----------+---------+-----------+-------------+----------------------+------------+
| axisStart | axisEnd | axisRange | imagePrefix | dataCollectionNumber | omegaStart |
+-----------+---------+-----------+-------------+----------------------+------------+
|       -60 |     120 |       0.1 | ins_3       |                   12 |        -60 |
|       -30 |     150 |       0.1 | ins_3       |                   13 |        -30 |
|        60 |     0.1 |       0.1 | ins_3       |                   16 |         60 |
|        30 |     0.1 |       0.1 | ins_3       |                   17 |         30 |
|        10 |     190 |       0.1 | ins_5       |                    4 |         10 |
+-----------+---------+-----------+-------------+----------------------+------------+
5 rows in set (0.001 sec)

Note that GDA doesn't properly populate axisEnd

Conclusion: Flipping the omega_start isn't sufficient as although it then reproduces the motor movements of GDA exactly, the start and end positions in the nexus file and in ispyb are then both incorrect with the start omega being in the opposite sense to the rotation, therefore as well as flipping the start omega in the request we also need to make sure that it is not flipped it in the output to the database.
But it will make more sense to not do the flip in the request, but to actually do the flip in the motor outputs inputs seeing as at the very least we already have one flip for the increment but not for the absolute positions, that way we will have all the axis conversions in the same place.

[rtuck99]

From https://diamondlightsource.slack.com/archives/GJPB00679/p1734350618830859

I guess my question about omega is this:
Given that from my testing a couple of weeks ago, GDA does this:

https://ispyb.diamond.ac.uk/dc/visit/cm37235-5/id/16061026 - ins_3_17_master.h5
GDA UI: 30 - 210
omega_start = 30
2024-12-04 15:46:02
motor from -30 to -210
master file:
/entry/data/omega +30 to +210
entry/sample/transformations/omega:
    Attribute: vector {3}
        Type:      native double
        Data:  -1, 0, 0

i.e. in the UI, requesting omega from 30 to 210 degrees, gets you motor movements from -30 to -210, nexus data from +30 to +210 but a nexus omega axis of -1, 0, 0, why couldn't you just:
move the motor from +30 to +210, and set the nexus omega axis to +1, 0, 0 with the data in nexus still going from +30 to +210?
The only difference would be the rotation in physical space. But the semantics of the data in the nexus file would all still be correct according to the standard, as far as my understanding. Or is the physical rotation actually important?

Following conversation with Neil, I think part of the concern is that there may be downstream applications that don't respect the nexus transformation property. Although why they would assume negative orientation is unclear. Safest therefore is to follow GDA as closely as possible, despite additional complexity.