ArdIU - Open source flight computer w/ ATMega328

[UhClem]

Radians on roll.

That's the important one.

While your plot looks wild, it is hard to tell anything from just pitch and yaw. When I plot that for my data it also looks odd but the tilt tracks the quaternion version perfectly till ejection. (I computed tilt from pitch and yaw by squaring them and taking the square root of the sum.)

 

[SparkyVTFlyer]

I was out for a few days on vacation. I got back and tried your formula with interesting results. I combined pitch and yaw a few different ways and they showed the same thing.

I'm thinking there might be a speed limit to your method. I tried it for one flight that only rolled twice on the way to apogee and your equations were spot on. However, when I tried it with a flight that spun like a top on the way up, then it quickly got out of control. See the plots below.

I'm not sure what to make of it.

 

[UhClem]

When you say "spun like a top" it makes me wonder about the roll and sample rates. The simplified algorithm I presented (not mine, found in another thread here) uses the small angle approximation.

 

[SparkyVTFlyer]

Peak roll rate was about 1400 degrees per second. Average roll rate through most of the flight was about 700 dps. Datarate at about 800 samples per second through the flight.

Small angle approximation should be fine within 10 degrees for sine and 14 degrees for tangent, and none of the individual cycle rotations violated either. So I'm not totally sure why it isn't working.

I also take advantage of small angle approximation. Combined with fixed-point math I got around 400-450 cycles per second written to an SD card on an ATMega328. I double that now with the Teensy3.5, which pretty much pegs the output data rate of my sensor package (even over I2C).

 

[UhClem]

While that is good enough to keep the small angle approximation error below 1%, there is still some error. I have no idea what the limitations of this algorithm are as I haven't found any description of its derivation.

 

[Tetrahedron]

Peak roll rate was about 1400 degrees per second. Average roll rate through most of the flight was about 700 dps. Datarate at about 800 samples per second through the flight.

Small angle approximation should be fine within 10 degrees for sine and 14 degrees for tangent, and none of the individual cycle rotations violated either. So I'm not totally sure why it isn't working.

I also take advantage of small angle approximation. Combined with fixed-point math I got around 400-450 cycles per second written to an SD card on an ATMega328. I double that now with the Teensy3.5, which pretty much pegs the output data rate of my sensor package (even over I2C).

Here is an example of using your Arduino code with my Arduino Nano, MPU-6050 (16G) , ADXL-78 (70G) and BMP-180 for recording data.
I also had a 70cm GPS transmitter using Lora SX-1278 with Adafruit Feather M0+ Cortex processor.

[video=youtube;cUGMDxOq_es]https://www.youtube.com/watch?v=cUGMDxOq_es[/video]

-John

 

[LithosphereRocketry]

While that is good enough to keep the small angle approximation error below 1%, there is still some error. I have no idea what the limitations of this algorithm are as I haven't found any description of its derivation.

As far as I know it basically assumes that the "arc" of the angle is the same length as the opposite side of the right triangle, so the length of the arc (also known as the angle in radians) is equal to the sine of the angle. As the name would suggest, it's good for small angles but not large ones- 0.4% error at 9 degrees or 1.6% at 18 (unless my math is wrong, which is totally possible).

In other news I was able to get a bit done on the ArdIU code this weekend- more specifics when I have a few minutes. Basically, I have the basic groundwork set up for datalogging, including a handy template function that should be able to write any datatype to the SD. I still have a while to go, but I'm making progress!

<shamelessadvertising>Speaking of progress, there are still 3 unclaimed beta boards...</shamelessadvertising>

 

[LithosphereRocketry]

A bit more progress today.

Did some more coding, this time on the smoothing algorithm. I'm using an algorithm I found in an Indonesian presentation on the intertubes that biases the data toward a parabola- a pretty good guess for a rocket. I have a bit more to do on the 2nd gen PCB, and I still haven't done anything with the gyro, but it's getting closer.

Previous shameless advertising still stands.

Sent from my LGL44VL using Tapatalk

 

[LithosphereRocketry]

Even more progress.

