Actively controlled rocket not flying straight

[Nv7]

I'm mostly done with the software (just need some work on the state estimation), so I started 3d-printing the rocket! Here's a timelapse of the transition printing on my new 3d-printer which I was able to buy with the prize money from nationals!

View attachment FirstTransition.mp4

 

[Nv7]

Its done printing! Surprisingly its only about 8 hours to print all the pieces in this, which is much better than the previous 18 hours! I think it looks super cool, even better than last year's rockets despite having the transition upside down, and the white filament also looks pretty nice

 

[kjhambrick]

Very nice @Nv7 !

Thanks for sharing your progress !

I can't build a rocket with traditional components and glue in eight hours !

Do you have an Open Rocket .ork file for your latest version ?

-- kjh

 

[Nv7]

After a couple days of printing, seeing things don't fit properly, and re-printing, its ready! I had to adjust the tube lengths a bit but here is the ready-to-launch version (with the motor in but without the eggs loaded):
View attachment IMG_8376.jpgView attachment IMG_8377.jpg

One thing I love about these 3d-printed modular rockets it that I was able to re-use nearly everything from last year - the shock cord, elastic cord, fire blank, and a parachute come from last year's rocket, and even the screws have soot on them! Here are some stats:

Mass: 645g
Motor: Aerotech F67W
Length: 27.6"
Cost: ~$40 (not including motors)
Payload Parachute: 18" Diameter
Fin Can Parachute: 12" Diameter

I've attached the OpenRocket file below!

 

[Nv7]

Exciting launches today! There were a bunch of bugs in the first flight that we addressed, and the second flight data is good acceleration-wise but the altitude sensor is reporting a lot of noise. I'm not sure if its the problem with the sensor driver or if I just need to switch sensors, right now it is the MS5607 (in the past I've used a BMP280). Here is the second flight!

Mass: 648g (whew, close to that 650g limit definitely need to remove mass)
Flight time: 48.5s
Altitude: 845ft (no active control, just testing the sensors)

Video:
View attachment IMG_8396.mov

While there was no damage on the first launch, a ton of things broke on the second launch, including one expensive servo
I have plans to fix all of these though and its good that I can address them early!


The base of the payload bay broke, I will add some small strakes to fix this
View attachment IMG_8398.jpg
The battery mount broke, I can just make the walls thicker

The servo broke, this is the most difficult one to fix. My plan is to build a two-part case that encloses the servo, and then that screws into the transition instead of using the fragile servo mounting holes. I'll redesign the transition for this.


This didn't break its just interesting that it turned yellow without the fin can below it turning yellow. Overall I think the white looks good after a launch (better than the black and blue rockets) so I think I'll stick with it! Going to call it Ghost

I've attached the flight data below!

 

[Spacedog49Krell]

Your new processor is providing better time performance for analysis. Your time integration of 4 ms is good. You still need to address the 28 ms of time lost writing to the SD card. That's 16.6% of your data that you are not seeing. Buffering the data will resolve that issue. Will buffering improve altitude control, probably not. Capturing your accelerometer readings during the full burn is a major improvement in altitude control. The F67W motor experienced two anomalies during the burn which would have affected your altitude control system. Resolving the buffered data issue would be a highlighted point in a technical presentation. If you become an aerospace engineer, companies will look for those details on a resume.

The MS5607 barometer is noisier than a BMP280. It has a higher altitude range and faster output data rate. I'm still working on the oversampling rate settings for a smoother output.

Check with the servo manufacturer about a replacement case for your servo. Broken mounting tabs is a common issue. They may sell a replacement lower case.

Keep up the good work. You're capturing data at a higher rate than one of the university rocket projects I'm an advisor on. I went over the data of the very successful flight last month. The rocket set a new altitude record and was recovered intact. When I reviewed the data, they only recorded 15 channels at 14Hz due to the radio data link bandwidth. The processor they used had the capability of recording 15 channels at 1000Hz while sending an averaged data packet to the radio downlink at 14Hz.

 

[Nv7]

Your new processor is providing better time performance for analysis. Your time integration of 4 ms is good. You still need to address the 28 ms of time lost writing to the SD card. That's 16.6% of your data that you are not seeing. Buffering the data will resolve that issue. Will buffering improve altitude control, probably not. Capturing your accelerometer readings during the full burn is a major improvement in altitude control. The F67W motor experienced two anomalies during the burn which would have affected your altitude control system. Resolving the buffered data issue would be a highlighted point in a technical presentation. If you become an aerospace engineer, companies will look for those details on a resume.

The MS5607 barometer is noisier than a BMP280. It has a higher altitude range and faster output data rate. I'm still working on the oversampling rate settings for a smoother output.

Check with the servo manufacturer about a replacement case for your servo. Broken mounting tabs is a common issue. They may sell a replacement lower case.

Keep up the good work. You're capturing data at a higher rate than one of the university rocket projects I'm an advisor on. I went over the data of the very successful flight last month. The rocket set a new altitude record and was recovered intact. When I reviewed the data, they only recorded 15 channels at 14Hz due to the radio data link bandwidth. The processor they used had the capability of recording 15 channels at 1000Hz while sending an averaged data packet to the radio downlink at 14Hz.

