Slip Kinematics and Detection - Build Log

duncan006

Filmed a bunch more tests and threw them all in a playlist - Playlist here

Test 1 & 2 - the original tests posted above
Test 3 & 4 - Filmed before your response. Double checked that the screws did not have any effect on the readings. Couldn't find nuts to test, will test another time. Realized that the binder clips I was using affected them, so checked the extent of it and stopped using them in these and subsequent tests. Had a decent impact.
Test 5 - 9 - Filmed after response. Actual sensors aren't quite visible because I was trying to get the dump in frame. During the first test (#5) there was a lot of variation which decreased steadily over each test as I waved the sensors around like in the linked video. Test 9 is surprisingly solid for all of the sensors, with only small bit of drift.

EDIT: just thought about this... does this extra calibration happen in the blender addon or the notochord? Because if it happens in the blender, it looks like I'll need to calibrate it in my program somehow.

duncan006

With this new calibration, I pretty much have to send the data through blender in order to have accurate angle measurements. However, any attempt to use the forwarding node has only sent the quaternion values even when the notochord is running with --raw. Is there any way to get both raw and quaternion data through blender?

Once we get this, we should be good to start small scale data collection for our project.

daylanKifky

duncan006
Oh yeah, the forward node currently has only the quaternion datatarget implemented. Let me see if I can give you a solution to send the data out of blender later today

daylanKifky

