Actively controlled rocket not flying straight

[Spacedog49Krell]

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.

The 23 ms also tells me that this TARC team is likely using the standard SD library with an ATmega 328 processor. Using the SdFat library will shorten the Flash wait time to 10-13 ms. Running SdFat, the SD wait time will remain steady over hours of data collection time. The SD library will steadily increase over the same time period. The millisecond time values indicate that the cpu has been running for 5-6 minutes before the rocket launches. If it is recording data to the Flash chip during that time, the SD wait time will have increased reducing the overall data sampling rate.

 

[Spacedog49Krell]

To Nv7

After analyzing your videos and the flight data from three of the flights, I have some conclusions and corrective suggests.

1. A stability ratio of 1.04 is marginal.
2. Whatever the cause for the spiraling horizontal flight, the onset is occurring close to motor burnout with a vehicle velocity >200 ft/sec.
A. Third flight, first straight flight. See chart.
1. Canards set to 0°.
2. Altitude ~869 ft.
3. Motor burnout velocity ~167 ft/sec.
4. Slowest acceleration.
5. Added weight to nose cone?
B. Fourth flight. See chart.
1. Canards set to 0°.
2. Altitude ~820 ft.
3. Motor burnout velocity ~265 ft/sec.
4. Fastest acceleration.
5. Was additional weight removed?
6. Lower altitude reading after burnout. (?)
C. Fifth flight. See chart.
1. Canards set to 2°.
2. Altitude ~662 ft.
3. Motor burnout velocity ~200 ft/sec.
4. Lower altitude reading after burnout. (?)

* 3. Small canard angle has significant drag effect.

4. Check the BNO055 operation mode. I believe you are in the M4G mode, 4G limits on the accelerometers and magnetometer readings replacing gyro data.

Corrective Suggestions

1. Set the BNO055 to IMU relative orientation mode or non-fusion ACCGYRO mode.
2. Set accelerometers to +/-16 G's.
3. Set gyros to +/-2000°/sec, raw radian output.
4. Add additional nose weight to bring stability ratio to >2.
5. Reduce the canard length.
a. Small angular changes in canards produce large drag values.
b. Sudden onset of flight deviation at MaxQ could be canard flutter or servo gear slack.
c. One canard fluttering, at natural resonance frequency, could cause flight deviation.
d. Change in shape will change the natural resonance frequency.
e. Reduction in vehicle velocity may also reduce canard flutter issues.


Keep up your work. My preliminary drag calculations suggest the canards will apply more overall drag than spin drag.

Krell

 

[Nv7]

Thank you for the excellent insights! I've been busy and the weather has been terrible for the past few weeks but we finally got a chance to launch, and it went great - Perfectly straight up, even with the fins tilted!

It didn't spin nearly as much as expected for 2 degrees and it also went pretty high although I'm not sure what the reaction time of the servos is, since it turned mid-flight instead of starting out with the angle. We'll start it out at the angle for the actual test data launches, we were just verifying it worked for this one.

We switched to a fully 3d printed payload and fin can which offers us many benefits, like perfect consistency between rockets, a much stiffer body, and a much better fit between the fin can and the body tube. The servo mount is part of the tube instead of sliding in which makes it a lot more convenient and rigid. There is much less slop overall in the system, and its only ~20g heavier than before.

I put much larger avionics bay vent holes for the 3d-printed rocket and they worked out a lot better, the curve for altitude looks just like the sims, it doesn't have that really quick sharp part and then sharp turn like before, I think its much better.

Just checking, a 3d-printed rocket is TARC legal right? You can see how it looks in the video attached.'
Everything but the nose cone on top is 3d printed, each color indicates a different piece.

Stats for today:
Altitude (P-Nut altimeter): 912ft
Flight time (hand-timing): 41.6s
Rocket mass: 533g
Motor: F51-10NT

I'm still not sure if I should get rid of the fusion mode because I don't think simple integration will get a good estimate of the angle of the rocket, and that is required for a good estimate of the vertical acceleration. Do you think it will be fine? I will definitely start collecting gyro velocity data.

I'm thinking we will do a 0deg launch, a 3deg launch, and a 6deg launch next time to try to get an idea of the response of the rocket. Do you think these are good values to test or should we do a different range?

 

[Nv7]

The 23 ms also tells me that this TARC team is likely using the standard SD library with an ATmega 328 processor. Using the SdFat library will shorten the Flash wait time to 10-13 ms. Running SdFat, the SD wait time will remain steady over hours of data collection time. The SD library will steadily increase over the same time period. The millisecond time values indicate that the cpu has been running for 5-6 minutes before the rocket launches. If it is recording data to the Flash chip during that time, the SD wait time will have increased reducing the overall data sampling rate.

