Slip Kinematics and Detection - Build Log

duncan006

Hello Everyone,

Haven't been quite as active on the forums the past few days while getting the attachments designed for the k-ceptor cases. Still waiting to get the 3D prints to actually attach the sensors, so in the meantime I typed up my build log.

Going forwards, I will use this thread to post progress update and issues related to this project.

Goal

Our goal is to build a motion capture system that can be used to capture walking kinematics anywhere. This is necessary because we are using motion capture for slip and fall studies. Combining a standard motion capture system with a harness to protect the subject from fall related injuries is difficult, and made much easier by Chordata's features. Additionally, it allows us to take captures anywhere, with real time data streaming to our algorithm - no computer necessary. To do this, I run the Notochord with "./notochord --raw --scan localhost" and receive the data in a python program. Because of this, I have a small library of highly configurable OSC listeners that can read, sort, label, and print or re-transmit much of the code from Notochord. I would be happy to share these if anyone has any use or need - for instance, logging data on the Raspberry Pi until the OSC redirect is fixed. You can find the algorithm version on GitHub, here. It's not perfect, and it probably has more than a few redundancies, but it works.

If interested, you can find some previous research done by our head professor in the form of an accurate 5-IMU slip detection algorithm here. This is also the algorithm that we are currently running on the pi.

Build Log

The system came into my hands as the fully soldered k-ceptors and hubs. I know my limits with soldering, so we decided to enlist the help of our more practiced lab tech.