Hi
this should make a custom node that forwards RAW packets (I haven't tested it)

In order to use it

open a text area inside blender and create a new text datablock by clicking in the [New] button in the top center of the area
paste the contents of the script, eventually tweak things and then click on the [Run script] button on the top right of the area
Within the node area add a [Custom node], I included a button to start or stop forwarding data.

You might need to connect it directly to the notochord, because the armature node might be dropping the raw packets. Use the Dump node to test whenever they are being outputted by a particular node

Let me know how it goes! and if you need assistance understanding the custom node code don't hesitate to ask 😉

duncan006

daylanKifky Thanks for the script! I just finished running a few verification tests with it, and it works beautifully. Only thing is that it uses the exact same address as the quaternions. No problem though, I used the number of arguments to determine which was being passed each time. Should keep working as long as nothing other than the raw and quaternion packets gets forwarded.

daylanKifky

Hi!
Glad to know the script works correctly.

There should be a difference in the OSC Address Patterns of the raw and quaternion datatargets.
The first one should be like /Chordata/q/<name of the bone> while the second one /Chordata/raw/<name of the bone> (considering you are not using bundles by passing the --no_bundles flag to the notochord).

You could also use a different port number for each type of payload

duncan006

daylanKifky Thanks for the tips, the --no_bundles flag was what did it for me. Without it the address didn't have the /q/ or /raw/.

duncan006

Hello,

Tested out receive rates today, and noticed some odd behavior from the --odr flag. Dealing with slip, milliseconds can count, so I was documenting average frequency for a range of odr values (50-90Hz in increments of 10, 90-100Hz in increments of 1) and saw that the average value at 100Hz, and only at 100Hz, was basically in line with the average value at 50Hz. Note that the script I am using to take these times bundles the raw and quaternion packets back together, so the times measured are between each set of raw and quaternion values. The average values for each odr value are graphed below. Only one sensor was used for these tests.

Because I was using the data coming out of blender, I wanted to verify that this problem also existed for the data coming directly out of notochord. The individual graphs look fairly different (a lot more variation in frequency when coming out of blender as opposed to the notochord), but the averages are almost exactly the same.

Here you can see that the odr=50 graphs and the odr=100 graphs for each output are almost exactly the same, not just the same average.

Sample Frequency Variation from Blender from 50-100 in Increments of 10, y axis 0-0.1 seconds. Upper left to lower right.

Sample Frequency Variation from Notochord from 50-100 in Increments of 10, y axis 0-0.05 seconds. Upper left to lower right.

I am currently on notochord commit d051c5a0fe10787a6b332bc5d0a2a871040dac2b, which I believe is the latest significant version.

For now, I will be using --odr=97, as that gave the best results in my tests. I will of course have to test with multiple sensors to see how that affects the rate.

While I'm already on the topic... Is there any potential way to further increase the sample rate, especially for the raw values? My professor is looking to push it as far as possible to gain those extra milliseconds.

Edit: Updated images for increased clarity

daylanKifky

Hi.
The --odr flag was added on 0.1.2 as an experimental feature and since nobody used it until now we focused on developing other areas of the program.
Currently the new sensor fusion algorithm has a hard coded odr of 50, so if you change it you will probably get wrong quaternion values.

As I already commented to you, the notochord has to go thought a comprehensive re-writting process. It currently has many inconsistent configuration options, and it's hard to update or maintain. This revision is planned to be accomplished by the end of this year. Until then it would be really hard to effectively tweak the odr

duncan006

Hello,

Starting to process some data from various runs, could you break down what units everything comes out in? I've gotten that the quaternions have the odd component first but I'm still struggling with the proper units of acceleration and the like.

Apologies if this is already somewhere on the wiki, I trawled the forums and docs for a bit before posting.

daylanKifky

Hi,
I think this is not yet documented in the wiki.
The format for the raw lectures is:
/Chordata/raw/<bone> gx, gy, gz, ax, ay, az, mx, my, mz
where:
g=gyro
a= acel
m=mag

and just to be sure, the quat is:
/Chordata/q/<bone> w, x, y, z

duncan006

daylanKifky Thanks for the information, already have all of that figured out though. By "units" I meant "m/s²" for acceleration or "radians/sec" for angular velocity.

daylanKifky

Oh, yep. That makes a lot of sense. I'm sorry for the confusion.

The values you get with the raw stream have no units. They are the signed 16bit integer that comes out from the sensor. You have to convert them to real values by applying the sensitivity at which the sensor is working.

In the case of the notochord 0.2.0 this sensitivity is hard coded at

SENSITIVITY_GYROSCOPE_2000 //(dps)
SENSITIVITY_ACCELEROMETER_8 //(g)
SENSITIVITY_MAGNETOMETER_4 //(gauss)

This constants come from the LSM9DS1 datasheet and are defined in lib/imu/LSM9DS1_impl.h as:

#define SENSITIVITY_ACCELEROMETER_2  0.000061
#define SENSITIVITY_ACCELEROMETER_4  0.000122
#define SENSITIVITY_ACCELEROMETER_8  0.000244
#define SENSITIVITY_ACCELEROMETER_16 0.000732
#define SENSITIVITY_GYROSCOPE_245    0.00875
#define SENSITIVITY_GYROSCOPE_500    0.0175
#define SENSITIVITY_GYROSCOPE_2000   0.07
#define SENSITIVITY_MAGNETOMETER_4   0.00014
#define SENSITIVITY_MAGNETOMETER_8   0.00029
#define SENSITIVITY_MAGNETOMETER_12  0.00043
#define SENSITIVITY_MAGNETOMETER_16  0.00058

They are pre-calculated values. For example for the gyro they are DPS / (ADC tick). In case you wonder which ADC: the one inside the LSM9DS1 which converts internally the actual readings from the sensing structures to digital values. One ADC tick is one of the signed integer values the sensor outputs.

So, the TLDR version:

For example to get the DPS for the gyro you can multiply:
<reading> * SENSITIVITY_GYROSCOPE_2000

Of course these real values are calculated inside the notochord before feeding the sensor fusion algorithm. But they are currently not exposed. We plan to add a real datatarget to get them directly in the future.

Let me know if this helps

duncan006

daylanKifky Thank you! This was what I was looking for!! So If I'm understanding your writeup correctly, the only values I need to worry about are

#define SENSITIVITY_GYROSCOPE_2000 0.07 #define SENSITIVITY_ACCELEROMETER_8 0.000244 #define SENSITIVITY_MAGNETOMETER_4 0.00014

And just to make sure - dps is for degrees per second yes?

duncan006

Hi,

I posted a few months ago (July 22) about using the --odr flag to increase read rates, and ended up just maxing out the read rate at the expense of the sensor fusion algorithm. Instead, I coded a basic fusion algorithm that has worked remarkably well for simple walking analysis, but is terribly inaccurate over long tests and complex motion (particularly turning, which is a large issue).

I am wondering if any progress has been made with regards to the --odr flag, so that I can continue collecting data at 50Hz without having to sacrifice the sensor fusion algorithm. Additionally, my head researcher is curious if we could push it any farther (100Hz was the number he had in mind).

I am aware that the full rework (which will likely include this) is not promised until the end of the year, but I wanted to check on this one particular issue.

Thank you.

« Previous Page