Hm, we are using Arduino Nano 33 BLE, but not SdFat, just the raw flash api methods since SdFat wasn't working

 

[Spacedog49Krell]

Downloaded your CSV file. I see the improved barometric response with the larger vent holes. Further analysis will require more time.

 

[Nv7]

Compared it to the sims and it actually was great, sims predicted apogee of 904 but we got 912 so its a little higher and the sims parachute is wrong so ignore that, its hard to tell these apart for a lot of the flight!


This is super good news because this means we can use computer tools like Matlab simulink to get a very accurate representation of the flight data the rocket will be perceiving!

 

[Spacedog49Krell]

Now that your rocket is flying straight and you have good simulations, you need to give your flight computer good information. Study the data you have collected. It is telling you what you need to change and what is critical for your project. Currently, your primary onboard sensor is the BMP280. Secondary sensors are the magnetometers giving you roll, pitch, and yaw.

Using the first derivative of the BMP280 altitude data gives you velocity. The second derivative gives you acceleration. Like with integration, each derivative introduces more error. Plus, the altitude data has a time phase shift error from the venting of the payload volume through the vent holes. The first derivative looks ugly, but is recognizable and useful. This brings up how you are collecting the BMP280 data. Your main loop is based on ten iterations of collected data before you write the data to memory. The BMP280 data does not follow this set iteration or an interrupt time. The ~120Hz sample rate is within the update rate of the BMP280. I suggest you collect the current altitude data during every iteration. The BMP family of sensors operate at I2C clocks up to 3.4MHz. I regularly operate a 1MHz I2C clock and for special applications up to 3.2MHz. Most I2C sensors will operate at 1MHz clock, this is Fast Mode +. Your BNO055 could pose a problem at 1MHz, from comments people I know, and follow have said about the BNO055 IMU.

The magnetometer roll data indicated 2+ rotations during the flight. It appears the canards are countering a roll induced by the fins. At higher velocities the canards are dominate. At lower velocities the greater area of the fins is dominate.

Attached is a graph you may find interesting.

 

[NTP2]

I would like to say that most algorithms and sensors are designed for every thing BUT rockets it takes a lot more work to get stuff working in the environment that a rocket operates in.

 

[Nv7]

We had very exciting launches today, in which we completely broke 2 3d-printed rockets!

Launch 1
912ft
1:03.5
6 degree fin tilt

The rocket went up great, but because we installed a much larger parachute and the delay is much too long the egg pushed the nose cone out and fell out itself, but somehow survived a fall of 900 feet without a single crack! Unfortunately the payload tube cracked upon impact because its very thin and relies on the nose cone and egg for structural integrity. For the next launch we taped up the crack and taped the egg in.

I'm going to 3d-print a bulkhead that we can screw in above the egg so that that would bear the weight of the egg instead of the friction of the nose cone.
View attachment IMG_6272.jpg
View attachment launch1.MOV

Launch 2
536g
875ft
1:09.9
This one flew diagonally for some reason, maybe it was because of the tape, maybe the fin angle is too much? This final altitude is probably lower than it would be for straight flight. When the parachutes deployed this time, the shock cord mount on the fin can broke! We had pulled on those pretty hard while testing and they survived, plus the elastic cord should have reduced the amount of force on the shock cord a lot. I'm not sure why they broke, any ideas?

View attachment launch2.MOV

I've attached the flight data: 6deg for launch 1 and 12deg for launch 2. For some reason we lost the data after parachute deployment for flight 2, I will do more investigation into this. We're going to try to increase the strength of the broken parts, re-print it, and do some more flights to hopefully get some more consistent data.

The fin angles are not doing nearly as much as I expected. It barely spins any more between 2 degrees, 6 degrees, and 12 degrees. The altitude is also only barely reduced. I'm thinking we need to do flights at 30 degrees, 45 degrees, and 60 degrees instead.

 

[Spacedog49Krell]

The fin angles are not doing nearly as much as I expected. It barely spins any more between 2 degrees, 6 degrees, and 12 degrees. The altitude is also only barely reduced. I'm thinking we need to do flights at 30 degrees, 45 degrees, and 60 degrees instead.

As I mentioned in post #182 on Oct 15, the canards produce more drag than spin torque. In that respect they are acting like speed brakes on a jet.

Look at moving the pivot point to the middle of the canard and extend them further out into the air flow.

 

