Add operator to spatial transform ts4231 data #432
Conversation
|
|
||
| private void EnableButtons() | ||
| { | ||
| buttonMeasure0.Invoke((Action)delegate |
There was a problem hiding this comment.
Why are the EnableButtons and DisableButtons so different? I would have thought you could create a single method SetButtonState(bool state) and assign the boolean to each button
There was a problem hiding this comment.
Yeah so I was getting "cross-thread operation not valid" errors during run-time when I would call win forms methods from a Subscribe's lambda function. Using this winFormControl.Invoke((Action) delegate {...}) pattern (relevant documentation) was one way to get around this. There might be another more elegant to prevent this error though. I wanted to look into it before issuing the PR, but I think it became time to put this out there and see what people think. Did you ever run into this kind of error?
There was a problem hiding this comment.
I never encountered this error, but I also was not running the dialogs while the workflow was active. Is this the method that the other Bonsai nodes use to handle passing data?
There was a problem hiding this comment.
That's a really good question. When I started, I cloned the Bonsai library and started developing on top of their GroupBy operator, slowly incorporating in bits of pieces from the RoiActivity operator and my own code to make it what we need. When I was doing this, I never ran into these errors. When I ported it to the OpenEphys.Onix1 library, these errors started occurring. I'm not immediately sure how these threads are being handled under the hood that this behavior wouldn't occur when developing on top of the Bonsai library but they would in our library.
There was a problem hiding this comment.
I can get around using the winFormControl.Invoke((Action) delegate {...}) pattern by using the ObserveOn and ControlScheduler. This is probably how Bonsai takes care of this problem. I'm using their Bonsai.Design.ControlScheduler() method to do this. This is what I added in c3e951d
- Consolidate win form event handlers - Initialize SpatialTransformMatrix property to indentity matrix - Refactor some functions here and there
- This is a more elegant than using the `WinForm.Control.Invoke` pattern to avoid cross-threading errors
- I think the the sptial transform should be another property within TS4231PositionData that allows the user to map the base-station-based coordinate system into an external coordinate system - Defaulting to identity matrix means that this does nothing by default.
There was a problem hiding this comment.
This is an interesting idea but we need to do some things to make it useful generally. I've committed some changes that start to move in this direction. Other refinements are
- The user needs to be able to cancel a measurement and start over. Or a timeout needs to be set that will cancel a measurement if some time has elapsed before lighthouse data is received.
- Ideally the editor should not display unless the workflow is running. I think there are ways to check the run state of a workflow when an editor is opened.
- add cancel button - add timeout (probably only need timeout or cancel button) - check workflow is running before opening GUI - leave text boxes blank - correctly populate ts4231V1CoordinatesMatrix - give persistent scope to subscriptions so they can be disposed - simplify conditional statement for checking if user input is valid - minor edit to top-level label to be consistent with changes
|
I made changes and did some cursory testing to make sure it looks ok and still works. I didn't have time to extensively test this latest commit. There is one problem with the current implementation which is that the calculated matrix spatial transform is only correct if we are already starting with an identity matrix. |
|
It seems like the user supplied coordinates are verified in real-time for the correct format. It would be nice to have a status text indicating if the input is valid or not (e.g. "input coordinates invalid vs. input coordinates valid". You can a tool strip for this (see e.g. Rhs2116StimulusSequenceDialog.cs:
|
|
Instead of this:
use the standard "OK, Cancel" pattern:
See |
…Dialog - This should recover the raw position values from P and Q alone without the M that is currently being edited.
|
@jonnew Re:
I'm wondering if it would be worth indicating which coordinate is invalid. like having green checks or red x-es for each row or each cell (probably instead of the status strip) as indicated by this screenshot:
|
jonnew's feedback: - Add status strip - Use "OK", "Cancel" button paradigms additionally: - Improve resizing - Address all VS messages - PascalCase methods - Make "using" syntax more concise - Add/Edit some XML comments - Instead of transforming every Vector3 and then averaging, average all Vector3s and then take the transform - Inline/remove the GetData() function
|
I addressed feedback (look at commit message for more details). I tested calculating a new M from a pre-set M. This seems to work OK. |
|
If I click measure for a coordinate with data in it, and the measurement is invalid, it doesnt get rid of the old measurement
Desired? |
|
Here are some changes I think would be helpful to the UI
|
|
It is possible to create a transform that collapses dimensions by providing zero for a given dimension. For instance if all my calibration data is in a single X,Y plane, this is the result:
This should not be permitted. |
|
Several overall architectural comments:
|
- The operator is now an included workflow comprising of ts4231
source node and a spatial transform node
- The property that's set by the dialog is a struct containing
pre-transform coordinates, post-transform coordinates and spatial
transform matrix instead of just the matrix
- Add workflows to ItemGroup in Onix1.csproj
- Revert TS4231V1PositionData
- Dialog changes:
- Add X, Y, Z labels
- Add a textbox for each component of each coordinate instead of
one textbox
- Add a textbox & label for displaying Spatial Transform Matrix
- Change status messages TextBox to RichTextBox which allows
changing font color and using newline characters instead of
environment.newline.
- Automatically calculate transform matrix when inputs are valid
(avoids decoupling sets of pre-transform & post-transform
coordinates and the spatial transform)
- Simplify bottom toolstrip behavior
- Move event handlers to top and helper methods underneath
- Change instructions in top label according to the above changes
Resolve #427