Actively controlled rocket not flying straight

[Aeva]

Then @Nv7 you can get up to 16G on that sensor:

https://forums.adafruit.com/viewtopic.php?p=776214#p776214

 

[Nv7]

@Nv7 what accelerometer are you using? I know some of the stock LSMs I've used default to a lower magnitude of measurement to get more accuracy, but I was able to reconfigure mine to do up to 12G (which is still mostly insufficient for HPR, but has done well for MPR and less). Before you go buy new hardware, check if you can modify the configuration of the accelerometer to get larger magnitudes.

I plan on making a new flight computer with the Bosch BHI260AP which supports +/- 16g in sensor fusion mode, however, I am very busy with school so I don't have time to develop that for a while.

 

[Nv7]

Sorry for the response delay, I've been fighting a virus.

• Simulations are just that, a close approximation of what is reality. You use your real time data to make improves in the simulation calculations, not the reverse action.
• Solid propellant batch to batch burn rates vary. A ±100 ms variation in burn time is not unusual.
• Your 4G accelerometer rail severely limits knowing what is occurring above that value for burn time and velocity calculations. You need to record the actual acceleration values and not a simulated acceleration from a thrust curve.
• Check your servo response speed to understand the servo response delay. This value is given as a time/degree movement, usually 0.1/60° or 0.1/90°. My cheap SG90 test servos are rated at 0.1/60°, but my 90°movement test was 0.2/90°.
• Your canards are producing drag, just not the drag values I would expect.

- I understand that simulations are a close approximation, and normally my simulations are pretty close to reality (+/- 5m). However, in this flight they were significantly off from reality (20m). If they are this far off they are no longer useful

- For the burn time, yes, however this variation (at least from the acceleration graph) is 0.5 seconds, which is a very significant amount. Despite this, the rocket actually went lower, so maybe the peak thrust was lower? Would really be helpful to have that accelerometer range to understand more but I tested the LSM9DS1 and I found it really unreliable - I did one launch with it, but the data cut out during the flight and for a couple minutes after, even though its directly soldered onto the Arduino???

- I am using Blue Bird BMS-115WV+ servos which is a pretty reputable servo brand and they were also pretty expensive , how did you test the actual rotation rate? Servos don't have encoders or anything built in

- The canards only produce 15% of the drag as the CFD simulations predict. This is very weird, earlier I thought it was because of turbulent air from the rocket, however, I moved the surface area of these fins away from the rocket to combat this and its still 15%. This is also confusing me although all the data is confusing me so I don't know if I can trust this number

Thanks for the insight!

 

[Nv7]

Then @Nv7 you can get up to 16G on that sensor:

https://forums.adafruit.com/viewtopic.php?p=776214#p776214

Yes, but sensor fusion is not supported, and I need orientation data to measure vertical acceleration accurately (otherwise its difficult to account for gravity)

 

[icyclops]

Did a launch today on our new F35-8W motors, but unfortunately it ended up going a lot lower (not sure if it went vertical, hard to tell from POV) and because of that the delay was way too late so parachutes ejected at a very high velocity. Because of this the ring that attaches the parachutes to the payload tube broke. Then, the payload tumbled and the egg mount broke upon impact. Finally, the parachutes got tangled and failed to open so the fin can broke. Here is an image of every part that is broken (which is every exterior component):
View attachment 628579

Luckily the electronics, egg, and motor were completely unharmed (all the delicate and expensive components)!

View attachment 628582
In the video you can see there is a line coming off the fin of the rocket. This follows the rocket throughout its flight and starts when the motor ignites. What is it? Did it cause the rocket to go lower? Here is the video so you can take a closer look:

View attachment 628585

I have also attached the flight data but its not too useful because the fins didn't tilt since it went so low. However, I can see the rocket's oscillations until it tilts over as it approaches apogee. It seems like it flew straight though, until it tilted as the effectiveness of the fins reduced.
View attachment 628588

Almost looks like the fin tip is on fire from the rocket motor…you don’t really see it until it just clears the pad then the thrust looks like it catches right as it leaves the pad…..no loss of clear coat or paint I assume or tell tale signs of paint burn?

 

[Spacedog49Krell]

Here is your Blue Bird BMS-115WV data:

Torque At 3.7V	3.6 kg-cm / 50.0 oz-in
Torque At 6.0V	5.5 kg-cm / 76.4 oz-in
Torque At 7.4V	6.6 kg-cm / 91.7 oz-in
Torque At 8.4V	7.1 kg-cm / 98.6 oz-in
Speed At 3.7V	0.20 sec / 60°
Speed At 6.0V	0.13 sec / 60°
Speed At 7.4V	0.10 sec / 60°
Speed At 8.4V	0.09 sec / 60°