[Nv7]

As I mentioned in post #182 on Oct 15, the canards produce more drag than spin torque. In that respect they are acting like speed brakes on a jet.

Look at moving the pivot point to the middle of the canard and extend them further out into the air flow.

Ok, I will increase the length of the canard and move it a bit up (relative to the servo). I was expecting more drag though, the altitude didn't change very much even though I tripled the angle from 2 degrees to 6 (it only went 10 feet lower)

 

[Spacedog49Krell]

Research the canards of the AIM-9 Sidewinder. The prototype used a leading edge servo axis, like yours. Production units used a central axis servo connection. The trailing edge torque load of your canards could be exceeding the torque of your servo. The servos are commanded to 2, 6, & 12 degrees, but the canard's response could be less due to aerodynamic torque loads. The in-flight spin and altitude data show little change with increased canard deflection. You may need to flow high velocity air across your canards while sending commands to the servos to verify the deflection angles. I've used an air compressor and hand nozzle to flow air across fins to determine weak points.

I also came across an orientation algorithm that may be of help to you. The MadgwickAHRS algorithm utilizes accelerometer, gyro, and magnetometer data to determine flight orientation. My knowledge is strictly from the published papers. I'm ordering a 9DoF IMU to gain further experience. There are several libraries on GitHub. I've been a real skeptic of using magnetometer data for orientation, but seeing your data and another person's magnetometer data, now coupled with the Madgwick algorithm that produces a quaternion output I may have been wrong.

Parachute deployment is very stressful on vehicle components. I did a year of engineering on dragster and Land Speed Record vehicles. It was amazing the stresses they endured and the components we broke. My rocket high-speed flight computers record accelerometers railing on almost every flight for 20-80 milliseconds. The graph shows the ejection charge, parachute burrito release, and initial parachute inflation.

 

[Nv7]

Research the canards of the AIM-9 Sidewinder. The prototype used a leading edge servo axis, like yours. Production units used a central axis servo connection. The trailing edge torque load of your canards could be exceeding the torque of your servo. The servos are commanded to 2, 6, & 12 degrees, but the canard's response could be less due to aerodynamic torque loads. The in-flight spin and altitude data show little change with increased canard deflection. You may need to flow high velocity air across your canards while sending commands to the servos to verify the deflection angles. I've used an air compressor and hand nozzle to flow air across fins to determine weak points.

I also came across an orientation algorithm that may be of help to you. The MadgwickAHRS algorithm utilizes accelerometer, gyro, and magnetometer data to determine flight orientation. My knowledge is strictly from the published papers. I'm ordering a 9DoF IMU to gain further experience. There are several libraries on GitHub. I've been a real skeptic of using magnetometer data for orientation, but seeing your data and another person's magnetometer data, now coupled with the Madgwick algorithm that produces a quaternion output I may have been wrong.

Parachute deployment is very stressful on vehicle components. I did a year of engineering on dragster and Land Speed Record vehicles. It was amazing the stresses they endured and the components we broke. My rocket high-speed flight computers record accelerometers railing on almost every flight for 20-80 milliseconds. The graph shows the ejection charge, parachute burrito release, and initial parachute inflation.

No, I've tried madgwick AHRS, and it was very drifty, at least with the way I set it up. I'm not using magnetometer orientation, the BNO055 has sensor fusion algorithms onboard that calculate orientation. Unfortunately, they only work with +/-4g which is why it is not at 16g. I want to use the 16g mode but I am not sure how to get accurate using only accelerometer/gyroscope velocity values, everything I implemented drifted or gained error quickly during high-vibration tests.

Wow, the canards on the Aim-9 sidewinder are huge! Is it even aerodynamically stable? I feel like it must use its control systems to stabilize itself, but I am trying to use aerodynamic stability and just have canards control altitude, I think stabilizing the entire rocket is too complicated (especially considering the inaccuracy of civilian IMUs and GPS etc.)

Our parachute deploys well after Apogee because we didn't have a delay drill, we will work on that so that we can get it closer to apogee (right now it is close to its terminal velocity when parachutes deploy, OpenRocket even gives a warning!). Honestly I'm surprised it survived the first 2 flights.

We re-3d printed every single part of the rocket due to various improvements, but here are the main ones:

Larger fins (blue is new)


Heat set inserts (before there were nuts taped in)

We also changed the diameter of the tubes to be more consistent and had to strengthen and re-print all damaged parts.

 

[waltr]

Those canard fins seem not to be long enough (out from BT) to be fully effective.

