I just added an update to include all of the Clash Detection defines that profezzorn discusses here:
Care for what you wish for, you might get it…
In the beginning, there was CLASH_THRESHOLD_G.
Originally, the clash algorithm would simply compare the new accelerometer value with the last accelerometer value, and if it was greater than CLASH_THRESHOLD_G, it would trigger a clash, like:
|Acceleration_{now} - Acceleration_{last} | > CLASH\_THRESHOLD\_G
Note that the acceleration values are vectors with X, Y and Z components, and the || takes the length of the vector. In other words, this is the same as doing:
X = XAcceleration_{now} - XAcceleration_{last}
Y = YAcceleration_{now} - ZAcceleration_{last}
Y = YAcceleration_{now} - ZAcceleration_{last}
\sqrt{X^2 + Y^2 + Z^2} > CLASH\_THRESHOLD\_G
The problem with this algorithm is that the frequency of readings changes what it does. If you get more readings per second, then the difference between each one will be smaller, so the same CLASH_THRESHOLD_G wouldn’t work. Back then, Proffieboards were new, and there were lots of Teensysabers still around, and because of differences in how they worked, they would often get different number of readings per second.
So a long long time ago, I changed this algorithm, instead of using the “last” value, I used a slow average of values instead, so the algorithm became:
| Acceleration_{now} - Acceleration_{average} | > CLASH\_THRESHOLD\_G
In ProffieOS 3, this algorithm was improved by adding the Fusor class. The Fusor uses the accelerometer and the gyro to calculate a down vector. When nothing is happening, the down vector and the accelerometer should be the same thing. But this allowed me to change the algorithm to:
| Acceleration_{now} - Down | > CLASH\_THRESHOLD\_G
So far, the improvements have been just that: improvements, however, at this point the story takes a bit of a turn… I discovered two potentially problematic things.
The range for acceleration values was set to -4 to 4. Values higher than this would be truncated by the motion chip. For some reason though, many people seemed to find that they needed values around four for clash detection to work well for them. Values around 3.9 were quite common for some reason. To me, that meant that the algorithm wasn’t really working as designed. Also, it gets a little wonky, because the truncation is cube-shaped, so if you hold your saber at a 45 degree angle, then the maximum value would be \sqrt{3 * 4^2} = 6.9 and having an algorithm that works differently depending on the angle didn’t seem like a …
These defines can be used to dial in clash detection methods for OS7, there is a new section added for “Additional Clash Adjustments” to allow further tweaking in your config.
Khufu01:
I have found an issue
This update also fixes this bug.
You’ll need to refresh the page to get the new scripts and options.
1 Like