I finally got the datalogging working, at least sort of. There's lots of finicky things that have to happen for the code to work, and I have zero idea why it works, but it's a start.

On the plus side, I now have working datalogging! :w: Still to do:

Accelerometer/gyro
Liftoff/apogee/landing detect
Deployment control
Probably more stuff as well

Sent from my LGL44VL using Tapatalk

 

[LithosphereRocketry]

ArdIU flew today! :w:

The data is pretty good except for a few things:
-Drift- the altitude drifted quite a bit sitting on the pad. Not sure if it's my smoothing or the barometer.

-Shock loads- The SD card popped out at apogee. Not ideal, but will hopefully be improved in the next version.

Anyway, here's what I got...


Sent from my LGL44VL using Tapatalk

 

[GrouchoDuke]

Woot! Congrats!

 

[LithosphereRocketry]

Thanks GrouchoDuke!

In other news, I just registered lithosphererocketry(at)gmail(dot)com for all my ArdIU related communications. If you have any questions or comments about software, hardware, batteries, when I'm gonna finally get the darn production version out, or anything really, you can shoot me an email there as well as on the forum.

Thanks for the support everyone! I don't have a ton of spare time but I'll do my best to get ArdIU flyable as soon as possible.

 

[LithosphereRocketry]

So I'm starting the board layout for the first beta run of ArdIU. I have a couple questions for those of you who may someday want one of these, or just have a general idea about what the public wants in a DD altimeter...

- SMD parts: ArdIU will be assembled by the user from a kit, Eggtimer style. This of course means that really tiny parts aren't going to be happening, but I'm on the fence between standard through-hole resistors, etc. versus 1206 SMDs (the size in an Eggfinder). The only objection to 1206 I have is that there are quite a few of them- 20 resistors and 4 capacitors by my count. What do people think about soldering that many SMD components?

- Extra pins: ArdIU in its current form has an extra pin along with the SPI bus broken out to a female header. However, ditching that would save a lot of board space. Would anyone be horribly offended by that? If I ditch the header, what should I replace the spare pin with? An indicator LED? I'd add another pyro but I don't have an input left to run continuity checks from.

Thanks all!

 

[ksaves2]

Chute, most of us who do EF stuff are used to the small resistors. I'm not talking about the "dust speck" ones seen in some of the Rf modules. I'm cool with the 1206 The only limitation I believe is some of the baro chips out there are extremely tiny and generally kit developers send the boards out with that component already on the board. Kurt

 

[LithosphereRocketry]

Chute, most of us who do EF stuff are used to the small resistors. I'm not talking about the "dust speck" ones seen in some of the Rf modules. I'm cool with the 1206 The only limitation I believe is some of the baro chips out there are extremely tiny and generally kit developers send the boards out with that component already on the board. Kurt

I'm using the BMP280 which is indeed tiny, but it's on a breakout board for now, so it'll be presoldered. I was more concerned about the total number- I missed one on my last count, so there would be 25 relatively small parts to solder.

There's a 4 pin I2C barometer that I looked at a while ago that is close to hand solderable- I can't remember the name at the moment but I might switch to that in later versions.

 

[Tobor]

So I'm starting the board layout for the first beta run of ArdIU. I have a couple questions for those of you who may someday want one of these, or just have a general idea about what the public wants in a DD altimeter...

- Extra pins: ArdIU in its current form has an extra pin along with the SPI bus broken out to a female header. However, ditching that would save a lot of board space. Would anyone be horribly offended by that? If I ditch the header, what should I replace the spare pin with? An indicator LED? I'd add another pyro but I don't have an input left to run continuity checks from.

Thanks all!

Not having those pins routed to a header is fine but, it would be nice to have any extra pins connected to pads like you see on PJRC's Teensy boards.

 

[OverTheTop]

I solder 1206, 0805 and 0603 components quite happily. Tweezer technique is king for the smaller parts.

I recently did a design using 0402 (0.04"x0.02") components and I am developing a bit of a dislike for them from a manual rework POV.

 

[vcp]

