Help with Adafruit ICM-20649 IMU Orientation During Frisbee Throw

[FGD]

Hi everyone,

I’m using the Adafruit ICM-20649 IMU attached to a frisbee, and I'm trying to capture the orientation data during the throw.

In the attached data, you can see a throw with a 30-degree roll angle. The beginning of the throw is calculated correctly, but the yellow-highlighted area shows the part where the data becomes messed up and unusable. This data primarily represents the throw, with just a slight flight phase at the end.

Currently, I’m using a complementary filter, but it’s not providing the accuracy I need during the throw period.

Is there a recommended solution or method to obtain accurate orientation data throughout the throw? Any insights or suggestions would be greatly appreciated!

Thank you!

 

[berkeman]

I’m using the Adafruit ICM-20649 IMU attached to a frisbee, and I'm trying to capture the orientation data during the throw.

Is this a continuation of your previous thread on this project?

I have an IMU that includes an accelerometer and a gyroscope. The IMU is moving through 3D space while rotating around it's z axis(yaw).

 

[FGD]

Is this a continuation of your previous thread on this project?

It is the same project but different problem.

 

[Baluncore]

Is there a recommended solution or method to obtain accurate orientation data throughout the throw? Any insights or suggestions would be greatly appreciated!

1. Do you know if it is the sensor, the algorithm, or the processor, that is falling over?

2. Are you using 3D vectors, or quaternions, for the orientation computations?

3. Have you placed the module at an angle, on an angled turntable, then gradually increased the speed ? Is there an RPM where it falls over?

4. Have you considered flying two identical systems on the same Frisbee? They would have different input data, but should deliver the same orientation result. Will they both fall over at the same time?

5. Is the computation choking the processor? Do you begin a new computation cycle every real-time heartbeat, or do you chain the computations together in irregular time?
Software should clear a 'busy' flag at the end of the computation. Does it check the 'busy' flag, before setting the 'busy' flag at the start of the next computation cycle?

6. How much RTOS is there, stealing computation time from the processor?

7. Does your software monitor data stack overflow?

 

[pbuk]

A frisbee rotates at about 1000 rpm or 6000 degrees per second and in a throw lasting, say, 0.1s accelerates at 60,000 degrees per second per second. Do you think that your 15 USD over-the-counter sensor is capable of operating effectively in these conditions, even assuming (i) an ideal location and mounting and (ii) timely processing and communication of data?

 

[pbuk]

7. Does your software monitor data stack overflow?

In this environment almost all software and devices use ring buffers rather than stacks, but the effect is similar.

 

[Vanadium 50]

Do you think that your 15 USD over-the-counter sensor is capable of operating effectively in these conditions

I don't see why not. This is 30 g or so. Surely one could find one that works in this range. I would not, however, use this sensor, which claims to max out at 30 g. What happens if the frisbee experiences an acceleration of 31 g?

It's pretty clear from the four threads on this project there was never a pencil and paper design going into sensor specs, data rates, impact of the frisbee's flight and so on. And yes, this should have been the first step. Slapping something together based on the parts you have on hand, or have heard about from your friends usually doesn't work.

But I think the OP is just a kid, and this is a valuable lesson. Maybe even more valuable that if this worked as expected: skip the pencil and paper step at your own peril.

 

[Baluncore]

A frisbee rotates at about 1000 rpm or 6000 degrees per second and ...

From: https://invensense.tdk.com/download-pdf/icm-20649-data-sheet/
"With an extended FSR range of ±4000 dps for gyroscope and .... "

One problem will be that; 6000 dps > 4000 dps.
That needs further investigation.

 

[pbuk]

I don't see why not.

Then, like the OP (but unlike @Baluncore and I), you haven't read the specs on the device.

@FGD I recommend that you abandon the idea of measurement during the throw - the angular acceleration (and angular jerk) is likely to defeat any sensor that is available to the public, and in any case all that matters is the conditions on and after release (in particular the imparting of wobble is a chaotic effect and can only be measured during flight rather than reliably predicted from throw data). I suspect that you will have to wait a short time after release for the sensor(s) to stabilise with the accelerations of the throw removed: I believe this is what the TechDisc does.

It's also probably worth mentioning that disc golf might have been invented by Physics students at UCSB in the 60s and remains a popular sport among e.g. NASA staff: a lot of clever people with good resources have looked at this before and it would be a good idea to see what they have done rather than reinvent the, er, wheel.