Actively controlled rocket not flying straight

[Steve Shannon]

Hey, if you want to go through all of that work, go for it. However, that's not what the contest is all about.

This!
And the first thing engineers learn when they get a job is that simple is almost always better.
“Coolness” is highly overrated.

 

[jqavins]

The fabrication rule is recent... to prevent them from using commercially-available "stuff" to gain an advantage.

That doesn't sound right, since the rule is about custom stuff, that it can be used only if made by the team members. Commercially available stuff is not custom. What you can't do is, for example, design your PCB then send it off to a prototyping shop to fabricate for you.

And yes, photo etching, like Steve said.

https://www.instructables.com/DIY-PCB-Etching/

 

[cls]

@Lv7, have you actually flown a model rocket? Have you flown one with an egg in it? Did you get it back? Did the egg break?

I doubt you've done any of that. Post some pix, I'd like to be wrong about that.

Meanwhile, stop trying to cheat. It's not in the spirit of the competition.

It's a class competition, every team has similar equipment, so it's your skills and teamwork that matter.

It's not an open class competition, where the most $ wins.

Look at sailing and auto racing for comparison.

 

[jqavins]

@Lv7, have you actually flown a model rocket? Have you flown one with an egg in it? Did you get it back? Did the egg break?

I doubt you've done any of that. Post some pix, I'd like to be wrong about that.

Meanwhile, stop trying to cheat. It's not in the spirit of the competition.

It's a class competition, every team has similar equipment, so it's your skills and teamwork that matter.

It's not an open class competition, where the most $ wins.

Look at sailing and auto racing for comparison.

We know he's flown rockets. For the rest I won't speak for him.

The "spirit of the competition" I don't know about. But how can you call something that's within the rules "cheating"? The rules, in addressing things like custom 3D printed parts and custom PCBs, explicitly state that that they are not allowed unless they are "designed and fabricated by the student team members only." So so off the shelf components are explicitly allowed, as are custom components that the team makes themselves How is any of that cheating?

I think I've been clear that I think these steerable canards are bad idea, and that using different rockets for the qualifiers and finals is an even worse one. But it certainly doesn't seem that being clever is cheating, nor should it be, even if it's too clever for your own good.

 

[Alan15578]

Yup, thats our plan! We're going to try these things one by one.
We could solder an Arduino Nano onto a proto board but I feel like this rule is unreasonable, or maybe I am understanding it wrong. Its industry-standard practice to have PCBs manufactured by 3rd parties. Schematic & PCB design is a valuable skill and there are lots of jobs for it. It costs like tens of thousands of dollars to fabricate a PCB yourself so I feel like TARC is basically limiting the potentials of that to really rich teams or perhaps none. In addition, soldering a bunch of components together really isn't applicable once you exit TARC. Graduates from our school literally work in PCB design at SpaceX. Considering that TARC exists to prepare us for the engineering industry I feel like this rule is hypocritical. I've emailed them and I'll see what they say

You may be a better "Pink Book Lawyer" than engineer.

Seriously, violate the rules and cut corners to make a proof of concept vehicle. If it works, then you can make a more difficult vehicle that meets the rules. Thinking outside the box, design constraints, is not good for engineers.

 

[Titan II]

Hey, if you want to go through all of that work, go for it. However, that's not what the contest is all about.

So what is the contest all about?

The contest gives students the opportunity to design, build and launch model rockets and hands-on experience solving engineering problems.

That sounds like what they are doing.

Ultimately, the goal is to win.

Meanwhile, stop trying to cheat. It's not in the spirit of the competition.

How are they cheating?

 

[Nv7]

@Lv7, have you actually flown a model rocket? Have you flown one with an egg in it? Did you get it back? Did the egg break?

I doubt you've done any of that. Post some pix, I'd like to be wrong about that.

Meanwhile, stop trying to cheat. It's not in the spirit of the competition.

It's a class competition, every team has similar equipment, so it's your skills and teamwork that matter.

It's not an open class competition, where the most $ wins.

Look at sailing and auto racing for comparison.

Yeah, like I said we have a traditional rocket that we've flown a lot and tuned, every time with an egg (and the egg has never broken).

How is developing an active control system cheating??

 

[Nv7]

