Actively controlled rocket not flying straight

[cls]

A good launch detect algorithm probably needs a ring buffer with a moving cursor to avoid losing significant acceleration data.

Yeah, that's how I'd do it, too.

I should have been more specific:

For the purpose of eliminating bias error from accelerometer drift, ignore the data before the moment of launch plus 1 or 2 seconds, start integration there and through the flight.

For post flight analysis, present all the raw data to the user (program).

But all this is implementation details, exercise for the OP.

 

[Nv7]

3G Max Accel value is too low. Remember recommended TTW is 5:1 which means 5G acc.
Setup Accel for over 10G and fly again.
I use the old MPU6050 set for 16G and get good data for Acc and integrated to Vel & Alt.


The differentiated Baro to Accel looks kinda right, It is up during motor burn and down during coast and near level during chute descent.
However, compare to the Real Accel curve and the Baro deduced accel is way TOO SMOOTH due to the filtering.
Specifically, look at the Accel values during coast. The Accel plot in post #133 is correct shape. The Baro derived Accel is NOT the correct shape and actually worthless.

If your accel curve doesn't closely resemble your motor's published thrust curve then you're doing something wrong. In your case, your accel isn't registering high enough... for rocketry use, anything below 16G is worthless, 32G is better, and for high-power you want 100G or more.

The BNO055 only supports 4Gs (and 1 is taken up by gravity) in the algorithm mode and we tried using Madgwick filters and stuff but were not able to get any reasonably accurate orientation results using just gyro data.

 

[rocket_troy]

The BNO055 only supports 4Gs (and 1 is taken up by gravity) in the algorithm mode and we tried using Madgwick filters and stuff but were not able to get any reasonably accurate orientation results using just gyro data.

Isn't the BNO055 programmable to +-16g?

TP

 

[waltr]

Isn't the BNO055 programmable to +-16g?

TP

Yes it does. The Default is +-4G but can be set to 2, 4, 8, 16G ranges as per the data sheet.

As to data pre-launch- I like having at least a few seconds of pre-launch data.
I use the data as Calibration and/or Sanity checking that the sensor data looks ok.

Also, Did the OP Calibrate the Sensors? Accel can be done in the Lab and a Cal table created.
Gyro Data typically needs an 'offset' cal just before it's real data is needed since it has long term drift. The few seconds of pre-launch data is perfect.

Magwick algorithum does NOT work properly for rockets. It assumse Earth Based and uses the Accelerometer to reference Earth which dissappears once the rocket leaves the pad.

This has been discussed many times in the forum. Search and read.

 

[Nv7]

Yes it does. The Default is +-4G but can be set to 2, 4, 8, 16G ranges as per the data sheet.

As to data pre-launch- I like having at least a few seconds of pre-launch data.
I use the data as Calibration and/or Sanity checking that the sensor data looks ok.

Also, Did the OP Calibrate the Sensors? Accel can be done in the Lab and a Cal table created.
Gyro Data typically needs an 'offset' cal just before it's real data is needed since it has long term drift. The few seconds of pre-launch data is perfect.

Magwick algorithum does NOT work properly for rockets. It assumse Earth Based and uses the Accelerometer to reference Earth which dissappears once the rocket leaves the pad.

This has been discussed many times in the forum. Search and read.

I'm using the BNO055 builtin sensor fusion, which only supports 4G. It doesn't require sensor calibration, it handles all that kind of stuff.

 

[waltr]

I'm using the BNO055 builtin sensor fusion, which only supports 4G. It doesn't require sensor calibration, it handles all that kind of stuff.

That would be the problem......
Not high enough Accel range and does STUFF for Robots and Ground based vehicles NOT Rockets.

 

[Nv7]

That would be the problem......
Not high enough Accel range and does STUFF for Robots and Ground based vehicles NOT Rockets.

Do you know what algorithms we could use to get rocket orientation using the raw degree per second data? Couldn't figure it out so thats why we are using BNO055, its orientation data seems very accurate throughout flight too

 

[rocket_troy]

Do you know what algorithms we could use to get rocket orientation using the raw degree per second data? Couldn't figure it out so thats why we are using BNO055, its orientation data seems very accurate throughout flight too

