Test #1

daylanKifky

AxonSpark Happy Solstice! I give you the gift of another test video, which is probably the developer equivalent of someone giving you a fruitcake.

😁 This video is the closer we've got to grab the problem behind the malfunction of your suit, so It's quite a tasty fruitcake to me.

The config.txt looks ok to me.

Could you try the test listed in the following snippet? (starting from #5)

if you get an error message use this script:

#!/bin/bash
var="$(xxd -ps /sys/class/i2c-adapter/i2c-1/of_node/clock-frequency)"
var=${var//[[:blank:].\}]/}
printf "%d\n" 0x$var

AxonSpark

daylanKifky The speed value that i2cspeed.sh returns is 100000. That's just with the Pi and Hub powered up.

AxonSpark

I should also point out, that my config.txt doesn't look like Step 3. It has dtparam=i2c_arm=on, but it's not followed by i2c_arm_baudrate=400000

daylanKifky

The fact that the configuration parameter is in a new line shouldn't be a problem. But perhaps you can try to set it like that

Instead what I found as a significant difference is the use of

i2c_arm_baudrate

Instead of
i2cbaudrate

I will check again, but I think the latter worked for me.

AxonSpark

Progress!

@daylanKifky I know you're probably on vacation for the holidays, but I figured I'd go ahead and post my latest test.

So it looks like adding ,i2c_arm_baudrate=40000 to dtparam=i2c_arm=on results ini2cspeed.sh returning 400000. However, when I changed it to ,i2c_arm_baudrate=700000 I got this value and message:

Using the 700000 value also resulted in random erroneous results when used in the full biped test.

When I ran ./test_notochord_send_rate.py I got values that were consistently in the high 40’s and low 50’s. Huzzah! When I ran it with -s 25, the values started out in the mid-20’s and then after about 30-ish seconds it bumped up to high 40’s and low 50’s, and running with s-51 it started and remained in the high 40’s and low 50’s.

Since you said that the lower send rates could affect calibration, I went ahead and recalibrated all the K-Ceptors. Although halfway through (after completing all the K-Ceptor 0’s and halfway through the K-Ceptor 1’s), I realized that I had my phone in my pocket, and put it in the other room (more on this later).

Here's the result of my full biped tests:

As you can see, the lag and slow drifting into position issues are gone (yay!), but there are other issues. For some reason the right arm and left leg have issues which are consistent across Attempts #1-3. The right arm doesn't come all the way down to my side when I lower my arms, and the wrist moves counter to my movements. When I twist it side to side the rig bends it up and down and vice versa. As for the legs, I'm doing the same motion of raising it bent at the knee on each leg, but for some reason to left leg bends out to the side. There's also some weird stuttering lag at 1:22, but I think that might be from the screen capture.

Attempt #4 where I used --odr 100 reintroduced drifting and had some downright odd results.

I'm not sure what's causing these problems since I just recalibrated all the sensors. I tested the individual K-Ceptors used in the right arm and left leg, and for the most part the results were difficult to judge. Some had drift, but it was very slight and/or slow. For instance it would hold a rotation value for several seconds, and go up by one (ex. 0.041 to 0.042) which would also hold for awhile before rising in value again. The most obviously problematic one was K-Ceptor 2-5 which was at the end of the right arm:

Local X pointing toward Global +Z: Very slight drift
Local Y pointing toward Global -Z: slow drift
Local X pointing toward Global -Z: noticeable drift that slows over time
Local Y pointing toward Global +Z: Very slight intermittent drift
Local Z pointing toward Global -Z: noticeable drift that slows over time

I would've expected there to be more problems with the K-Ceptor 0's and some of the 1's, so this is pretty baffling since my phone was in the other room when I calibrated this one. If you want to see all the videos of the faulty limb K-ceptor tests (left leg 0-2,1-2, and 2-2 and right arm 0-3,1-5, and 2-5) you can download them here:
https://www.dropbox.com/sh/sa2z4ktyl2yi7uj/AAAx2ZB54gOgkyL-LWOyMay3a?dl=0

daylanKifky

That's definitively progress!! 🥳

AxonSpark The right arm doesn't come all the way down to my side when I lower my arms, and the wrist moves counter to my movements

What happens if you flip sensors btw arms? the misbehavior follows the sensors?
or
Could you try to test one of these "misaligned" sensors togheter with a working one using a dummy like the one at the beginning of the thread?
I want to know if it's a problem on the orientation of the sensor itself, or in the full body recreation/

In which part of the body was the K-C_2-5 placed during the fullbody test #1.8?
All the others seem to be behaving correctly

AxonSpark

daylanKifky I did some limb switching tests today. The limbs from the last test, were configured with the following K-Ceptors:

Right Arm (problematic): 0-3 (shoulder), 1-5 (forearm), 2-5 (hand)
Left Arm: 0-4 (shoulder), 1-3 (forearm), 2-4 (hand)
Right Leg: 0-1 (hip), 1-4 (knee), 2-3 (foot)
Left Leg (problematic): 0-2 (hip), 1-2 (knee), 2-2 (foot)

Test #1: Switching Sides for Arms & Legs

Right Arm: 0-4 (shoulder), 1-3 (forearm), 2-4 (hand)
Left Arm: 0-3 (shoulder), 1-5 (forearm), 2-5 (hand)
Right Leg: 0-2 (hip), 1-2 (knee), 2-2 (foot)
Left Leg : 0-1 (hip), 1-4 (knee), 2-3 (foot)

Test #2: Switching Arms to Legs and Legs to Arms

Right Arm: 0-2 (hip), 1-2 (knee), 2-2 (foot)
Left Arm: 0-1 (hip), 1-4 (knee), 2-3 (foot)
Right Leg: 0-4 (shoulder), 1-3 (forearm), 2-4 (hand)
Left Leg : 0-3 (shoulder), 1-5 (forearm), 2-5 (hand)

Test #3: Switching Sides for Switched Arms to Legs/Legs to Arms

Right Arm: 0-1 (hip), 1-4 (knee), 2-3 (foot)
Left Arm: 0-2 (hip), 1-2 (knee), 2-2 (foot)
Right Leg: 0-3 (shoulder), 1-5 (forearm), 2-5 (hand)
Left Leg : 0-4 (shoulder), 1-3 (forearm), 2-4 (hand)

In all tests, the sideways knee bend issue in the left leg from test #1.8 persisted. I don't know if this might have something to do with the feet. I noticed that when the 3D representation of the sensors were settling in the T-Pose, in all cases the feet sensors seem to be offset toward the left side of the body, whereas the others are resting pretty accurately on the body.

Interestingly, the arms look to be functioning mostly correctly now. However, they both seem to have an issue that I've noticed in past tests that, for lack of a better term, I've been calling "The C-3PO problem". The range of motion of the arms is rather limited. When my arms are resting at my sides, the model's arms look like they're lifted up somewhat. You can also see this in the instances where I try to reach across my chest, bend my elbow, or try to clap. In Tests 1 and 2 the arms look to be more or less resting at the same height, with maybe the right arm being slightly higher. However in Test #3, the left arm shows some improvement as it rests closer to the body, while the right arms rests noticeably higher up.

daylanKifky

AxonSpark "The C-3PO problem"

🤣 🤣 🤣 🤣 🤣 🤣 🤣

I-ll take a look at the problem asap

daylanKifky

HI!
sorry for keeping you waiting. The forum is getting more crowded and it's hard to keep up with everything.

C3PO

It seems like the C3PO problem is due to an inaccurate pose calibration. As a first attempt: try to stand with your arms a little higher while you are in T-POSE. This should make the elbows get closer to the body when you rest your arms beside your body.

If this first attempt gives good results, then the problem starts to get more complex 😁
To get a more accurate pose calibration the virtual skeleton should match as close as possible the real skeleton of the performer. So, since you have blender skills: a good idea would be to modify the skeleton (and why not, the external model) to match yours.
The best way to do it is to take a pictures* of yourself standing in T-POSE, put them in blender as a reference, and modify the skeleton in EDIT mode.

(*) It is strongly recomended to use telephoto lens for this pictures, so the distortion is minimized

Knees bending

This seems like a different problem. The feet themselves shouldn't be affecting the rest of the legs. It seems like there's a heading offset in all the lower sensors.

We can try a couple of things here.

Heading offset test #1

Take some sensors from the lower and upper part of the body. For example

right-leg
left-tight
right arm

Place them all on a rigid dummy, be sure to align them properly and make the capture run while holding the dummy in vertical position. Do all the Z-axis align? Perhaps you can repeat the test with different sensor groups.

Heading offset test #2

This test is done with you wearing all the sensors, like in a regular capture.
Open a 3D view in another region of the Blender GUI. Set that region to a Top, Ortogtaphic view, and wireframe.
Select two sensor_helper objects, so you will end up with a mostly dark viewport, with 2 helpers highlighted in orange.
Make the capture run. Do the axis of these two sensor align (from the top view)?

AxonSpark

daylanKifky I'll try and get as many of these done as possible this month. I have some freelance work coming up, followed by a month long work-cation trip to Los Angeles, so there's a chance I may not be able to complete the tests until March.

AxonSpark

daylanKifky I finished my freelance gig early, so I was able to do the tests you suggested:

Tests #1-4 were Heading Offset #1 tests, where I mixed the K-Ceptors from the previous configurations of arms and legs and tested them using the spine only rig. It looks like there's varying amount of drift in Test #1 at 0:37, Test #2 at 2:10, Test #3 at 3:41, Test #4 at 5:32, and Test #5 (where I tested the K-ceptors I usually use for the spine, dorsal, & head) @ 7:16

The Default Biped Tests, tested both raising arm height to combat the C-3PO effect and Head Offset Test #2. Raising my arms does indeed seem to help with arm position as they were much closer to my body, although things like clapping or putting my hands on my head still don't quite work. I probably won't be able to run a test on a modified model based on my body until March, since I'll be traveling in February.

For some reason, this time both knees were bending sideways (but in opposite directions). In Default Biped Test #2, the axes seem to more or less align in the top ortho view on the left leg. However, in Default Biped Test #3 the axes do not look aligned on the right leg. And unfortunately I didn't make a note of which K-Ceptors I was wearing on my legs for the full biped tests (I realized I should've noted this after taking off the suit), but hopefully some of this information helps.

valor

AxonSpark I'll see if my suite has the same issue some time next week of a week after that.
It's always a good idea to mark, and ideally label, each sensor with a "permanent ID" for QA tracing and troubleshooting. Especially in a situation where you have more than 3-4. Then you can log the work done and the relevant issues for specific units. Some sort of a "service book".
I know, it sounds as an overkill, but considering that we have 15 sensors (and probably few spares) on-hand while dealing with testing and tuning it will definitely help to minimize the confusion.

AxonSpark

valor I do have a permanent ID for each sensor labeled by their place in the hierarchy (0,1,2) and then by number (1-5). For instance the first test in the video is with K-Ceptors 0-4, 1-5, and 2-4, but I was in a bit of a rush with the full biped tests, so I forgot to note which sensors were placed where (some I typically use in certain positions regularly, while others get swapped around).

daylanKifky

Hi.
Sorry for taking so long, but it is not easy to come out with a diagnosis here. The behaviour you are getting keeps surprising me :S.
From the video I noticed a particular behavior that might lead us to some conclusions: At 3:00 you rotate the dummy around the X axis. The two KCs on the top side rotate around their X axis which are aligned, but the lowermost one rotates around a slightly different axis (almost 30º off).
Is this behavior consistent when using this same set of sensors? what happens if you put the lowermost one in another position?

AxonSpark

daylanKifky Ok, I'll run that test when I get back to Seattle in March.

« Previous Page