That doesn't sound right, since the rule is about custom stuff, that it can be used only if made by the team members. Commercially available stuff is not custom. What you can't do is, for example, design your PCB then send it off to a prototyping shop to fabricate for you.

And yes, photo etching, like Steve said.

https://www.instructables.com/DIY-PCB-Etching/

We would have to buy lots of chemicals for this and I doubt this would produce a PCB with the quality we are using right now. I guess we'll just have to regress back to our old breadboard prototypes.
This is what we would have to produce:

I really doubt a homemade etching thing would be able to produce a PCB with enough quality to SMT solder this.

 

[wmay78]

Remember at the basics of engineering, you want to get the job done in the most simple way possible. It would appear that you are trying to over-complicate it as these gentlemen are so kindly explaining in very detailed ways. Best of luck in the TARC!

 

[jqavins]

I really doubt a homemade etching thing would be able to produce a PCB with enough quality to SMT solder this.

Did you notice that Big Clive produced 0.4 mm lines and legible 1 mm high text? But suit yourself.

 

[Tractionengines]

I wasn't going to post anymore here, because you've been given a lot of advise... but here is a response to your comment.

We would have to buy lots of chemicals for this and I doubt this would produce a PCB with the quality we are using right now. I guess we'll just have to regress back to our old breadboard prototypes.
This is what we would have to produce:
View attachment 601445
I really doubt a homemade etching thing would be able to produce a PCB with enough quality to SMT solder this.

The etching is easier than the drilling...in the "old days" with all thru hole parts making prototype boards we had drill counts... ie a #xx drill was only good for yy number of holes, then you threw it away regardless. Broken drills, and "walking drill holes" are more of an issue than the resist, light exposure, and etching process.

I wouldn't expect a perfect board the first time, but it is possible to make a serviceable SMT board with a little practice.

 

[diyaerospace]

I think we should take a step back.

If you are trying to win with an active controlled rocket it probably won't happen, at least this year.

There is a ton to learn and getting your system to be reliable enough is likely going to take more time than you have in a single ARC season.

I did active control on ARC last year.
https://www.rocketryforum.com/threads/active-altitude-control.174855/
It was a great learning process but there were a lot of unforeseen problems I encountered.





Your first problem is getting your rocket to know where it is.

A barometer can be used to tell apogee, although it's readings become somewhat distorted by high speed flight and I would not rely on barometric derived velocity estimates.

An accelerometer can be used to determine velocity and altitude. However, it is important to note that most sensors read acceleration in the body frame, which when integrated measures distance the rocket has traveled, not altitude above ground level. There are solutions to this, all of which are math heavy.

How have your sensors preformed on previous flights?




I really want to see more people working with active control and flight computers as there is a ton to learn,
Walter

 

[Nv7]

We did a launch today and it went great! Set fin angles to 0deg and it went perfectly straight up! Also, we fixed all our software bugs and we finally got flight data off our flash chip! I've attached the flight data and video to this post.
We flew it with a P-Nut altimeter, which reported an apogee of 862ft. This matches with our flight data which reported 869ft:

Our accelerometer maxed out at 3Gs so we weren't able to get the real acceleration, but you can clearly see the motor burning, quick deceleration at burnout, it coasting, and spikes at parachute deployment & landing!


You can also see that the rocket went straight up in the X and Y absolute acceleration values.

Feeling good about this launch, I plan on validating the data against the sim data and then flying with various fin angles (probably 1, 2, 3, 5) next week to characterize the rocket's response to those, will update when that happens.

 

[Nv7]

I think we should take a step back.

If you are trying to win with an active controlled rocket it probably won't happen, at least this year.

There is a ton to learn and getting your system to be reliable enough is likely going to take more time than you have in a single ARC season.

I did active control on ARC last year.
https://www.rocketryforum.com/threads/active-altitude-control.174855/
It was a great learning process but there were a lot of unforeseen problems I encountered.





Your first problem is getting your rocket to know where it is.

A barometer can be used to tell apogee, although it's readings become somewhat distorted by high speed flight and I would not rely on barometric derived velocity estimates.

An accelerometer can be used to determine velocity and altitude. However, it is important to note that most sensors read acceleration in the body frame, which when integrated measures distance the rocket has traveled, not altitude above ground level. There are solutions to this, all of which are math heavy.

How have your sensors preformed on previous flights?