Also, where is the CG compared to where the canards are mounted?? Looks to be close to the CG. If so then these will NOT make the rocket turn but only go sideways.

Remember that in flight the rocket rotates around the CG.

 

[Nv7]

Those canard fins seem not to be long enough (out from BT) to be fully effective.

Also, where is the CG compared to where the canards are mounted?? Looks to be close to the CG. If so then these will NOT make the rocket turn but only go sideways.

Remember that in flight the rocket rotates around the CG.

Wouldn't tilting the fins in opposing directions induce a spin/drag regardless of their orientation relative to the Cg? I might increase the width if they do not seem strong enough in our upcoming tests, I don't want them to be too big otherwise it will mess up the static stability.

 

[waltr]

Wouldn't tilting the fins in opposing directions induce a spin/drag regardless of their orientation relative to the Cg? I might increase the width if they do not seem strong enough in our upcoming tests, I don't want them to be too big otherwise it will mess up the static stability.

Ahhh...forgot you are controlling 'roll'.
Yes, that is correct.

Think about control fins of about the same area but extend away from the BT farther. Typical shape is a clipped delta. Read up on wings.
There is an old 'rule of thumb' that the fins should extend at least one body diameter from the BT. Exeptions exist but look at all the kits and also Sounding rockets and this is true most of the time.

 

[Spacedog49Krell]

Wouldn't tilting the fins in opposing directions induce a spin/drag regardless of their orientation relative to the Cg? I might increase the width if they do not seem strong enough in our upcoming tests, I don't want them to be too big otherwise it will mess up the static stability.

You actually want spin fins to be closer to the Cg. Any misalignment of the spin fins will have less pitch and yaw leverage through the Cg. The Sidewinder canards are large to provide greater pitch and yaw leverage for directional control. Your current spin fin design will require a greater angle of deflection as they are moved closer to the Cg.

Secondarily, the short height above the body tube places the spin fins in the turbulent boundary layer region. Spin fins that extend further out from the body tube will deliver more spin torque.

You can test spin fin design and placement effectiveness by taping or gluing short threads to the body tube and spin fins to give a visual reference for air flow and turbulence. As you direct an air stream from a leaf blower or Shop Vac over the rocket, look for turbulent flow patterns as you control the spin fins through different angles of deflection.

 

[Nv7]

We had exciting launches today but I'll just share the electronics part of it. I tried a new accelerometer code that used the orientation of the BNO055 and gravity data and combined it with the acceleration of the integrated LSM9DS1 (since Arduino Nano 33 BLE) with +/- 16G. However, it didn't work and it seems to have just been returning 0s throughout the flight. After landing it started returning actual data but I cut that out of the data file.

How did it not work?? I normally would say its a connection issue but the LSM9DS1 is literally soldered onto the Arduino.
It seemed to have spun more with the bigger fins but not enough data to really tell if the bigger fins are making enough of a difference. I am switching back to +/- 4G but I'm thinking of getting a board with the BHI260AP which supports +/-16G with sensor fusion, perhaps https://store-usa.arduino.cc/products/nicla-sense-me?selectedStore=us

Planned 3 launches but couldn't do any more due to damage to the rocket. The parachutes deploy at very high velocity so I think the egg pushed on the new bulkhead we installed and actually broke the top part of the rocket, last time it just pushed the nose cone out but this time we had a bulkhead.

Also the motor mount broke, but we are switching to a 3d printed retainer system that will make it a lot stronger.

As usual flight data and video are attached.


Broken motor mount:
View attachment IMG_6390.jpg

Broken payload:
View attachment IMG_6392.jpg

 

[kjhambrick]

@Nv7 --

What is the sample frequency for the rows in flight.csv ?

Thanks

-- kjh

 

[Nv7]

@Nv7 --

What is the sample frequency for the rows in flight.csv ?

Thanks

-- kjh

9 ms between most data values so its around 111 Hz

 

[OverTheTop]

Those canard fins seem not to be long enough (out from BT) to be fully effective.

You would be surprised how little effort is needed to change the roll of a rocket. The moment on inertia in the roll axis is much smaller (factor of about 30 in my rocket) compared to the pitch and yaw axes.

 

[Nv7]

New retainer design, have to see if it will be damaged by the rocket exhaust but is definitely a lot stronger
View attachment IMG_6406.jpg
View attachment IMG_6407.jpg

 

[Nv7]

Awesome launches today! Did a 24deg test and we can see in the sims (below) that the Cd had to be changed from 0.46 to 0.51 to get the graphs to line up! That proves that changing the angle does noticeably affect the drag of the rocket!