Thank you! I buffered it with 42 frames for every write, so that I can write to one flash sector at a time. I wasn't sure whether I should buffer it more because it will need to write a very large amount when it does have to write and there is a risk of losing data (often the flights that are the most likely to lose data also have the most interesting data). Ideally I would use the Quad-SPI interface but unfortunately that is not compatible with the processor I am using.

I looked into the MS5607's oversampling and I found that it slowed down the sample time a lot. In fact, most of the 4ms time between samples is already coming from the barometer. Here are the times I got for oversampling (its just linearly correlated with the oversampling factor)
256 (minimum): 4ms
512: 8ms
1024: 16ms
In addition, I only got a very minor improvement in the range of the measurements when going from 256 to 512 (although I wasn't following a very scientific approach).

When designing the flight computer I read a paper that claimed the MS5607 had a lower standard deviation in its readings than the BMP280, but it doesn't seem to be true. I followed their schematic and design guidelines and yet it was still very noisy. Because of this, I modified the PCB to use the BMP280 and I've sent in another order to JLCPCB.

To solve the broken servo I am redesigning the transition so that it comes in 2 parts that completely enclose the servo case. Now, the entire body of the servo is supporting the canards instead of just the little tabs. Another benefit of this design is that I can fit the battery inside of the transition, saving a lot of space above (and it looks better)

Congratulations on your teams' successful flight!

 

[Nv7]

Today I did a test of the BMP280 and it was amazing! The sensor doesn't have a delay while reading so I was able to achieve over a 1000Hz control loop, so fast that my delta time calculations using milliseconds didn't work anymore! (i switched to microseconds)

Since its so fast now, I will record data every 10ms instead of doing it based on the sample count!

 

[Spacedog49Krell]

Today I did a test of the BMP280 and it was amazing! The sensor doesn't have a delay while reading so I was able to achieve over a 1000Hz control loop, so fast that my delta time calculations using milliseconds didn't work anymore! (i switched to microseconds)

Since its so fast now, I will record data every 10ms instead of doing it based on the sample count!

The BMP280 and MS5607 sensors are nothing alike. The MS5607 is fast (2000Hz), wide altitude range, 24-bit data, but no internal processing. The external processor and library do all of the temperature data compensation. The BMP280 is slow (157 Hz) by comparison, limited altitude compensation algorithm, 20-bit data, but it has an internal processor for the temperature compensation and data output. The BMP280 in cyclic or free running mode updates the output data registers when new data is available, but you can read the registers at any time between updates. There is a "STATUS" register that sets a flag when new altitude data is available.

I went back and looked at your raw altitude data. You have a 20m noise bandwidth from the MS5607. That is excessive! Which MS5607 library are you using?

 

[Nv7]

The BMP280 and MS5607 sensors are nothing alike. The MS5607 is fast (2000Hz), wide altitude range, 24-bit data, but no internal processing. The external processor and library do all of the temperature data compensation. The BMP280 is slow (157 Hz) by comparison, limited altitude compensation algorithm, 20-bit data, but it has an internal processor for the temperature compensation and data output. The BMP280 in cyclic or free running mode updates the output data registers when new data is available, but you can read the registers at any time between updates. There is a "STATUS" register that sets a flag when new altitude data is available.

I went back and looked at your raw altitude data. You have a 20m noise bandwidth from the MS5607. That is excessive! Which MS5607 library are you using?

I thought it could be the library, so I tried two:
- https://github.com/joaopedrovbs/MS5607-STM32-SPI/tree/master
- https://github.com/Pyponou/barometer_ms5611/tree/master

While I had to multiply the output by two for the ms5611, both gave basically the same amount of noise and behaved about the same.

I added a 100nf decoupling capacitor on the power input which is all the datasheet said to do, so I'm not sure if a problem with the PCB could've caused it?

Either way the 157Hz of the BMP280 is fine as I'm using a complementary filter that fuses the IMU with the barometer at a high rate.

 

[Spacedog49Krell]

Went through your library codes. The MS5611 does not compensate for temperatures below 20°C. The MS5607-STM does 2nd order temperature compensation below 20°C. I didn't find a reason for the large noise bandwidth in the library codes, it might just be the sensor or your settings. Were you using SPI Com and what clock frequency?

On my high speed systems, my Coms are separate to prevent data collisions. I have the IMU on one SPI channel, the BMP280/390 on I2C @ 3MHz, and the SD card on a second SPI channel.

 

[Nv7]

Yes I was using SPI, I am using the same SPI channel for everything though. I don't think it is a problem with the SPI because the sensor didn't work well even in tests where I was only reading it (not reading the IMU). The baud rate is 3.0 Mbits/s (3 Mhz I think). Now I have the BMP280 on the same SPI bus and it is working well too.

I thought it could be the sensor and JLCPCB sends 2 boards assembled minimum, so I tested both boards and they had the same amount of noise.

 

[Spacedog49Krell]

I run my SPI at 12MHz unless there is a limitation with a sensor, the I2C at 1-3MHz most 400KHz sensors work at 1MHz, and the UART at 2MHz.

Data collision was an issue 45 years ago when I started doing Assembly programming. I still carryover techniques that I know prevent or isolate problems. Most of the newer and faster processors have multiple serial output channels and I take advantage of them.

I have limited experience with the MS56XX sensors. I noticed that they had more output noise than the Bosch sensors. Since my rockets weren't going above 10km I went with the BMP280 for cost and low noise data output.