I really want to see more people working with active control and flight computers as there is a ton to learn,
Walter

Thanks! We are using the BNO055 which provides us with absolute orientation, and therefore world-relative acceleration. On this most recent flight the barometer (BMP280) seemed mostly correct and at least matches with the P-nut altimeter, although it did spike quite a bit during the ejection charge deployment.

I attached the data to the above post in case you have any ideas on how to validate it in a better way.

 

[waltr]

I would not be too sure about the BNO055 giving Absolute orientation. The algorithms used tend to use the Accelerometer data to give Earth reference ( great for robotics) but this disappears once a rocket leaves the pad.

There is some Accel data that may be very useful to you. That is the Accel after motor burn-out up to apogee (or deployment). The accel data goes Negative due to DRAG. Look for the technical paper by Tim Van Milligan from Apogee Components on the NAR web site.

Next I would be integrating the Accel data into Velocity and integrate Vel into Altitude. This altitude should match the Baro altitude IF the flight was straight up.

Then it is the integrated Gyro (looks to be done inside the BNO055) data that shows if the rocket did or did not go straight upand it looks like it did go straight up.

Your .csv data file looks a lot like the data file I write from my rocket data logger. Good format for Post-flight analysis.

 

[diyaerospace]

I agree with waltr, the next step should be integrating the accelerations to velocity and altitude.

How exactly do you plan to control altitude? Your canard approach seems to be a little overcomplicated with more variables than necessary.

 

[Nv7]

I would not be too sure about the BNO055 giving Absolute orientation. The algorithms used tend to use the Accelerometer data to give Earth reference ( great for robotics) but this disappears once a rocket leaves the pad.

There is some Accel data that may be very useful to you. That is the Accel after motor burn-out up to apogee (or deployment). The accel data goes Negative due to DRAG. Look for the technical paper by Tim Van Milligan from Apogee Components on the NAR web site.

Next I would be integrating the Accel data into Velocity and integrate Vel into Altitude. This altitude should match the Baro altitude IF the flight was straight up.

Then it is the integrated Gyro (looks to be done inside the BNO055) data that shows if the rocket did or did not go straight upand it looks like it did go straight up.

Your .csv data file looks a lot like the data file I write from my rocket data logger. Good format for Post-flight analysis.

I've tried simple integration but the velocity drifts leading to a terribly innacurate altitude estimate from the accelerometer. How do you deal with this?

Right now alt is calculated by just putting the baroAlt (baro) through a simple 1d kalman filter, and then vel is calculated using the alt values and put through another simple kalman filter. Simple integration with the accel values leads to very innacurate velocity

 

[Nv7]

I agree with waltr, the next step should be integrating the accelerations to velocity and altitude.

How exactly do you plan to control altitude? Your canard approach seems to be a little overcomplicated with more variables than necessary.

I've explained this earlier in the forum but basically:
1. Test various fin angles and try to figure out a Cd
2. Characterize fin angle response in Simulink or something like that
3. Use a PID controller that takes in altitude vs target altitude and creates a fin angle (using a target flight profile that we would have to make)
Probably would be tuning PID controller in simulink first

Also, simulink is kind of hard for us to get any ideas for other application to use

 

[diyaerospace]

I've tried simple integration but the velocity drifts leading to a terribly innacurate altitude estimate from the accelerometer. How do you deal with this?

Right now alt is calculated by just putting the baroAlt (baro) through a simple 1d kalman filter, and then vel is calculated using the alt values and put through another simple kalman filter. Simple integration with the accel values leads to very innacurate velocity

Are you testing this on the ground, or in flight? If the former is true, gravity will cause significant drift in your velocity measurements.

 

[diyaerospace]

I've explained this earlier in the forum but basically:
1. Test various fin angles and try to figure out a Cd
2. Characterize fin angle response in Simulink or something like that
3. Use a PID controller that takes in altitude vs target altitude and creates a fin angle (using a target flight profile that we would have to make)
Probably would be tuning PID controller in simulink first

Also, simulink is kind of hard for us to get any ideas for other application to use

In my experience you can get good results by simulating in python.

Here are some things you might not be considering with active altitude control.


1. Un-temperature corrected barometer data.
Because all TARC approved altimeters don't factor in air temperature with their altitude measurement the actual altitude and measured altitude will be quite different.
Your custom barometer needs to either be un-temperature corrected or you will have to manually do the conversion, which requires an air temperature reading.