Today was also the first time ever that the rocket survived with no damage, our delay drill still hasn't arrived so the parachutes have been deploying at extremely high velocities but changes to the design and improvements in the stringing setup made it come out ok!

Flight data is attached

 

[Spacedog49Krell]

You have a complete flight with very valuable and interesting data.
1. The accelerometer is functional. Unusual motor burnout data, might be from out-of-phase vehicle precession. I also see some uneven drag during the coast phase.
2. The increased canard angle produced one more complete rotation before peak.
3. The canards are ineffective at low velocities (circled areas). The negative slope in your heading data indicates loss of canard rotational effectiveness. There is some counter rotational spin induced from the fin can. Increasing the spin rotation will increase the fin paddle drag.

Keep making improvements and a Merry Christmas to you and your team.

 

[Nv7]

You have a complete flight with very valuable and interesting data.
1. The accelerometer is functional. Unusual motor burnout data, might be from out-of-phase vehicle precession. I also see some uneven drag during the coast phase.
2. The increased canard angle produced one more complete rotation before peak.
3. The canards are ineffective at low velocities (circled areas). The negative slope in your heading data indicates loss of canard rotational effectiveness. There is some counter rotational spin induced from the fin can. Increasing the spin rotation will increase the fin paddle drag.

Keep making improvements and a Merry Christmas to you and your team.

Heres a graph of our simulated acceleration vs. real acceleration (green is simulated), it makes it very clear where the accelerometer is getting cut off due to the +/-4g limit of the accelerometer

I don't think I need to be worried about the canards being ineffective at low velocities because nothing after apogee matters since this is active apogee control, and most of the variation between flights that this needs to correct for occurs over 100ft into the flight

I'm excited that an entire rotation extra occurred this flight, this shows the new fins are definitely a lot more effective! Thanks for the insights and Merry Christmas!

 

[Spacedog49Krell]

I have extensive experience with Analog Devices and STM accelerometers. When they rail, it is a set value. The Bosch sensors don't rail in the same manner. Seeing the variations in acceleration, I wrongly assumed it was real data. Once I integrated the acceleration values, I realized it was ~300% low for a motor burnout altitude of 46m.

 

[Nv7]

Today we actively the fins during flight, and it seems to have worked! To do this I used CFD simulations to create a curve of fin angle to Cd:



Then I put the equation into our scilab simulation:

And then I created a target flight profile that would lead to the most desirable results using this simulation.

Today, we flew this:

This graph shows altitude (blue), target flight profile (orange), fin angle (gray). Compared to our simulation (top graph black line is "real" altitude, green is target altitude, and bottom graph red line is the fin angle):


I can see that in both the simulation and real angle that towards the end the fins become saturated with error and even at its max angle it cannot reduce the error. In a future iteration I will increase the size of the fins so that they have more authority. However, in this flight I can there are oscillating fin movements at the start of the flights not present in the simulation. I think this could be because of noise in the barometer data being interpreted as error in the PID control. How do I fix this?

We did a second flight but for some reason the accelerometers started returning 0 and the kalman filters started returning NaN? I know this isn't an issue with the data transfer because I can see launch detect didn't work (which relies on the accelerometers) and because of that the fins stayed at 90 degrees. It also went sideways, but I'm not as worried about that. Any ideas on why this could be happening?

Flight data and videos for both flights are attached, and happy new year!

 

[kjhambrick]

@Nv7 --

I wonder if you want to approach the problem of control in terms of LIFT instead of DRAG ?

So it would be CL instead of CD ...

I believe all of the above methodology would be much the same but the forces that you're after are the forces that are NORMAL to the direction of flight ...

Just $0.02 worth ... HTH ...

-- kjh

 

[waltr]

We did a second flight but for some reason the accelerometers started returning 0 and the kalman filters started returning NaN? I know this isn't an issue with the data transfer because I can see launch detect didn't work (which relies on the accelerometers) and because of that the fins stayed at 90 degrees. It also went sideways, but I'm not as worried about that. Any ideas on why this could be happening?

Does the accelerometers give proper reading now (after the flight)?
There could be a solder joint gone bad or other issue with the accel chip if not working.
if working it may have hit the limits and then only output 0 until power cycled.

Great progress.

 

[Nv7]

Does the accelerometers give proper reading now (after the flight)?
There could be a solder joint gone bad or other issue with the accel chip if not working.
if working it may have hit the limits and then only output 0 until power cycled.

Great progress.

Yes, and this has happened before but I can never reproduce it at home, pretty confused by this