Calibration issues

daylanKifky

there's definitively a problem, probably a very tiny and subtle one, but with huge consequences.

I went trough the code today and I can' t find the problem. I will probably need some time to carefully review it.

If you want to give it a last shot: could you try to get the raw dump while zeroing the calib offset with:

<calibration type="offset" target="gyro">
	0 0 0 
</calibration>
<calibration type="offset" target="acel">
	 0 0 0
</calibration>

and calculate the averages after that.

Do you have some experience with C++ code or GDB? I so can give you some some advances tests

highmatergogo I just ran this test again and the averages are quite different. Different enough to make a difference?

In this case the difference is small enough to take them for the same:

larger_delta = -2.54  - 1.94
max_scale = 65535
error = larger_delta / max_scale
# error: -6.836041e-05

highmatergogo

I'll give the zero out raw data dump a go now.

I'm a coder but a colleague of mine is. Do you want to send me the tests and I can get him to take a look?

highmatergogo

Averages with XML set to zeros (on the bad kceptor):

9.911051213 -4.591644205 1.066037736 0 0 4067.90566

I got the spinning kceptor in blender with these values added back into the XML.

Please feel free to pass those C++ test over, I'll get my dev to take a look tonight.

daylanKifky

You can try to explore the execution with GDB

First, running in calibration mode set a breakpoint at
double LSM9DS1<IO>::calibrateGyroAcel(float max_slope)
on file LSM9DS1_impl.h

a good test point would be line #451, before the sample averaging is performed inside this loop:

	for (ii = 0; ii < 3; ii++)		{
		this->gBiasRaw[ii] = gBiasRawTemp[ii] / samples;
		this->aBiasRaw[ii] = aBiasRawTemp[ii] / samples;
	}

Do gBiasRaw or aBiasRaw get filled with reasonable values?

