Add support for the adxl345 accelerometer for the BTT EBB42 V1.2 toolhead

[rondlh]

Add support for the adxl345 accelerometer for the BTT EBB42 V1.2 toolhead

Requirements

BTT EBB42 V1.2 toolhead

Benefits

The accelerometer can be used for input shaping.

Configurations

Just enable ACCELEROMETER_ADXL345 in Configuration_adv.h
Note: This is new, and currently there is no code to process the accelerometer data.

Related Issues

#27588

[thinkyhead]

We will need to explore the methods used for sampling, motion patterns that are analyzed, and the conversion of the collected data into settings to apply to our existing input shaping features. This is a challenging frontier for the casual developer, but I believe we can tackle it!

[tombrazier]

This is going to get a lot of people excited I think.

After a very quick quick look at the code, it looks to me like a wrapping of an SPI interface for the adxl345. Have I read that correctly?

Using the accelerometer to measure resonant frequencies can be done with a frequency sweep by printing the same pattern used here. Whilst this is occurring, it will be necessary to poll the appropriate ADXL345::readMeasurement[XYZ]() function at high frequency and record the peak values for each frequency. I am vaguely imagining maintaining a "peak" value which decays by some factor before every sample and then is boosted if the sample value is higher than the decaying peak. i.e. something like peak = MAX(sample, peak * 0.5).

[thinkyhead]

Here's a sample of arduinoFFT code from the chatbot that should help our cause…

#include <SPI.h>
#include <arduinoFFT.h>

// Constants
#define FFT_SIZE 128          // Size of FFT (power of 2)
#define SAMPLING_FREQUENCY 1000 // Sampling frequency in Hz
#define ADXL_CS_PIN 10         // Chip Select pin for ADXL

// Globals
double vReal[FFT_SIZE];
double vImag[FFT_SIZE];
arduinoFFT FFT = arduinoFFT(vReal, vImag, FFT_SIZE, SAMPLING_FREQUENCY);

void setup() {
  Serial.begin(115200);
  pinMode(ADXL_CS_PIN, OUTPUT);
  SPI.begin();

  // ADXL initialization code here
}

void loop() {
  // Collect data
  for (int i = 0; i < FFT_SIZE; i++) {
    vReal[i] = readADXL_X(); // Replace with function to read ADXL X-axis acceleration
    vImag[i] = 0;            // Imaginary part is always 0
    delayMicroseconds(1000000 / SAMPLING_FREQUENCY);
  }

  // Perform FFT
  FFT.Windowing(FFT_WIN_TYP_HAMMING, FFT_FORWARD); // Apply a window function
  FFT.Compute(FFT_FORWARD);                        // Compute FFT
  FFT.ComplexToMagnitude();                        // Compute magnitude

  // Find dominant frequency
  double peakFrequency = FFT.MajorPeak();
  Serial.print("Peak Frequency: ");
  Serial.println(peakFrequency, 2);

  delay(1000); // Delay for visualization
}

// Example function to read X-axis acceleration
double readADXL_X() {
  digitalWrite(ADXL_CS_PIN, LOW);
  SPI.transfer(0x32 | 0x80); // Send read command for X-axis
  uint8_t lsb = SPI.transfer(0x00);
  uint8_t msb = SPI.transfer(0x00);
  digitalWrite(ADXL_CS_PIN, HIGH);
  int16_t raw = (msb << 8) | lsb;
  return raw * 0.004; // Convert to g's (adjust based on ADXL scale)
}

[tombrazier]

Oh that makes tons of sense. Then you don't even have to know what the input frequency is when measuring the output.

[thinkyhead]

Yep. We just need enough samples at a regular interval to get some complete waves. There's probably some dynamic methods as well, such as counting up frequency peaks in buckets and then narrowing down on each peak.

[robherc]

So are we trying to FFT the "ringing" from an abrupt step-input, or should we feed in sinusoidal motion of known peak distance/acceleration, in a frequency sweep, and look for the induced over/undershoots of the target points?

I agree that sharp-input ringing could potentially give a "quicker output" through fft, and may give better accuracy for resonance decay-rates, but I'd expect the second method to give better settings for exactly what amount of over/undershoot to expect, and thus how to compensate best for the initial inaccuracy caused by axis resonance.

Ok, so I guess both would give different bits of information that would benefit the calibrated settings we could generate from the test.

[rondlh]

This is going to get a lot of people excited I think.

After a very quick quick look at the code, it looks to me like a wrapping of an SPI interface for the adxl345. Have I read that correctly?

Using the accelerometer to measure resonant frequencies can be done with a frequency sweep by printing the same pattern used here. Whilst this is occurring, it will be necessary to poll the appropriate ADXL345::readMeasurement[XYZ]() function at high frequency and record the peak values for each frequency. I am vaguely imagining maintaining a "peak" value which decays by some factor before every sample and then is boosted if the sample value is higher than the decaying peak. i.e. something like peak = MAX(sample, peak * 0.5).