2. You might have to factor in the angle of the rocket into your PID controller. The area of the rocket that is facing upward is going to change as the rocket starts weathercocking. This will change the effective "upward" CD, adding another layer of complexity into your controller and simulation.


I am sure there are more things to factor in but those are the ones I can think of off the top of my head.

 

[cerving]

Actually, the baro sensors used in just about every altimeter DO factor in temperature... the problem is that they're not very accurate or responsive. They're OK on the ground if they're not in a hugely confined space so they can reasonably adjust to ambient temperature, but in an AV bay where they're confined and sitting out in the sun the temperature may rise way above the ambient temperature. Since a hobby rocket flight it typically very short (under a minute for LPR/MPR, typically under 5 minutes for HPR) the temperature inside the AV bay doesn't change much, so it's basically a constant... which is fine, because it's the change in pressure from the ground reading that we're looking at to get the AGL altitude, not the "actual" pressure.

 

[cls]

I've tried simple integration but the velocity drifts leading to a terribly innacurate altitude estimate from the accelerometer. How do you deal with this?

Record the data until it detects launch, then discard all previous data; only integrate from the data immediately before launch.

Oldest trick in the book

 

[86mustang408w]

Are you looking for fins you can change the can't angle and it changes direction during flight for stability? There's a guy on YouTube that did that.

 

[jqavins]

[W]e fixed all our software bugs...

Perhaps the world's second most famous last words, behind only "Hold my beer."

 

[BABAR]

We're hoping the gyroscopic forces created by a spinning rocket would provide stability (spin stability). If our rocket flies in heavy winds (like D.C) it would tilt into the wind and lose lots of altitude. To combat this we want to use spin stability. They would also be controlled to do a fixed altitude, which would solve both problems (this is what we were thinking when we made this)

Effective gyroscopic force requires a good bit of MASS which must be PERFECTLY evenly distributed about the long axis. Also, doesn’t kick in until the rotation is “up to speed” which is challenging to achieve from a rod, rail, or typical tower, although possibly could be done through a tube launch. This means EVERYTHING, INCLUDING THE RECOVERY SYSTEM, needs to be balanced at every launch.

10 degrees is far too much. The Apogee SloMo uses canted fins at the tail of the rocket, these copied from the web site are

Slotted Tube - CANTED AT AN ANGLE! - This kit is really unique in that the slots on the tube were purposely canted by 2 degrees.

now, they do add DRAG, and these are at the tail end.

you stick something out the front end canted 10 degrees and it’s gonna be a problem with drag and stability.

break down your tasks.

you want some spin to prevent weathercocking? Stick a spin tab on a tail fin and dial in what you need.

now come up with a way to stop the rocket at your target altitude.

I am kind of a Capt Kirk Kobayashi Maru kind of guy, I was thinking of a long shock cord and eject the payload and altimeter at the target altitude and let the rest of the rocket slow down more gradually, since you are gonna be judged by the ALTIMETER reading, not the actual altitude the rest of the rocket reaches. Still has to recover in one piece, hence the long shock cord.

 

[Nv7]

Are you testing this on the ground, or in flight? If the former is true, gravity will cause significant drift in your velocity measurements.

Well we have absolute accel so we can subtract gravity. However, I was testing it on the ground. I could try doing it on the accel measurements from in-flight but another issue with this is that they max out during the motor burning. Also, I've read online that the algorithms used in the BNO055 cause simple integration to be extremely innacurate.

 

[Nv7]

In the top you can see vel based on barometer, on the bottom you can see vel based on accelerometer. I'm guessing that the reason it is a negative value the whole time is because it is missing a lot of upwards acceleration due to the accelerometer maxing out. However it also seems to be drifting downwards slightly throughout

 

[waltr]

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.

 

[cerving]

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.

 

[kjhambrick]

Record the data until it detects launch, then discard all previous data; only integrate from the data immediately before launch.

Oldest trick in the book

Hmmm ... my $0.02 here ...

The problem with 'discarding all previous data' is that one cannot detect liftoff until AFTER the rocket has launched.

If you discard ALL previous data, you're going to throw out some significant data, especially when you're integrating acceletation readings.

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

-- kjh