I have an Adafruit BNO055 IMU and am using the VECTOR_LINEARACCEL parameter so I can detect acceleration above or below 0m/s2.
I am doing free-fall experiments using magnets and I want to retain the polarity of the z-axis. Basically if the z-axis shows acceleration above 0m/s2 I want the acceleration vector magnitude to be positive which indicates the object is accelerating faster than gravity while if the z-axis shows acceleration below 0m/s2 I want the acceleration vector magnitude to be negative to show it is accelerating slower than gravity.
I have done tests with the Arduino Nano 33 BLE Rev2 and got surprising results when a normal magnet moves in the direction of north pole to south pole but it is flaky in that it often seems like the Z-axis g-force returned is negative when it should be positive or vice versa in that Arduino's builtin IMU, hence my decision to use the Adafruit BNO055.
I asked ChatGPT and it gave the following code, is this accurate:
#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BNO055.h>
Adafruit_BNO055 bno = Adafruit_BNO055(55);
void setup() {
Serial.begin(115200);
if (!bno.begin()) {
Serial.print("No BNO055 detected. Check wiring or I2C address.");
while (1);
}
// Optional: Set the sensor to calibration mode, if desired
bno.setExtCrystalUse(true);
delay(1000);
}
void loop() {
// Obtain linear acceleration (removes effects of gravity)
imu::Vector<3> linAccel = bno.getVector(Adafruit_BNO055::VECTOR_LINEARACCEL);
// Get x, y, z components of the acceleration
float x = linAccel.x();
float y = linAccel.y();
float z = linAccel.z();
// Calculate the magnitude of the x and y components only
float xy_magnitude = sqrt((x * x) + (y * y));
// Combine with the z component, preserving its sign
float overallAccelWithZPolarity = sqrt(xy_magnitude * xy_magnitude + z * z);
// Print the results
Serial.print("X: ");
Serial.print(x);
Serial.print(" Y: ");
Serial.print(y);
Serial.print(" Z: ");
Serial.print(z);
Serial.print(" | Overall Acceleration Magnitude with Z Polarity: ");
Serial.println(overallAccelWithZPolarity * (z < 0 ? -1 : 1));
delay(100); // Delay between readings
}
In free fall, the acceleration due to gravity cannot be measured, as gravity exerts the same force on all parts of the sensor. If the accelerometer is properly calibrated, all axes will report approximately zero acceleration during free fall.
However, during free fall the accelerometer will continue to measure acceleration due to other forces applied to it, such as acceleration due to air resistance.
I discovered with the magnet free fall object that it accelerated faster than gravity when moving north pole to south pole and thus would have an acceleration greater than 9.8m/s2 using VECTOR_ACCELEROMETER or greater than 0m/s2 using VECTOR_LINEARACCEL in the BNO055 IMU.
I am just trying to figure out if ChatGPT is accurate with its multiply the acceleration vector by -1 if the z-axis reports an acceleration rate of less than 0m/s2. Can't always just trust ChatGPT.
The "VECTOR_LINEARACCEL" correction assumes that the sensor is supported by something, and is intended for nearly level flight or rovers, boats, etc. It does not work in free fall.
I understand that VECTOR_LINEARACCEL is for acceleration detected by the IMU other than gravity.
When using the Arduino Nano 33 BLE Rev2, its IMU reported acceleration including gravity and reported acceleration in g-forces that when converted to meters/second2 were around 11.25 m/s2 when dropping a magnet in the north pole to south pole direction.
When dropping a control, NSSN, SNNS, or a magnet in the direction of south pole to north pole its g-forces was near zero and therefore when converted was around 9.8m/s2.
Np, just trying to write a physics paper and wanted to make sure I am reporting the data correctly.
I'd use the Arduino's IMU data but it would be like 4m/s2, 6m/s2m, 11m/s2, 8m/s2 and seemed to be flipping the g-force value from positive to negative or vice versa early on in the data recording.
Near the end of each free-fall trial the data was more uniform with negative to positive flipping or vice versa, not happening.
Then you should understand that the misnamed "linear acceleration" is what remains from the sensor-reported total acceleration after subtracting the acceleration due the reaction force opposing gravity, which is always assumed to be 1 g.
That works to some extent for an accelerometer sitting flat on a bench, reporting 1 g along a vertical axis (the acceleration due to the bench "normal force"), but of course does not work for an accelerometer in anything remotely resembling free fall.
That agrees with my data on my Control, Control AUD (Arduino Upside Down), NSSN, SNNS, SNSN, SNSN AUD. When I converted the g-force to meters/second2 it was close to 9.8
For NSNS and NSNS AUD something more than normal free fall acceleration is occurring. My hunch is inertia reduction. I got the idea from Boyd Bushman a Lockheed Senior Scientist and the Brazillian team of Elio Porcelli and Victo Filho (who I got the idea to use an accelerometer from rather than a video camera).
You can look at my preliminary line chart that shows for the most part the acceleration rate is close to 9.8m/s2 except for NSNS and NSNS AUD where the acceleration rate steadily increases until the object collides with the ground.
I guess where I am unsure is if the z-axis starts out -1g then crosses over to (+) that means it is accelerating at a rate greater than gravity same as if I had the Arduino upside down and it starts out +1g then crosses over to (-) . That is my hunch but I was not certain.
My hunch is inertia is being reduced not gravity increased because I placed the NSNS, NSSN, SNNS, and SNSN magnet objects on a balance and they were almost exactly the same mass.
I suggest to not use "linear acceleration" and instead, measure the total actual acceleration.
Contrary to popular understanding, consumer grade accelerometers do not respond directly to the force of gravity, rather to forces applied to the accelerometer housing.