IIRC, the BNO055 is a 9axis sensor meaning it has the potential for 3 axis magnetometer redundancy I'd imagine for "absolute orientation" sanity checking given that magnetic interference is dealt with.

We've had good success using a MTi-7 as an INS in rocket flight, although that's not quite in the same "low-end solution" class as the BNO055 and utilises GNSS data for augmentation.

TP

 

[Nv7]

I exported the data from the sim into Excel and put it with the original flight data, here are the graphs:


Do you think the discrepancy in the start in this is caused by issues with air pressure, an actually different flight path, or something else? Since we are planning on doing this based on altitude I worry that this will cause some issues.

This actually looks really good, its basically the same for a lot of the flight after burnout

Definitely need to make the Kalman filter for velocity do more filtering... Any ideas on how to get better velocity data?

 

[rocket_troy]

Do you think the discrepancy in the start in this is caused by issues with air pressure, an actually different flight path, or something else? Since we are planning on doing this based on altitude I worry that this will cause some issues.

With the roughness of the baro plot, it looks as though there could be some kind of turbulent venturi effect happening with the port(s)? Dunno...

TP

 

[waltr]

Yes, I agree that the Baro alt data looks like an issue with the vent port. Most error at highest velocity.
What do the Vent ports look like? They need to be just large enough and not too large. Also best if three ports spaced equally around the circumference of the payload tube.

As has been posted---Velocity from Baro (Alt) data is done with differentiation which ADDS NOISE. Filtering causes delay and abnormal smoothing so not that good. Improvement can be obtain with a carefully TUNED Kalman filter.
Better to use Accel data which is integrated to obtain Velocity.

Angles can be calculated by correcting Gyro data (offset error) and then integrating to get the change of angle which is added to the 'starting' (or previous angle).

While experimenting log All the RAW Data from the Baro (Alt), Accel, Gyro and Mag. Then you can experiment with calculations in Excel or a custom program. Try obtaining the same parameter (say Velocity and Alt) using different sensors and math methods.

 

[cls]

...and in the end, if you really are flying for TARC, you need to make one of the allowed commercial altimeters read the target altitude.

They will not accept results from your altimeter with your unknown and broken software, or the output of a simulation, or whatever.

 

[Nv7]

...and in the end, if you really are flying for TARC, you need to make one of the allowed commercial altimeters read the target altitude.

They will not accept results from your altimeter with your unknown and broken software, or the output of a simulation, or whatever.

Yeah we will fly with P-Nut to read the altitude, we just are using this for the active control

 

[Nv7]

Yes, I agree that the Baro alt data looks like an issue with the vent port. Most error at highest velocity.
What do the Vent ports look like? They need to be just large enough and not too large. Also best if three ports spaced equally around the circumference of the payload tube.

As has been posted---Velocity from Baro (Alt) data is done with differentiation which ADDS NOISE. Filtering causes delay and abnormal smoothing so not that good. Improvement can be obtain with a carefully TUNED Kalman filter.
Better to use Accel data which is integrated to obtain Velocity.

Angles can be calculated by correcting Gyro data (offset error) and then integrating to get the change of angle which is added to the 'starting' (or previous angle).

While experimenting log All the RAW Data from the Baro (Alt), Accel, Gyro and Mag. Then you can experiment with calculations in Excel or a custom program. Try obtaining the same parameter (say Velocity and Alt) using different sensors and math methods.

We found that simple integration with the gyro data got inaccurate extremely quickly, especially in high vibration environments like a rocket. Can't get velocity from accel with current range unfortunately. We have all the raw data, sent it earlier in this forum too

I used a thumbtack to make 3 little holes for venting, I'll make those bigger.

 

[waltr]

Did you Calibrate the Gyros? This is typically just a Offset error/correction based on averaged values just before launch. I have gotten this to work well on an old MPU6050.

Search for recommend Baro ebay Vent hole sizes. These vary with bay volume.

You need to select an Accel range that allows measuring the highest acceleration of the rocket. Else there is really no reason to have the Accel.

Being the "auto calculations" fix the Accel the 4G also means these calculations are for an 'Earth' Base vehicle making them Useless for a Rocket. Disable this and Log Raw Values.

 

[Nv7]

We've been trying to qualify for the past few weeks but unfortunately that didn't work out, but got some launches of the actively controlled rocket in today! (0 degree tilt, 2 degree tilt)