Now on normal running mode take a look at Chordata::K_Ceptor::Bang() (this function is kind of messy right now and it would be hard for outsiders to get most of what's happening there, refactoring it is one of the first steps on the notochord roadmap). In line #350 it calls the actual reading of the sensors:

		imu->readGyro();
		imu->readAccel();

in these functions aBiasRaw and gBiasRaw should be subtracted from the incoming vectors. Are these offset consistent with what you read on the first stage or with what's stored in the EEPROM?

highmatergogo

Just checking you didn't miss our reply above daylanKifky we were really proud we had managed to get the debug figures 😂

highmatergogo

Great, thanks @daylanKifky, we'll take a look asap.

highmatergogo

Right! That was fun!!!

Values from calibration:

gBiasRaw: {_M_elems = {-62597, 84747, 60}}
aBiasRaw: {_M_elems = {1638200, -1638200, 26112}}

Values from Normal mode:

Reading void LSM9DS1<IO>::readGyro(), we got:

gx: 5
gy: -2
gz: 3
gBiasRaw: {_M_elems = {-1258, 1696, -3}}

Reading void LSM9DS1<IO>::readAccel(), we got:

ax: 0
ay: 0
az: 4076
aBiasRaw:  {_M_elems = {32764, -32764, 514}}

And, as a reminder, this is what this kceptor has stored in EEPROM for calibration:

debug~[    269]       Gyro correction vector =[ -1258     1696      -3   ] EEPROM
debug~[    322]       Acel correction vector =[ 32764    -32764    514   ] EEPROM
debug~[    375]        Mag correction vector =[  915     -1871     -245  ] EEPROM
debug~[    690]        Mag Matrix = EEPROM
                        |   0.9738      0.039231    -0.0170931 |
                        |  0.039231     1.00488      0.001159  |
                        | -0.0170931    0.001159     1.02383   |

AxonSpark

daylanKifky I think I need a little clarification on what you're asking me to do.

copy this tag and paste it inside the <K_Ceptor> tag:
<calibration type="offset" target="acel">
0 0 0
</calibration>
this way it should overwrite the EEPROM calibration data with the one inside the tag (please confirm it by spotting the XML word at the side of the Acel correction vector debug line instead of EEPROM)
Does the drift gets any better this way?

Which file do I need to modify? Is it K_Ceptor_offset_calib? Currently, that's the only file where I see code referring to acel offset, Although there are two listed from different calibrations settings. Does notochord automatically look at the most recent one?

<!-- Value written on Wed Apr 24 01:06:40 2019
 -->
<K_Ceptor Name=Unico id="0">
	0
	<calibration type="offset" target="mag">
		-655 -833 -202
	</calibration>
	<calibration type="offset" target="acel">
		-85 -157 -122
	</calibration>
	<calibration type="offset" target="gyro">
		45 0 -7
	</calibration>
</K_Ceptor><!-- Value written on Tue May 21 01:40:14 2019
 -->
<K_Ceptor Name="calibration_dump" id="0">
	0
	<calibration type="offset" target="mag">
		-1816 -829 -744
	</calibration>
	<calibration type="matrix" target="mag">
		0.996618 0.0337802 0.0102339
		0.0337802 0.996509 0.00318466
		0.0102339 0.00318466 1.00818	</calibration>
	<calibration type="offset" target="acel">
		0 -11 -5
	</calibration>
	<calibration type="offset" target="gyro">
		37 0 -1
	</calibration>
</K_Ceptor>

If K_Ceptor_offset_calib isn't the right file, which one do I need to modify? And when I run the Notochord program with the --scan command, how do I instruct the program to read an XML for acel offset and not what is written to the EEPROM?

highmatergogo

Hi @AxonSpark the file is the Chordata.xml where you setup your armature structure.

This is how mine looked after I pasted the code in...

<K_Ceptor Name="Unico" id="2">
    0
    <calibration type="offset" target="gyro">
        0       0       0
    </calibration>
    <calibration type="offset" target="acel">
        0       0       0
    </calibration>
</K_Ceptor>

AxonSpark

@daylanKifky Here are the current offsets I'm getting from my K-Ceptors when running --scan -v1:

At first glance, it looks like I'm not experiencing the high numbers that @highmatergogo was experiencing in Acel, but I seem to be getting consistently high numbers in my Mag correction vector. But then again, I don't know what the Mag correction numbers are supposed to look like, so for all I know this may be normal.

Let me know how I should proceed with further testing/modifying the Chordata.xml file.

daylanKifky

highmatergogo
Hi, I didn't missed your reply.

the values you got on aBiasRaw confirm the fact that a the values are getting trimmed at the signed16bit maximum before being fed into the accumulator. (by the way, are you sure those values are from aBiasRaw and not from aBiasRawTemp?). But it's still not clear to me why is this happening.

Are the values read in normal mode extracted before or after the offsets subtraction?

//Calibration offset subtraction:
if (_autoCalc)
	{
		this->gx -= this->gBiasRaw[X_AXIS];
		this->gy -= this->gBiasRaw[Y_AXIS];
		this->gz -= this->gBiasRaw[Z_AXIS];
	}

I've made a temporary modification to the calibration function to make it print all the values on the branch b_bad_calib, commit #b51666b7

Please use with the --calibration flag send me the output.
In order to use it you have to change branch an re-compile.

git stash #<-- This will clear all the modifications you have done to the local files, including the ones on the XML files. Be sure to make a copy if you want to keep them!
git fetch
git checkout b_bad_calib
git pull

scons debug=1 -j3

@AxonSpark I'm not sure this issue is related with yours. As you pointed out: your offsets look more normal. But keep an eye on this thread: we might find something useful. For the moment I'm focusing on the acel and gyro calibration. The bigger values on the mag vector are expected.

highmatergogo

Awesome. Thanks @daylanKifky, will try this shortly.

highmatergogo

Do you want the whole calibration proceedure or just the initial? @daylanKifky

highmatergogo

(EDIT by admin) content pasted here:

daylanKifky

you are fast!

I'll make another mod on the next days and ask you to send me another dump.
The fact that we are not able to reproduce this makes everything much harder 😤

By the way @highmatergogo and @AxonSpark let's start using pastebin or similar service to put these dumps, it's starting to get hard to read things in this thread. You can just paste the URL of some paste directly as text, and it will serve a nice and tidy <iframe>

highmatergogo

Sure! Will do, thanks for all your help. 👍️

daylanKifky

made a simple mod.
the skip acel and gyro offset correction #04e55373 commit doesn't ever perform the subtraction.

could you:

try if the drift gets any better or worse now.
Send me another dump like the first one I asked you in this thread (--raw and -t file -t stdout flags)
Send me a new output from the calib like the one you did recently?

highmatergogo

Done.

After a calibrate drift is worse - kceptor spins on spot as before with 0 overides in XML.

Raw output:

Calibration output:

daylanKifky

highmatergogo
If you pull and compile now you should get the raw output from the i2c readings.
Run it without any flags

daylanKifky

so, there seems to be some extreme offset coming from your KCeptor. Let me do a last mod to confirm it

« Previous Page Next Page »