IMO: 1206's are enormous. 0805 is easy. 0603 requires some skill. More than a few 0402's are a challenge.

https://www.murata.com/en-us/about/newsroom/news/product/capacitor/2014/0507

 

[Voyager1]

So I'm starting the board layout for the first beta run of ArdIU. I have a couple questions for those of you who may someday want one of these, or just have a general idea about what the public wants in a DD altimeter...

- SMD parts: ArdIU will be assembled by the user from a kit, Eggtimer style. This of course means that really tiny parts aren't going to be happening, but I'm on the fence between standard through-hole resistors, etc. versus 1206 SMDs (the size in an Eggfinder). The only objection to 1206 I have is that there are quite a few of them- 20 resistors and 4 capacitors by my count. What do people think about soldering that many SMD components?

- Extra pins: ArdIU in its current form has an extra pin along with the SPI bus broken out to a female header. However, ditching that would save a lot of board space. Would anyone be horribly offended by that? If I ditch the header, what should I replace the spare pin with? An indicator LED? I'd add another pyro but I don't have an input left to run continuity checks from.

Thanks all!

You need to consider your desired final board size. This will be a compromise between the smallest rocket body size you want it to fit into and how easy you want it to be for people to populate with components. If you want a small board with a low profile, then SMD Rs and Cs are mandatory. You can also use both sides of the PCB if necessary, which will allow you to use the larger SMD footprints where higher density is required.

If people are getting value for money in terms of what your altimeter can provide in functionality, then they will likely forgive you for using lots of SMD components. Many people who are challenged by their lack of skill or experience with SMD components will hopefully know someone who is happy to help out.

Leave sufficient space clear of components for 3-4 3mm mounting holes around the board - not too close to an edge.

A spare pyro channel in a DD altimeter is often desirable, particularly for staging. If you don&#8217;t have a spare input channel for continuity, then you might be able to cleverly create one with a bidirectional I/O pin from your processor and also use it to drive a pyro FET. This line could also have an indicator LED for when it&#8217;s not used for pyro.

 

[OverTheTop]

Here is a suggestion. With the kit, also provide a small circuit board coupon that has pads to practice soldering on, and some extra resistors of appropriate size to practice with. You could even have some SOT23 size components (diodes are cheap) if you have that type of package on the actual PCA (they are one of the difficult packages to get soldered right). That way people can practice and get their soldering worked out before tackling the actual kit. Probably only needs to be no more than half or one square inch area.

I was going to suggest this to Cris at Eggtimer as well, so if you are listening Cris...

 

[LithosphereRocketry]

Thanks for the ideas everyone! I'm not going any smaller than 1206, because that's the smallest I want to solder...:wink:

It sounds like most people are OK with 1206 SMDs. My main goal was board width- the board with SMDs is now down to 1.25" by 3.2", so fits in a BT-55 coupler. It's kinda fitting actually- I built a BT-55 payloader specifically for my first Arduino altimeter project. That rocket never flew with its intended payload- there needs to be a law of electronics that however much space you have, you always need more- but it would be kinda neat to use it for its original purpose.

The idea of including a "practice" board is interesting. The PCB is by far the most expensive part right now, though, so that would drive the price up quite a bit.

Here's an idea for the spare pin- program switch button? The idea would be to load multiple flight configurations on your ArdIU and use that button to switch between them. That way you wouldn't need to ring a laptop for multiple flights... However, there wouldn't be a header for it. Tobor, was there something you needed the spare pin for? Pyros 1 and 3 are PWM...

I do have mounting holes, one at each corner on a 3" by 1" grid.

It's interesting, I was expecting SMDs to make routing harder, because they're only on one side, but it was actually easier- I just ran all the pyro connections that need to be beefy on top and put all the signal stuff underneath.

<moreshamelessadvertising class="thisiskindagettingrepetitive"> There are still 3 unclaimed beta boards- PM/post/email/whatever if you're interested! </moreshamelessadvertising>

 

[cerving]