They did not fly straight at all, I suspect this is because the fins can move around a degree or two within the payload because of the flexibility of the cardboard and the fact that they slide in and out. Our NAR observer for quals was telling us about how 3d printed rockets can improve consistency, I'm thinking we should 3d print the payload with permanent servo mounts that would be much more solid. Any thoughts on this? Any other reasons it didn't fly straight for the 0deg one?

I've attached the flight data below but its not very useful

 

[waltr]

Those flights look pretty good. I will look at the data files (just geeky that way).

Yes, 3D printing is what the successful controlled rockets have. A 3D printer bay insert holding all the mechanical parts plus electronics should work very well.

Check this thread for what can be done and some hints.
https://www.rocketryforum.com/threads/i-could-use-just-a-little-guidance.122042/

 

[diyaerospace]

The spiral could be caused by misaligned fins. How are you aligning them? Do you have pictures of them before flight?

 

[Nv7]

Those flights look pretty good. I will look at the data files (just geeky that way).

Yes, 3D printing is what the successful controlled rockets have. A 3D printer bay insert holding all the mechanical parts plus electronics should work very well.

Check this thread for what can be done and some hints.
https://www.rocketryforum.com/threads/i-could-use-just-a-little-guidance.122042/

Right now there is a 3d printed bay, but I believe the issue is that the bay can turn +/- 1 degree inside of the cardboard body tube, causing issues. My solution would be to 3-d print the entire payload

 

[waltr]

Two screws through the BT into the 3D printed frame would keep it from moving.
After drilling the holes harden the cardboard BT with Thin CA glue. Just a drop that wicks into the fibers.

Do you have data on what the Control system commanded of the servos?
This would be handy to correlate control to actual.

Looking at your data.
What are the sensor axis orientations? Which axis is up? Looks like z.
What are the Units?? Accel = m/s? Gyro = degrees/s?

What is the "Time" measurement? msec or usec?

The Velocity data does not look good. It oscillates going to Zero 12 times before burn-out. It should be a steady increase while motor burning, decrease to Zero at Apogee. Then become negative during descent (this can not be calculated from Accel). Descent velocity should use Alt data.

Is the Accel data raw from sensor or has Earth's gravity of 9.81m/s/s been subtracted?
I can not tell since first Accel data point = 29.18.

Are the sensor data values calibrated??

 

[Nv7]

Two screws through the BT into the 3D printed frame would keep it from moving.
After drilling the holes harden the cardboard BT with Thin CA glue. Just a drop that wicks into the fibers.

Do you have data on what the Control system commanded of the servos?
This would be handy to correlate control to actual.

Looking at your data.
What are the sensor axis orientations? Which axis is up? Looks like z.
What are the Units?? Accel = m/s? Gyro = degrees/s?

What is the "Time" measurement? msec or usec?

The Velocity data does not look good. It oscillates going to Zero 12 times before burn-out. It should be a steady increase while motor burning, decrease to Zero at Apogee. Then become negative during descent (this can not be calculated from Accel). Descent velocity should use Alt data.

Is the Accel data raw from sensor or has Earth's gravity of 9.81m/s/s been subtracted?
I can not tell since first Accel data point = 29.18.

Are the sensor data values calibrated??

Velocity is calculated with derivative of altitude which is pretty bad, but right now I'm not using it so I haven't worked on improving it

Accel = m/s^2, altitude = m, gyro = absolute orientation (degrees)

control system not doing anything, trying to get some data on the response of the rocket to different fin angles

Unfortunately, these flights did not provide any useful data since they did not fly straight at all, any ideas why this is happening?

 

[waltr]

Unfortunately, these flights did not provide any useful data since they did not fly straight at all, any ideas why this is happening?

What diyaerospace said:

The spiral could be caused by misaligned fins. How are you aligning them? Do you have pictures of them before flight?

Also, air speed is required for fins to provide stability. Is the air speed high enough? >12m/s off the rail?
If max accel is 29m/s/s then this is barely a 3:1 TTW ratio which is an absolute minimum for a safe launch. Most RSO's prefer a 5:1 TTW.
It seems you are having the flight computer do calculations which are then logged.
To start it would be better to log RAW sensor data then in Post flight do the calculations including Sensor calibration.
Advantage is if a calc is wrong you can easily redo the calc since you have the raw data to work with.