Initial Setup
First things first, to anyone reading this at any time before they turn the system on (because it can't be said enough):

DON'T LIVE PLUG K-CEPTORS IF YOU ARE DIRECTLY POWERING THE HUB. YOU WILL BURN THE CONVERTER. This caused some confusion, but we use the 3v3 rail now and everything works fine. I have live-plugged k-ceptors while using the 3v3 rail for power (for instance, when calibrating many sensors at a time) and have not noticed any adverse effects.

The docs page doesn't make this very clear because of the way everything is presented, but jumpers are necessary no matter which configuration you use. For the 3v3 rail, you need 1x microUSB and 5x jumpers. For the dedicated power source, you need 2x microUSB and 4x jumpers.

The SBC setup by itself is very well documented. However, if you're missing a keyboard and monitor like I was, the referenced chapter 1.6 does not exist. You can find the instructions I used at this link, make sure to enable SSH while you're in there.

Got stuck on plugging in multiple k-ceptors for a while. Took me a while to figure out, but the system only detects the second k-ceptor in a string if it's plugged in the reverse way from the other two. Like (HUB -- OUT/ID_0/IN -- IN/ID_1/OUT -- OUT/ID_2/IN). Not sure if this is intentional or not, because I didn't notice anything about it in the docs.

The blender documentation is the other piece of the documentation that's well done. Even with no experience in the software, I was able to get it up and running quickly. I might add that currently the stats node is a little off, so if the system stops on you, try deleting it from the node view.

Calibration
I tried to use the printable box, but due to difficulty and paper size I ended up making my own method. I wrote down the numbers and letters from the box, and folded it into a small cube. I used this to practice a few times before calibrating the sensor with no box. In case anyone else has similar trouble, see below. It's not Picasso but it did what I needed it to.

This was and still is the most infuriating step for me. First, I calibrated them near my computer not thinking about the magnetometer interference. After reading the forums more, I took my sensors outside to calibrate. Even with nothing around, in the middle of my yard, with the new calibration procedure, using a terminal app on my phone to run it (I realize the phone may have caused some interference, now that I'm writing this out) some sensors just don't calibrate properly. Using the same cable, same location, same hub slot, same procedure for every sensor, about half of my sensors are rock solid, a quarter have slight drift (but major over time), and a quarter have major drift. Since then I've been experimenting with recalibrating to try to get a proper solid calibration but with enough properly calibrated and working sensors for my purposes, further calibration has fallen to the wayside for the moment.

Attaching the sensors to the body
This is where I'm at currently. All of the parts (3d prints, screws, nuts, straps, etc.) were just ordered today, so this will be the next update with pictures and STL files. For the raspberry pi, the case that came with the kit was used, with holes drilled for the jumpers. I decided to use the hub case and back brace attachment method that I saw @NakedRabbit use here. I also decided to use his hub case, shown in the same thread. The k-ceptor cases were custom designed, however. Note if you use screws as I am (#2-56), to use brass ones so that they don't have any change of messing with the magnetometer. Pictures below. Will update with pics of the physical cases when I pick them up later this week!

Previous forum posts regarding this setup and issues:
output raw sensor data to pi
calibration errors broken magnetometer

daylanKifky

Hi @duncan006, really happy to see this log. Most users are using Chordata in entertainment applications, so having the opportunity of following your process is quite exciting (at least for me).

duncan006 Got stuck on plugging in multiple k-ceptors for a while. Took me a while to figure out, but the system only detects the second k-ceptor in a string if it's plugged in the reverse way from the other two. Like (HUB -- OUT/ID_0/IN -- IN/ID_1/OUT -- OUT/ID_2/IN). Not sure if this is intentional or not, because I didn't notice anything about it in the docs.

This is strange, you are supposed to plug the Hub and KCs this way:

HUB GATE ----> IN/ID_0/OUT ----> IN/ID_1/OUT ----> IN/ID_2/OUT

So the "flow" goes always from OUT to IN
Are you using self-crimped cables? perhaps they were crimped using the R2.2 requirements (mirrored ends), here's the page with the specs: https://wiki.chordata.cc/wiki/User_Manual/1._Chordata_parts/1.2._Cables#Order_of_the_wires
I'm aware all these versioning and differences in configurations can get quite confusing, but they are part of the beta process🤷‍♂️

duncan006 some sensors just don't calibrate properly.

This is something that some users are reporting.

Are you calibrating the KC inside of the final enclosures?
Check there's no tension applied to the PCB or connectors while calibrating or using the KCs (see the effects of mechanical strain on the magnetomer readings https://forum.chordata.cc/d/104-effects-of-pcb-torsion-on-magnetometer-measurements)
I guess you are, but check that you are using the latest version of the notochord (0.2.0)
If you are using screws, even if they are made of brass, try calibrating and testing the KC which is giving you worst results without them.

NakedRabbit

If you print in PLA after a while the Hub case lid pegs will fall off! Yikes! Sorry! I just taped mine back on...

duncan006

NakedRabbit All good! Thanks for the heads up! The design looked like it "fit" together rather than "clicked" together if you get what I mean, so I planned on putting a rubber band or something around it anyways.

NakedRabbit

I'm just crap at OpenScad. If you know how to make it fit I'll go back to that design in a heartbeat.

duncan006

Thanks for the info daylanKifky

The wires are not self-crimped. I didn't pay much attention to the wires before, because I was given them with the soldered boards and assumed they were the proper order. The opposite of what you suggested seems to be the case, as the cables I am using have ends wired in parallel, not mirrored... and I'm using the 2.2 k-ceptor. However, if it makes a difference, the cable colors I have look more similar to the final image in the bottom right of the page you linked (Wh/Bla/Red/Gr/Ye/Blu) than the actual crimping guide.

As for the k-ceptors:

I have not gotten the enclosures just yet, so they are calibrated and table-tested without an enclosure.
When stored, k-ceptors are loosely placed standing side by side in a box. Working sensors go in and come out of the box without losing any measurement quality.
When calibrated/tested, k-ceptors are held loosely or placed on a wooden table.
I am currently on version v0.2.0b #d051c5a
I have not calibrated or used any sensors with screws in them.

daylanKifky

Oh so, are you part of the first betatesting round?

duncan006

daylanKifky It's an odd series of events, and I'm not quite sure...

As I've mentioned before, I wasn't involved in much of the discussion around the ordering/soldering of the parts. So to my understanding what happened was the head of our research was planning for the v2.3 boards, but there was some sort of complication after buying supplies. We had both v2.2 and v2.3 boards, but due to lack of some component they decided to solder the v2.2 boards. Having never looked into the project until I had the materials in my hands, (and not knowing how long ago the components were actually ordered,) I don't actually know what round of testing these parts were supposed to be a part of.

duncan006

Finally got in a bunch of stuff I needed to actually assemble the system. Back brace, straps, and prototypes of the 3d printed parts. I immediately cut the hard bits of the back brace out and pinned some velcro to be properly sewn later in the week. The hub case looks beautiful - thank you @NakedRabbit for that. The k-ceptor case will need a couple tweaks though, because when I finally opened the straps, the very ends were 2.5x thicker than the advertised thickness (and the thickness of the rest of the strap) and didn't fit. Fortunately, we only printed two, so these will become the upper and lower back sensors, and attach with velcro to the back brace.

NakedRabbit

I like that your 3D printer is slightly less crappy than mine!

I ended up also making a super low-profile case for the Kceptors I think may be to your interest. Printing mine out now for a test, hope to post it soon and see if it helps you!

duncan006

Got in the appropriate tool and RJ-12 headers today to re-crimp my cables. Only have to do one header per cable, without having to re-order any cables so the most time consuming part is properly stripping it. A few minutes tops per cable. Not noting any software differences (calibration or otherwise) but the k-ceptors connect in the correct orientation now!

duncan006

Now that I have the system set up and the algorithm almost entirely finished, I have no choice but to go back to my most favorite of activities - trying to get the calibration correct on these k-ceptors.

While my sensors are steady most of the time, I've identified a consistent problem that every one of my k-ceptors has to a degree. They all start to lose calibration when moved to a specific position. For example, I have three k-ceptors all oriented the same way on a long tube for testing. When the tube is still, the k-ceptors do not move at all. I have had the system running the entire time I wrote this post and the k-ceptors haven't moved. When I roll the tube, the k-ceptors perform well, don't have drift issues, and return to their correct places . However when I stand it on one end, two of the k-ceptors immediately start drifting quickly off-axis while the other one drifts if I put the tube on it's other end.

Here is what I have done this time to try to remedy this:
Recalibrated and retested multiple times
Rewired the three sensors in different configurations (0-1-2, 2-1-0, 1-0-2)
Calibrated the sensors in an empty room, standing on a non-metal chair
Calibrated both out and in final enclosures with same issues
Ensured that the phone used to access the pi via SSH was 6+ feet away
Using a magnet, double checked that the brass screws and nuts were not magnetized
Tried calibrating with a different order of moving the faces
Sensors are stored loosely (so as not to torque anything) inside a box, are re-calibrated after being taken out of the box, and are only laid flat in between calibration and testing.

After recalibrating and retesting so many times, I'm finally getting close to having it properly working, I just need to figure out this odd issue. If necessary I can post video of these tests to better illustrate the problem I'm having. Am I just going to have to take them to a park to calibrate without magnetic interference?

P.S. Almost stopped testing because of the very frequent errors in the Blender addon, even without any nodes attached except the Notochord node. If anyone happens across this with the same issue, a patched version is here and works beautifully.

daylanKifky

have you tried calibrating and testing without the metal screws? even if they are made of brass they might be causing some disturbances

duncan006

daylanKifky I recorded a couple quick tests to illustrate the problem, both with and without the cases on the two outer sensors. I re-calibrated all sensors in between tests (note: I don't think I recalibrated the second sensor from the left before the first test). While sitting still, and during most rotations, the sensors function fine. But most of the sensors have a point that, when held at, they start drifting.

Test 1 With Cases
Test 2 Without Cases

daylanKifky

duncan006
OK, thanks for the video, I now see the problem more clearly.
I assume you are using the notochord 0.2.0.

please repeat the second test and..

Plug a Dump node to the output of the Notochord node and leave only the Extras option enabled
At the beggining of the capture rotate the sensors around as I do at 7:20 in this video

The sensors need to get some info from the environment at the begginig to perform an auto-calibration once in a while. The behavior you are getting might be due to them collecting too many similar samples and performing the auto-calibration with an homogeneous set

The dump node with extras activated will print the messages that are used to color the bones in the video (with an address like /Chordata/extra/<bone name>/amcov. The second parameter is the magnetometer error, it will start big (red) and after moving them around it should be reduced to below 50 or so (green).

Let me know how it goes

duncan006

daylanKifky

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.