Hi,
let's break down the problem:
Memory malfunction:
This is a really strange situation. It seems like the Notochord is able to write to the eeprom, otherwise you should get a fail to write or read EEPROM memory error.
Could you send me the output of the following commands?
i2cset -y 1 0x73 0 0xff && i2cdetect -y 1
and
i2cset -y 1 0x73 0 0xff && i2cset -y 1 0x51 0x4F 0xab && i2cget -y 1 0x51 0x4F
run them on your raspberry with only the malfunctioning K-Ceptor attached to the Hub.
Also try running the Notochord in verbose mode (with the -v1 argument flag):
Do you get a [warning] .. No EEPROM calib data found.. or a [debug] .. EEPROM calib data found .. message?
(By the way, those <calibration> tags that Notochord dumps after the calibration can be copy-pasted to the configuration file, as a fallback when there is some problem with the EEPROM)
Z rotation (yaw) drift
First of all, when you say that the KC seems to be "tilted at angle when it isn't." Are you always referring the a misalignment on the Z axis right? Because "tilt" is normally associated with a rotation on an horizontal axis. I'll assume problem here is with the Yaw (also called Heading), as in this picture
Yaw_Axis.svg: Auawisederivative work: Jrvz CC_BY-SA_3.0
There's a lot to be said and done with this respect. The fact is that Chordata and many other inertial mocap systems relies on a type of sensor technology called MEMS. Those sensors are small, inexpensive and deliver amazing results; although with some drift. Another factor that might come into play here are the indoor magnetic disturbances. Paradoxically, even if most of the times we need to capture movement in indoor environments. they are the worst place to use this technology.
But, not everything is lost. Complex algorithms and calibration can be implemented to compensate these flaws. We are currently using only the Madgwick's sensor fusion algorithm, which does a great job but doesn't implement a dedicated magnetic disturbance compensation .
Moreover, the good news are that absolute Yaw drifts are not really a great deal when doing mocap (they would be a problem if you use these sensors for navigation). The only important thing is that the relative changes on the heading should be consistent with the movements of the K-Ceptor. in order to test if that's the case try this:
- Rotate the KC by a 90° angle, and hold it still for some seconds.
- Has the virtual KC changed by the same angle?
- Repeat from (1), but choose a different 90° angle on a different axis!
>>When the KC is not well calibrated you will clearly see it drift to the same Heading after some seconds.<<
AxonSpark I have tried re-calibrating multiple times, but I'm still getting this Z-rotation drift. Any ideas on what I'm doing wrong? Or is drift like this to be expected?
Even if, as said, a little drift is expected yours is really big. Could you please post the images generated during calibration? you will find them inside the notochord/bin folder.
AxonSpark Also, I noticed that there was some slight jittery movement noise coming from the sensors. Will there be options in the production version of the software/plug-in to smooth out that noise?
In the future we would like to implement different fusion algorithms. And we've recently realized that we could be using a higher refresh rate with the current hardware.
At this stage we are putting all our efforts on the usability of the system in order to make you guys have a working suit asap. Once we are done with this first stage of the betatester's program we will go back to improve the overall accuracy of the capture.