I used a simple beam break opto-coupler jig to measure the rotation time. I had to install wheel encoders on an old robotics project to keep the servos rotating evenly and the robot traveling straight.

Solid propellant motors are a Total-Impulse device. The thrust and burn time are affected by internal and external variables that you have no control over. The two most important parameters you can measure are time and acceleration. Limiting your acceleration to 3 g's produces an accumulative error in acceleration, velocity, and position. If your position is in error, I would assume your Euler angle is also in error. Real time calculations of Euler angles or quaternion vectors requires processor power on the order of ESP32 or Teensy 4.1 at my sampling rates of 500Hz - 860Hz. So, I do post flight calculations. The 6DoF ICM-20649 and the 9DoF LSM9DS1 are working for my applications. I took a quick look at the Bosch BHI260AP parameters, very interesting.

The 15% drag increase due to the canards is an interesting area. I also do not understand this value. Working with university students, they used a variable iris that extended drag panels out into the slip stream to reduce the velocity. The increased frontal area was ~2X. What is your canard area to stability fins area ratio?

 

[Nv7]

Almost looks like the fin tip is on fire from the rocket motor…you don’t really see it until it just clears the pad then the thrust looks like it catches right as it leaves the pad…..no loss of clear coat or paint I assume or tell tale signs of paint burn?

Nope, plus this has happened on the same fin can for the past 4 flights and nothing visible has happened

 

[Spacedog49Krell]

I'm following Joe Barnard's roll control fin tab experiments. Telemetry data from today's flight looks good and possibly relevant to your canard issues.

Looks like the video cameras didn't record.

 

[Nv7]

Here is your Blue Bird BMS-115WV data:

Torque At 3.7V	3.6 kg-cm / 50.0 oz-in
Torque At 6.0V	5.5 kg-cm / 76.4 oz-in
Torque At 7.4V	6.6 kg-cm / 91.7 oz-in
Torque At 8.4V	7.1 kg-cm / 98.6 oz-in
Speed At 3.7V	0.20 sec / 60°
Speed At 6.0V	0.13 sec / 60°
Speed At 7.4V	0.10 sec / 60°
Speed At 8.4V	0.09 sec / 60°

I used a simple beam break opto-coupler jig to measure the rotation time. I had to install wheel encoders on an old robotics project to keep the servos rotating evenly and the robot traveling straight.

Solid propellant motors are a Total-Impulse device. The thrust and burn time are affected by internal and external variables that you have no control over. The two most important parameters you can measure are time and acceleration. Limiting your acceleration to 3 g's produces an accumulative error in acceleration, velocity, and position. If your position is in error, I would assume your Euler angle is also in error. Real time calculations of Euler angles or quaternion vectors requires processor power on the order of ESP32 or Teensy 4.1 at my sampling rates of 500Hz - 860Hz. So, I do post flight calculations. The 6DoF ICM-20649 and the 9DoF LSM9DS1 are working for my applications. I took a quick look at the Bosch BHI260AP parameters, very interesting.

The 15% drag increase due to the canards is an interesting area. I also do not understand this value. Working with university students, they used a variable iris that extended drag panels out into the slip stream to reduce the velocity. The increased frontal area was ~2X. What is your canard area to stability fins area ratio?

The area per fin for the canards is 4.95, and for 2 fins that comes out to 9.9 square inches.

The area per fin for the bottom fins is 7.8, and for 3 fins that becomes 23.4 square inches.

The Bosch BNO055 has a builtin ARM chip that is doing the calculations necessary. I also have some of those encoders and I will see if I can find time to test the rotation rate.

 

[Nv7]

Did another launch today but it was super windy and it weathercocked. We are going to buy a longer rail and anemometer to tilt the rail properly to deal with this but also will launch on days with better weather.

The acceleration curve is super weird this time:

Didn't go high enough for fins to tilt, but here is the altitude comparison


Flight data and video are attached, you can still see that weird line. However, we successfully recovered everything unlike last time:
View attachment IMG_7021.MOV

 

[Spacedog49Krell]

The area per fin for the canards is 4.95, and for 2 fins that comes out to 9.9 square inches.

The area per fin for the bottom fins is 7.8, and for 3 fins that becomes 23.4 square inches.

The Bosch BNO055 has a builtin ARM chip that is doing the calculations necessary. I also have some of those encoders and I will see if I can find time to test the rotation rate.

