Incorrect Lickspout Position

[arjunsridhar12345]

The lickspout position is currently being pulled from the software events. This is a static position I believe so it is probably not correct as the experiment goes on. The solution from discussing with Micah seems to be to pull the position from the Harp files. See #19 for more details

[arjunsridhar12345]

Looks like there are Harp files, was looking at the data from the manipulator but was not sure what the values mean. Documenting from a teams convo with Micah:

uh yeah that's not a you thing. I need to link up with Jessy about how he is currently transforming the coordnates

[micahwoodard]

@arjunsridhar12345 talked to @jessy-liao and the current software transforms the stage coordinates so the positions where the lickspout is measured from a monument position is 0, 0, 0. I believe we achieve the same normalization between boxes with our current implementation, but I'm not sure how we want to handle the coordinate transformation so they are consistent between current and refactor. I think we would need to handle it at the rig because there isn't enough information afterwards, but I'm reluctant to take on a mapping and add extra coordinates and complexity to keep track of. @bruno-f-cruz any thoughts?

[bruno-f-cruz]

We should use the same frame of reference as the hardware to prevent any meaning drift. The manipulator already defines a 0,0,0 that is used for both the Bonsai interface, internal hardware (and probably also the CAD designs). Is there a strong reason to keep the monument position as 0,0,0 instead of using the reference of the manipulator?

[micahwoodard]

My mistake I responded without looking closely at the issue. The real question is how to get stage positions across the session. Looking at the behavior.yml I only see a MoveAbsolute and MoveRelative which would mean you'd need to keep track of the move requests to get the position across the session. @bruno-f-cruz do you know if that's right or am I over looking something

[bruno-f-cruz]

https://github.com/harp-tech/device.stepperdriver/blob/f3788fc8832fbc9f0abef7cacc3f9b8919d2a4b4/device.yml#L379-L380

This should work for what you need. Otherwise, we can also serialize a position at the end of the session (which is what I do in vr-foraging) since the "raw" position is in steps, not coordinates.

[arjunsridhar12345]

https://github.com/harp-tech/device.stepperdriver/blob/f3788fc8832fbc9f0abef7cacc3f9b8919d2a4b4/device.yml#L379-L380

This should work for what you need. Otherwise, we can also serialize a position at the end of the session (which is what I do in vr-foraging) since the "raw" position is in steps, not coordinates.

thanks for the reference. for converting this to coordinates, is the logic below a good starting point and does it make sense or am I way off?

steps = dataset.at("Behavior").at("HarpManipulator").at("AccumulatedSteps").load().data
rig = dataset.at("Behavior").at("InputSchemas").at("Rig").load().data
full_step_to_mm = rig.manipulator.calibration.full_step_to_mm

position = steps * full_step_to_mm

[bruno-f-cruz]

That seems good. You can also just put this information in the aind-data-schema and use it from there, since aind-data-schema should change more slowly than the rig schema. I will leave that up to you.

[arjunsridhar12345]

closed by #47