Actually, 0805's aren't all that bad either. The trick is doing what we (Eggtimer Rocketry) do with our SMT pads... make them about .025" oversize on each end to give you more room to solder them. Doing that, you get a nice fillet of solder wicking up the end of the part. Without that extra pad room, you're trying to flow solder underneath the part... and half the time it doesn't quite get there. The "standard" pads (like you get in the Eagle libraries) are designed for reflow mounting, not hand soldering.

 

[LithosphereRocketry]

Interesting... Eagle gives me two 1206 SMD footprints, one "standard" and one that says "for wave soldering" with very narrow pads. Is the standard one good for hand soldering then?

 

[cerving]

The standard Eagle pads don't work well for hand soldering. I created custom pads with an extra .025" on each end (don't forget the solder mask and cream layers, too!)

 

[OverTheTop]

Actually, 0805's aren't all that bad either. The trick is doing what we (Eggtimer Rocketry) do with our SMT pads... make them about .025" oversize on each end to give you more room to solder them.

This is a significant difference between reflow work and hand soldering, and for purely hand soldering well worth doing. The extra pad size makes it greatly easier to hand solder. As the size of the resistors go down the pad "overhang" is deliberately reduced so that surface tension does not flip the component vertical during reflow, causing "tombstoning", due to slightly different heat at each end causing slightly different forces on the ends of the component.

If you look at 0402 components you will see the pad is basically the same outline as the part.

If you really want nice fillets on the end of the components you can add some finesse to your soldering by starting off with the iron (preferably chisel tip) laying down more (driving the heat into the pad) and then rotating it more vertical (more contact with the end of the component to drive the heat in there) before removing the iron. Remember what solder follows: flux, heat, and other solder. Remember those when wrangling solder and you will do well. Some people also count gravity on that list.

 

[LithosphereRocketry]

The standard Eagle pads don't work well for hand soldering. I created custom pads with an extra .025" on each end (don't forget the solder mask and cream layers, too!)

Do you have a copy of your Eagle library handy? If not I can always figure it out, but there's no sense reinventing the wheel... (Also, I'm lazy)

No need to go searching if it's not right there- I can look into it myself if it'll take more than a few seconds for you to find. No need to waste your time for a competitor's product...

 

[LithosphereRocketry]

The standard Eagle pads don't work well for hand soldering. I created custom pads with an extra .025" on each end (don't forget the solder mask and cream layers, too!)

Nevermind, Eagle libraries are way easier than I thought. Do you do all sides or just the ends? .025" is a lot...

 

[LithosphereRocketry]

I've had a busy few weeks but I'm on April break now, so back to work again.

I started on the IMU code earlier this week. It's still not working, but it's getting closer.

Liftoff detect, apogee detect, and pyro channels are done. Liftoff detect is useless, though, because the accelerometer doesn't work.

The board is also pretty close to done for the next ArdIU Beta run. I still need to add silkscreen but the copper is ready to go. Currently, the spare pin is being used as a utility button that can be programmed to switch configurations and whatnot.


Another beta board has been claimed, so 2 are still up for grabs. (See, that was useful, and not just a shameless ad... OK, it was mostly a shameless ad...)

 

[cerving]

Nevermind, Eagle libraries are way easier than I thought. Do you do all sides or just the ends? .025" is a lot...

Just the ends. Spacing parts reasonably far apart is a major part of our design PCB process... we can't assume that our customers have mil-spec soldering skills.

 

[LithosphereRocketry]

Just the ends. Spacing parts reasonably far apart is a major part of our design PCB process... we can't assume that our customers have mil-spec soldering skills.

OK, thanks, PCB footprints are updated.

In other news, the code is almost done. Accelerometer readings are working, as is liftoff detect. Barometric apogee detect is still a bit iffy, but it's getting there.

Still to do- tilt lockout and logging of accel/gyro data, and decent documentation. Getting closer! In the meantime, I'm having some hardware issues due to crappy soldering. Not a big deal, easy to fix, hopefully.

Is there anything people want out of an altimeter that I haven't at least talked about? Both flash memory and RAM are starting to get tight, so I may have to do some cleanup if there's a lot that needs to go in.