I wouldn't worry about the rotational speed of your servos. Not a critical parameter. Your drag increase spikes are approximately 100 ms.

What could be important is your servo drive voltage. The available torque increases with drive voltage. Fluctuations in the drive voltage over the 100ms could indicate torque issues.

 

[Nv7]

I wouldn't worry about the rotational speed of your servos. Not a critical parameter. Your drag increase spikes are approximately 100 ms.

What could be important is your servo drive voltage. The available torque increases with drive voltage. Fluctuations in the drive voltage over the 100ms could indicate torque issues.

Yes, I have a future PCB planned that will greatly increase the power available to the servos but I haven't gotten a chance to make it yet. However, I think that the servos are working due to the dip in altitude from a high pressure zone created by the canards, the bump in acceleration, and because the rocket goes lower

 

[Nv7]

I did a couple of launches last weekend, one at a 0 degree fin tilt angle and found that it only goes 10 feet higher than the target. I am buying more powerful motors and will try again.

 

[Nv7]

The motors took 4 weeks to arrive and now I have 4 days to do qual flights...

 

[Nv7]

Did a launch on Wednesday! We switched to AeroTech F67 single-use motors and they are a lot more convenient (and powerful!). I also canted the fins on the fin can 5 degrees to hopefully achieve some spin stabilization. The launch was pretty good, the rocket flew straight, the rocket spun, and everything was recovered successfully.

The first launch went too high because I over-estimated the drag of the canted fins. But, you can see them working in the video attached.

To solve this, I activated the fins earlier (2.25s in vs 3s in) for the second launch. The sims predicted it would go 254m and it went 255m! However, there is a bigger problem with this.

You can see the spin in the accelerometer readings (and the roll data):


If I activate the fins too early, they correct too much and the rocket goes too low. If I activate them too late it goes too high. In addition, as I test different weather conditions all of them need different fin activation times/P values otherwise they go too low or too high. How do I solve this?

 

[kjhambrick]

If I activate the fins too early, they correct too much and the rocket goes too low. If I activate them too late it goes too high. In addition, as I test different weather conditions all of them need different fin activation times/P values otherwise they go too low or too high. How do I solve this?

@Nv7 --

Beautiful Flight and excellent acceleration and gyro data -vs- time !

Does your onboard flight controller have enough power to integrate acceleration -vs- time to instantaneous axial velocity -vs- time ?

If so, can you then integrate axial velocity -vs- time to instantaneous altitude -vs- time ( actually it will be axial distance -vs- time ) ?

I imagine given velocity and altitude, you could come up with a table of 'when do I activate my canards so the rocket will coast to a given altitude' ...

HTH !

-- kjh

 

[Spacedog49Krell]

Going from the F51 to the F67 motor increased your delivered total impulse by 10.8%. Both are ~1 second burn motors, but the F67 delivers about 150 ft/sec more velocity that your flight computer cannot sense to apply the brakes earlier.

 

[Nv7]

I thought about it and I realized my control system is completely wrong - it could reduce the velocity so much that the rocket wouldn't reach the target altitude but still have the current position be higher than the target position. Instead, the controller must incorporate velocity and position estimates.

Instead, the way I am thinking I will make it work is predict the apogee given the current position and velocity and use the error of that from the target final altitude as the error in the PID controller. Using a system of differential equations I simulated the apogee with a 4th order Runge-Kutta approximation. I then implemented that in a quick python sim and found it worked a lot better at getting the target altitude:



To solve the problem of estimating velocity I think I will not do anything before motor burnout, and after motor burnout I will integrate acceleration starting from the velocity after motor burnout as simulated. Despite the oscillation of acceleration as the rocket spins it seems that the velocity curve seems ok? It roughly reaches 0 at apogee and is much smoother than the barometer-based velocity.



Excited to try this out! In the sims the new control system worked a lot better and effectively handled a variety of conditions, unlike the previous system. I will implement this into the Scilab simulation and make sure it works well and then test it out on a flight.

 

[kjhambrick]

@Nv7 --

Why not integrate acceleration during the thrust phase too ?

IOW, where do you get velocity after burnout ?

-- kjh

 

[Nv7]

@Nv7 --

Why not integrate acceleration during the thrust phase too ?

IOW, where do you get velocity after burnout ?

-- kjh

The acceleration in the thrust phase exceeds the 4g limit of the accelerometer. Because of this, it cannot be integrated to get the correct velocity so instead I am obtaining this value from the simulation. However, a future design I have made will have a 16g accelerometer so that I can just integrate acceleration for the whole flight.

 

[kjhambrick]

Thanks, Nv7 !

Makes sense.

-- kjh