There is a lot of information in your data. The hard part is extracting the rockets motions from this data.


Example of the Accel data (during motor burn and coast).
az is motor thrust. It is 29m/s/s for about 1 sec (burn-out) then goes negative. The negative value is due to the rockets Drag.
For a perfectly straight flight the Ay & Ax values should be near zero. However, these do not. ay becomes large near burn-out then goes negative before settling to zero.
ax does some non-zero also. These are telling you the rocket was forced sideways, could be fins or even wind or slop in the control fins.
Both data logs show the same ay spike at burn-out. This could be the control module shifting inside the tube. In the 0deg data gx starts moving at this same time.

Same time period of the Rotation:

First, I would not limit this to 0-360 degrees (gx) but allow rotation values to goe as high as needed. Note the discontinuity at about 5500 to 7500 msec, The curve between these point could be continuous and show a maximum rotation of 402 degrees then decreasing.
Also notice gy goes pos & neg without discontinuity but gz is limited to +180 to -180 degrees. Why is each axis different?
Just saw something very ODD, the gx and gz values start with pretty high values (194 & 87). These should be ZERO since the rocket is still on the rail and has barely moved.
Now it looks like you offset gx by 180 degrees and offset gz by 90 degrees offset. Why?

At about 1 sec the rotation changed which the accel also shows something happened.

