The dream of clash locations is crushed

By the way, in terms of small low-cost CPUs, I can recommend the $5 Raspberry Pico or other designs based on the RP2040. Lots of power for its cost: 133 MHz 32-bit ARM-M0+ dual core, and a 500ks/s 12-bit ADC. Enough for quite a lot of sound signal processing.

I think the ideal would be for all the components to fit on or behind a pogo pin pcb. I think the RP2040 might be too big for that, especially since it needs an external flash chip.

How big are the I2S input chips?

Sound ADC to I2S chips are not big. The AK5720VT, a popular model ar the moment, is a 16-pin TSSOP package. The 24 bits accuracy is nice.

That’s still fairly large, but it might fit.
Ideal would be something like a 3x3mm qfn.

1 Like

The sensor needs to fit as well. Piezo disks for beepers come no smaller than 9-10mm in diameter. Strip-shaped piezo film bend sensors are more narrow but longer. Also, those cost 10x more, around $10. A standard $1 microphone element might also serve as a vibration detector. I should try that.

Yeah, I was thinking a 10mm piezo disk, although I’m uncertain about how to physically mount it.
Apparently capacitors also exhibit piezo-elecric properties if we needed to really tiny.

I come more from an econometrics background, so I’m more used to making models and then trying to fit data. If I had to think about this, I would assume that on a clash the whole saber would pivot around the clash point. Thus, if you can estimate a way your saber is pivoting, you could find a radius.
If you can program to hit the base of the blade, and then the tip, you could have two points and then estimate the fulcrum for other cases by interpolating. I understand that you really don’t need that much precision, just six to ten “clash segments” would be good enough.
Is there an “easy” way to record raw accelerometer data? If so, I could try to design some models.

Serial Monitor, mon clash and/or mon gyro may be helpful?
You might need to #define ENABLE_DEVELOPER_COMMANDS, in your config and/or comment out #define DISABLE_DIAGNOSTIC_COMMANDS
I can’t remember.

No, the monitor commands print out data far too slowly to be useful here.
The clash recorder is the right way to do this. It even lights up a random spot on the blade, asks you to hit it, then asks if you wish to accept the clash before moving on to a different spot. The spot is recorded in the results.

To make it even simpler, I have attached ~150 clashes that I recorded with the clash recorder.
clash_data.zip (626.4 KB)

The accelerometers I have seen output a few hundred samples per second at most, and the raw data is quite noisy. While there ought to be some correlation between hit position and the relation between angular and positional acceleration, I reckon it would also be heavily influenced by how tightly you are gripping the saber and the strength of the impulse from what you are hitting (or what’s hitting you).
I won’t say that it’s impossible, because I have seen some amazing things done by signal processing algorithms, but determining the clash location from somewhat sparsely sampled accelerometer data alone is a really hairy problem.
High speed sampling of a vibration sensor in the hilt might improve the data considerably. By itself, that is also not enough for clash location on a thin wall blade, but perhaps they might do the trick together?

1 Like

ProffieOS 6.x runs gyro/accel at 1600 samples per second.

1600 Hz is better. Still too sparse to capture any details on the impulse part of the clash event, which happens over as little as one or two milliseconds, but enough to determine the angular and translational momentum immediately before and after the clash, and possibly enough to make out the approximate location of the impulse. Noise could be the limiting factor here.

Hits by a swung blade (attacks) and hits on a stationary blade (blocks) will be fundamentally different in nature in terms of accelerometer data, and straight hits that make a clean bounce will have different characteristics than glancing hits that are partially blocked and partially deflected. A projection to the right coordinate system could make glancing hits much easier to analyze, possibly even transform them into weaker straight hits if we do it right. We do need data for hits with another blade, attacks as well as blocks, both with someone holding a tight grip on a properly weighted hilt.

Unfortunately, solid dynamics is not exactly my strongest subject, so I’m not the right person to take a swing at this. (Pun totally intended – I have no shame.) It does sound like a reasonably tractable problem, but I really don’t know enough to make that call.

1 Like

One of the classic blunders, like getting involved in a land war in Asia!

In a previous life I was a process engineer in a warehouse, and had a machine learning project I was working on. Made the same mistake, accidentally used the whole data set for training and for validation. Results weren’t as good once I split it up. XD Good catch recognizing that it was too good to be true. Sometimes takes us a long time to catch errors that give us what we want.

1 Like

I’m actually surprised that modern machine learning frameworks don’t have ways to automatically guard against over-fitting. It’s such a common thing…

1 Like