-
Notifications
You must be signed in to change notification settings - Fork 0
Limitations
Here are some things that don't work properly with this toolbox:
Non-blocking mode is when you use (Request<datatype>() -> DataIsReady() -> Receive<data_type>) to get your data.
For some reason, on 64-bit Windows with API 3.14, repeatedly calling DataIsReady() corrupts communication between the host computer and the SCU. Not sure why this happens, but I managed to replicate it in both C and Matlab, so I suspect it might be a bug in the API.
For accessing real-time data, this is not really an issue, just read data out repeatedly in your main experimental loop, and you have data without problems.
For buffered data in your experiment, I would recommend using DataBufferInitializeFile(), DataBufferStart() and optotrak_stop_buffering_and_write_out() in each trial. These functions let you collect real time data while buffering, or you could do something else in your experimental loop while recording.
The ODAU functions are not an immediate priority. I think you'll have to write wrapper functions in C as well, because the ODAU data is also organised in structure arrays.
The use of Euler angles is the most logical approach: it has a translation (X-Y-Z) and rotation (Roll-Pitch-Yaw, in radians) return array. This is what is used in computer graphics and in games. I just didn't implement the rest.
The wrapper functions I wrote have access to the raw data, and they are set to do the conversion on the host computer. Most Matlab users won't need this feature. NDI's conversion algorithms are very accurate and robust. If you want to develop your own algorithm to calculate positions from the raw data, you can expand this toolbox with your centroid conversion script.
Storing raw data is very convenient, as it allows the extraction of coordinates as well as rigid body transforms. Also, should you decide to re-calibrate your system, you can do the conversion with the updated camera files or rigid body definitions.
As far as I can tell, FileConvert() only works when the camera file is loaded and the number of markers are previously defined. You can do this with OptotrakSetupCollection() or OptotrakSetupCollectionFromFile(), but that only works when you previously executed TransputerInitializeSystem() which requires TransputerLoadSystem(), which requires TransputerDetermineSystemCfg() to be called and be successful. However, TransputerDetermineSystemCfg() will fail if it doesn't detect an SCU and a camera. I haven't found a workaround to this.
The function that is responsible to handle the camera registration using raw data recording of a static rigid body, nOptotrakCalibrigSystem() always fails. I don't know why.