How did you obtain these values? Are you applying a Gryo Offset error correction before calculations? Gyros have long term offset drift so their offset error must be measured just before needing data (on pad just before lift-off.
Ignoring the huge offset of Gx & Gz and just looking at changes, These are the rotation of the rocket in flight. They do not seem excessive and the rocket never rotated more than once around.
I think the Z-axis is in line with the rocket, Accel Z is up/down. Guessing gz is then the rotation around the long axis of the rocket.

Hope this helps a little.
Graphs are done in Excel from your 2deg.csv file. The 0deg.csv show similar graphs.

 

[Nv7]

What diyaerospace said:


Also, air speed is required for fins to provide stability. Is the air speed high enough? >12m/s off the rail?
If max accel is 29m/s/s then this is barely a 3:1 TTW ratio which is an absolute minimum for a safe launch. Most RSO's prefer a 5:1 TTW.
It seems you are having the flight computer do calculations which are then logged.
To start it would be better to log RAW sensor data then in Post flight do the calculations including Sensor calibration.
Advantage is if a calc is wrong you can easily redo the calc since you have the raw data to work with.

There is a lot of information in your data. The hard part is extracting the rockets motions from this data.
View attachment 608665

Example of the Accel data (during motor burn and coast).
az is motor thrust. It is 29m/s/s for about 1 sec (burn-out) then goes negative. The negative value is due to the rockets Drag.
For a perfectly straight flight the Ay & Ax values should be near zero. However, these do not. ay becomes large near burn-out then goes negative before settling to zero.
ax does some non-zero also. These are telling you the rocket was forced sideways, could be fins or even wind or slop in the control fins.
Both data logs show the same ay spike at burn-out. This could be the control module shifting inside the tube. In the 0deg data gx starts moving at this same time.

Same time period of the Rotation:
View attachment 608668
First, I would not limit this to 0-360 degrees (gx) but allow rotation values to goe as high as needed. Note the discontinuity at about 5500 to 7500 msec, The curve between these point could be continuous and show a maximum rotation of 402 degrees then decreasing.
Also notice gy goes pos & neg without discontinuity but gz is limited to +180 to -180 degrees. Why is each axis different?
Just saw something very ODD, the gx and gz values start with pretty high values (194 & 87). These should be ZERO since the rocket is still on the rail and has barely moved.
Now it looks like you offset gx by 180 degrees and offset gz by 90 degrees offset. Why?

At about 1 sec the rotation changed which the accel also shows something happened.

How did you obtain these values? Are you applying a Gryo Offset error correction before calculations? Gyros have long term offset drift so their offset error must be measured just before needing data (on pad just before lift-off.
Ignoring the huge offset of Gx & Gz and just looking at changes, These are the rotation of the rocket in flight. They do not seem excessive and the rocket never rotated more than once around.
I think the Z-axis is in line with the rocket, Accel Z is up/down. Guessing gz is then the rotation around the long axis of the rocket.

Hope this helps a little.
Graphs are done in Excel from your 2deg.csv file. The 0deg.csv show similar graphs.

Thanks for the analysis! If you watch the videos you can see that the rocket turned sideways in both flights, explaining the ax/ay values. For the gyro values, those are the raw BNO055 values, I believe the algorithms within the sensor handle calibration and such.

 

[waltr]

Yes, I did see in the video the rocket turn which is a reason I looked at the data.
An exercise for you is find the times in the video of when the rocket turned then correlate this to the data.
I also when over the data so you can analyze data from next flights. Of course post your data and I (we) can also take a look.

 

[kjhambrick]

@Nv7 --

I have nothing to add to @waltr's suggestions except questions:

When I look at the z-axis acceleration in Walter's graph, the magnitude of your coast-phase drag is HUGE compared to the magnitude of the positive acceleration due to the motor thrust.

Note the blue trace:



Could this be a calibration error ?

Or is the high drag because your canards might be misaligned?

EDIT: do you have a means to lock the canards so they're absolutely straight and fly without any active control a couple times ?

This might get you a baseline for the rocket and the sensor readings ...

Please keep it coming !

Thanks !

-- kjh

 

[waltr]

I saw the z accel drag was large but also note that it did not settle to zero. Instead is settles to about -9.8m/s/s. This looks like 'Earth's gravity' was subtracted.

Even if added back the Thrust peak goes to about 40m/s/s but drag is still about -32m/s/s which is huge.
A 3" diameter rocket I fly sensors in only gets about -5m/s/s drag.

Graph is with Carnard set to 2 degree. When the Canards are set to 0 degree the Drag deaccel is -30m/s/s.

Maybe this is something processed inside the BNO055 or this is a very Draggy rocket.

 

[Spacedog49Krell]

I just came across this thread and found it interesting. I noticed you are using the BNO055. What processor are you using with the BNO055? The BNO055 does not work well with several M5 and M7 processors, ESP32 and NXP.

Another quick issue I see is your sampling speed of 120Hz. The BNO055, using their fusion algorithm, outputs data at 100Hz.

 

[waltr]

Good point Spacedog.
Actually from the data's Time sampling is about every 0.006 seconds which is 166.6Hz.
If this is true then then should be some 'repeating' values.
Yes, I do see repeated values. There are two values the same repeated every 18 samples.

This is on the BNO055.

On the Baro the repeating happens more often. Check the Data sheet, I think I read the Baro conversions are at a much lower rate.

 

[Spacedog49Krell]

Good point Spacedog.
Actually from the data's Time sampling is about every 0.006 seconds which is 166.6Hz.
If this is true then then should be some 'repeating' values.
Yes, I do see repeated values. There are two values the same repeated every 18 samples.

This is on the BNO055.

On the Baro the repeating happens more often. Check the Data sheet, I think I read the Baro conversions are at a much lower rate.

Whomever is writing the code, is utilizing the SD card internal buffer. The data packets are sent to the SD card and after every 10 packets the data is transferred to the flash cells with a flush or close command. The transfer to flash cells does take extra milliseconds of time. The short term 166Hz sample rate slows down to 120Hz average sample rate. I've been using and teaching this technique for the past 4 years. For those that think an external buffer would fix the SD wait issue, there are a number of caveats. For small data packets of <64-bits, the external buffer technique works best. For large data packets of >256-bits, both techniques take the same time. The issue is the 1-bit SPI protocol is slow. I recommend using the 4-bit SDIO protocol, but that requires high speed processors like the ESP32 or Teensy 4.X. The next best option is streaming data via the UART to an openLager data recorder.

The barometric data is recorded at 16Hz average, making the velocity column values unreliable.

Due to my work at 500-1000Hz, I don't use the BNO055. The raw gyro data should be in radians/sec, not an absolute heading in degrees.

 

[waltr]

Another good observation Spacedog.
Looked at the data times again and see periods of 23msec every 10 samples. So yes, average is about 120Hz.

There seem to be issues with the data.
I tried to integrate the Accel data to Velocity and then Altitude and this did not match the Baro altitude.
I do this with my data logging and this math does work.