Calibration issues

highmatergogo

Data sample for one arm (fine):

Data samples for two arms (laggy):

daylanKifky

🤔 it also has a problem recognizing the "clear" command in (your are using windows, right?) so the output is completely messed up. I'll update it to work on windows and avoid crashing asap.
The first readings tend to be at a different rate, after some seconds the notochord will stabilize and should send at a more constant rate

highmatergogo

daylanKifky Great, thank you.

Just out of interest, are you running the i2c on the default baudrate of 10kHz?

highmatergogo

We managed to get the script running reliably on windows. We also adding printing of the sample_delay which you'll see hits 0 a few times. Our readings of just 3 sensors are WAY off from the screenshot you printed of a full suit.

highmatergogo

And both arms for comparison:

highmatergogo

So we finally have both arms working perfectly!

We added core_freq=250 to /boot/config.txt after reading a guide saying that the i2c speed was tied in with the VPU speed. Setting core_freq apparently gives it a fixed speed to run at.

We're going to try a full suit now and will report back.

Also, we were running the full default_biped.xml with only arms plugged in, this was causing a drop out for about a second every 10 seconds or so. Once we created an xml with ONLY both arms this problem went away.

Will report back shortly.

highmatergogo

Full suit gives same issues as before. We've tried increasing the core_freq to 500 and also reducing it to 100. Same issues.

@daylanKifky, did you make any changes to your raspberry pi config?

daylanKifky

highmatergogo
I think you have just hit the nail on the head!!!

In order to set the i2c baudrate to 400kHz in the rapsberry I use
dtparam=i2cbaudrate=700000 in /boot/config.txt

apparently there's an issue with this setting in the RPi device tree, and the number you set gets modified. A more complete explanation in a german article linked here: https://www.raspberrypi.org/forums/viewtopic.php?t=197707

I now realize that we have never explicitly told no one to increase the default baudrate on the RPi. This might be a game-changer. Let us know how it goes.

Did you try to measure the actual baudrate with an oscilloscope? you can use the i2cdetect -y 1 command to make the RPi issue some i2c readings, and put your prove on the SCL line (TP9 on the Chordata Hub)

PS: Does the phrase hit the nail on the head actually mean something in english?? 😅

highmatergogo

So we seem to have a full working suit!

We added these lines to the bottom of our /boot/config.txt:

core_freq=250
dtparam=i2c_arm_baudrate=400000

@AxonSpark do you want to give that a go?

AxonSpark

highmatergogo I just got a couple of editing gigs, so I won't be able to run a test until next week at the earliest, but it's good to know that we're approaching a solution.

highmatergogo

THIS IS SO MUCH FUN!

We didn't have the hand sensors on properly so wrist rotation is incorrect!

Also, we're sticking with @daylanKifky's suggestion of just:

dtparam=i2cbaudrate=700000 in /boot/config.txt

We get great results with that.

daylanKifky

highmatergogo

ALRIGHT!
We should definitively add this to the documentation ASAP!

Everyone on the team is enthusiastic with what you've done!

highmatergogo

daylanKifky Ah yes! That's awesome! We're super psyched here too! Soooooo good to see that Solved tag!

We're going to spend tomorrow getting our demo dance recorded and exported to our unity project. I'll be sure to share it on here for you all to have a look at too.

And yes, "hit the nail on the head" is very much in British vocabulary! 🤣

Guiltyfeet

Locking the discussion since the problem was solved.

« Previous Page