Thanks for the feedback. I will have a look into this.
The ADXL345 is a SPI/i2c device, but the users don't care about that, they just want the data from the sensor. That's what the code in the PR does, just give you the acceleration data. To make this useful the data needs to be interpreted and the code might need to be updated to meet the requirements. You are talking about "high frequency", what numbers are we talking about?

Yep. We just need enough samples at a regular interval to get some complete waves.
@thinkyhead Any suggestion for which interval to use?

If we don't care about the real time aspect of the data, then the sensor with its 32 level FIFO is quite powerful.
The sensor supports up to a sample rates of 3200Hz, but is quite noisy at that speed. Typically you want to sample at more than double the frequency you are trying to measure, 3-4 times is even better. I expect that we are dealing with quite low frequencies, below 50Hz, so a sample frequency of 100Hz or 200Hz would be suitable.
I will do some experiments on it when I find the time.

[robherc]

If we don't care about the real time aspect of the data, then the sensor with its 32 level FIFO is quite powerful. The sensor supports up to a sample rates of 3200Hz, but is quite noisy at that speed. Typically you want to sample at more than double the frequency you are trying to measure, 3-4 times is even better. I expect that we are dealing with quite low frequencies, below 50Hz, so a sample frequency of 100Hz or 200Hz would be suitable. I will do some experiments on it when I find the time.

FWIW, Nyquist says we need to sample at a minimum of 5x the frequency of the fastest wave you want to capture.

[rondlh]

FWIW, Nyquist says we need to sample at a minimum of 5x the frequency of the fastest wave you want to capture.

@robherc
Back to school.... interesting that you know Nyquist, but that you also misquote him so boldly, Nyquist says you need to sample faster than twice the highest frequency you are interested in. More is better of course, but you do not need 5x.

[robherc]

Nyquist says you need to sample faster than twice the highest frequency you are interested in. More is better of course, but you do not need 5x.

May want to plot that on a sine wave. At 2x frequency, a sine wave can be read at only zero crossings, so the wave would be 100% entirely missed in all readings.

[rondlh]

Nyquist says you need to sample faster than twice the highest frequency you are interested in. More is better of course, but you do not need 5x.

May want to plot that on a sine wave. At 2x frequency, a sine wave can be read at only zero crossings, so the wave would be 100% entirely missed in all readings.

The key word you missed here is "faster".

[robherc]

They key word you missed here is "faster".

I'm not interested in fighting with you here...was just trying to help avoid potentially painful "learning experiences" along the path to a working solution.

What I do know for certain is that 5x sampling is the minimum sample-rate to extract enough data from a single wave to fairly reliably determine both its frequency AND its amplitude.
Both can still be determined with fewer samples per wave, to one extent or another, but one would be stuck having to rely on samples from SEVERAL waves, pieced together to dig out all the needed data &/or rely on "luck" to happen to catch the waveform at points that give enough data for a close approximation.

So I may have worded it poorly before, but the thought I was trying to convey was "If we sample at 5x the highest frequency of interest, we can save some added effort in the processing, and enjoy increased reliability of our readings."

[tombrazier]

I think we're probably not looking higher than 100Hz. Sampling at 500Hz would both be very possible and also hopefully give good data. One factor in choosing sampling rate is, I am slightly guessing, noise. Can't claim to be an expert on Nyquist but I vaguely think the faster than 2x thing might not take noise into account.

[rondlh]

I think we're probably not looking higher than 100Hz. Sampling at 500Hz would both be very possible and also hopefully give good data. One factor in choosing sampling rate is, I am slightly guessing, noise. Can't claim to be an expert on Nyquist but I vaguely think the faster than 2x thing might not take noise into account.

Right, but the faster the sample rate, the more noisy the data will be. Also the amount of data will need to be considered, as the data needs to be stored and processed. Probably we can learn quite a bit from systems that already use an accelerometer.

[tombrazier]

Probably we can learn quite a bit from systems that already use an accelerometer.

My default mode is to reinvent wheels. One of these days I am going to come up with The Wheel 2.0 and astound everyone. But you're right, it would be a lot quicker and easier to crib off others stand on the shoulders of giants.

[rondlh]

Probably we can learn quite a bit from systems that already use an accelerometer.

My default mode is to reinvent wheels. One of these days I am going to come up with The Wheel 2.0 and astound everyone. But you're right, it would be a lot quicker and easier to crib off others stand on the shoulders of giants.

For Wheel 2.0 could you remove Pi from the calculations, make it an even 3 please? Much easier to remember and the math would be much simpler.