Calibration issues

highmatergogo

hi guys, been trying to get my kceptors calibrated.

I've tried 5 and only two have acceptable calibration, the other 3 drift.

When I do the calibration, do I have follow the sequence of numbers on the box or does it not matter which order you do each face? I feel like I'm missing a piece of the jigsaw!

Is there anyway to check the calibration data before and after?

I'm going to continue trying to calibrate the remainder of the kceptors now.

highmatergogo

Update: I've managed to calibrate 4 out of 15.

I am getting "Floating point exception" on 2 of the sensors. What component would likely be at fault there?

Update: Pretty sure the Floating point issue is just poor solder joints. Will check this tonight.

I've checked that all kceptors with drift issues are successfully loading their calibration from memory and they are absolutely fine. It does feel exactly like the calibration hasn't saved as the ones that have calibrated well are rock solid.

highmatergogo

Video for reference (I did mostly 90 degree turns and put the sensor back on the desk):

https://youtu.be/5tryPVnJLzA

highmatergogo

So, I've followed @AxonSpark 's threads about his drifting issues (thank you @AxonSpark and @daylanKifky for the info.) using the info there I tried a few things.

Firstly, I looked at the calibration image of which there was a 'tail' on a drifting kceptor. After some trial and error I managed to get the following calibration:

Axonometric

Front

Right

Top

Yet I still have the drift. I'm going to stick with this one kceptor now as I have a reliably drifting sensor even with good calibration.

Is there anything in the soldering that I may have gotten wrong? I assume polarity of capacitors isn't an issue?

daylanKifky

😮 The drift in the video is huge. It looks like there's no calibration at all.

Other users like @AxonSpark reported similar (but more subtle) problems with the calibration. The Plots look fine, the calibration seems to get stored at the EEPROM, but the testcube present some drift.

There's probably a dark bug hidden inside the notochord, but despite our attempts to fix it (based on feedback from @AxonSpark, see this thread) it was never completely gone. The mayor problem for us is that we are not able to reproduce it here, so it is hard to understand what's happening.
The idea is to make a complete and deep review of the way calibration is handled once we dig into the notochord code. December will probably be dedicated to the Blender add-on and the remote console.

For now, could you confirm that the calibration data dumped by the notochord at the end of the calibration process matches the one read from the EEPROM when you run the notochord with the -v1 flag? (debug~ lines starting @ 192 on the following image)

highmatergogo

Hey @daylanKifky

Requested info here - you can see a calibration I just performed and then the calibration data being pulled back when ruinning.

daylanKifky

🤔 .. interesting..
The values are stored and retrieved correctly..
but!

what about this?

The fact that two of the values are at the limits of a signed 16 bit integer looks suspicious to me. Perhaps the bug is leaving some clues behind 🔍️ 🔍️ 🔍️ . Let's follow them..

Could you:

Take a look at the other KCs that present drift. Do they have similar values in some of the calibration vectors?

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?

@AxonSpark perhaps you could try this as well

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

Let me check, try and get back to you asap!

highmatergogo

Think you're on to something @daylanKifky !!!

I quickly checked one of my good sensors and it has the following:

Acel correction vector =[ -10157 24485 -92 ] EEPROM

highmatergogo

Actually, maybe not 🙁

Sensors with drift:
Acel correction vector =[ 12839 32764 439 ] EEPROM
Acel correction vector =[ 32764 -32764 537 ] EEPROM
Acel correction vector =[ -4852 22691 794 ] EEPROM
Acel correction vector =[ -4960 -16013 6818 ] EEPROM

Sensors without drift:
Acel correction vector =[ -10157 24485 -92 ] EEPROM
Acel correction vector =[ 3363 -6850 610 ] EEPROM
Acel correction vector =[ -341 85 -136 ] EEPROM
Acel correction vector =[ 7320 -16860 755 ] EEPROM

Apologies for the delay, I could pulled into a meeting!

Do you want me to provide data for all kceptors or is the above enough?

I did try the:

But it appeared to make no difference to the drift.

daylanKifky

highmatergogo

Still there's something strange happening there. Most of these numbers look way out of scale. the correction vector for the acel and gyro should look more like this one:
Acel correction vector =[ -341 85 -136 ] EEPROM

(small values not far from zero)
could you send me a dump of the raw values from one or two KCeptors? please paste the acel and gyro correction vectors at the beggining of the file.

in order to do it:

Place the KC horizontally on a plane (as in step #1 of the calibration)
run ./notochord --scan -t file -t stdout --raw, leave it running for some seconds
You will find the dump at /notochord/bin/logs

highmatergogo

https://drive.google.com/file/d/1gp2rAC_jpOdJc9wqZiWOkQu0gSR6qfUf/view?usp=sharing

EDIT: apologies, I hadn't added the calibration data for each one to the beginning of the data output. I have now.

daylanKifky

it seems like the link is not public.
You can upload .txt files here

highmatergogo

chord-log-2019-12-05.txt

74kB

highmatergogo

Not sure if that worked @daylanKifky , I get file not found when I click it.

Here it is on Dropbox:

https://www.dropbox.com/s/db93fwe6wu8uriz/chord_log_2019-12-05.txt?dl=0

daylanKifky

Well, there's in fact a problem with the gyro and acel correction vector calculation.

The correction vectors for the first KCeptor should be:

<calibration type="offset" target="gyro">
	3	-7	-2
</calibration>
<calibration type="offset" target="acel">
	-545	161	-72
</calibration>

Could you try them with the KCeptor and tell me how it went?

These values can be found by reading the dump as a CSV and averaging each of the columns. Since the sensor is facing up the gravity value has to be subtracted from the acelZ. The raw 16bit value for the gravity in this case is 4098

The order of the columns is :
[time] /KCeptor/address, gyroX, gyroY, gyroZ, acelX, acelY, acelZ, magX, magY, magZ

highmatergogo

Thanks daylanKifky

I'll try this shortly and get back to you. Sounds promising.

highmatergogo

Apologies for the delay.

I tried your suggestion @daylanKifky but it resaulted in the kceptor spinning on the spot! i.e. made the drift infinitely worse.

I double checked everytying by recalibrating, outputting the raw, calculating the averages and updating the XML. I got the saem result.

Seems something is definitely not quite right here!

highmatergogo

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

First test average:
-2.544857768 0.085339168 -0.277899344 0 0 4116.157549 -690.3522976 2092.098468 -2703.354486

Second test averages:
1.948051948 -0.124304267 1.319109462 0 0 4100.897959 -1510.54731 1744.456401 -2612.45269

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

This is very strange!

These are the averages I get for one of my good kceptors:

1.326315789 -0.589473684 1.205263158 -8.389473684 -11.26052632 4091.415789 -378.2263158 2056.305263 -2778.139474

But these are the calculated values, that work well.

debug~[ 268] Gyro correction vector =[ 11 -398 107 ] EEPROM debug~[ 321] Acel correction vector =[ -15425 21733 269 ] EEPROM debug~[ 374] Mag correction vector =[ -29 -2146 26 ] EEPROM