ArdIU - Open source flight computer w/ ATMega328

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Never mind about a few weeks, OSH Park upgraded me to the fast panel for free because they had a few square inches of space free... That panel ships within 5 business days. :w:

However, I won't be able to do much assembling as of yet, as the electronic parts are still on the way from China... So I'll have something in a week or 2 but no assembling will happen for a bit after that.
 
The EEPROM thing combined with my current setup was kinda what I was thinking, and I'd love to be able to use the built-in brownout detection. However, I have two questions/concerns-

- It seems I have to modify the Arduino bootloader to enable brownout detection. This isn't something I've done before, and I'd like to avoid it if at all possible. However, if I can make minor modifications and end up with a more reliable altimeter, that would be fine.

- How is a brownout any different from simply disconnecting the power and reconnecting for the next flight? If you have to hit the reset button every time that's really no better than having a separate key.


About electronic deployment- I was under the impression that those under 18 can't do electronic deployment, going by this bit of text from the NAR Jr certification page:


If electronic deployment is allowed but the BP has to be purchased by an adult, then I'd love to set up an electronic deployment system to test the ArdIU. However, I would have thought that the NAR would include something about that possibility if it were the case.

Don’t read more into the certification requirements than what is written.
Until you’re 18 your HPR motors and your BP must be purchased and handled by an adult, but that doesn’t mean you can’t fly dual deployment.
 
Don’t read more into the certification requirements than what is written.
Until you’re 18 your HPR motors and your BP must be purchased and handled by an adult, but that doesn’t mean you can’t fly dual deployment.

Tripoli and NAR handle this a bit differently. Tripoli allows mentored flights within the certification and competence level of the mentor. The TRA mentor is charged to 'ensure that every rocket used in a mentored flight is built with the level of skill necessary for the project'. If you can build it and demonstrate to your competent & qualified mentor (who should be monitoring the build, much like a TAP monitors a level 3 project), your mentor can allow you to fly it.
NAR's web page states as of their 2009 rules revision:
  • "Qualifying junior members at this level permits them to fly single or multiple motor rocket flights with motors having a maximum total impulse of 640.00 Newton seconds.

    The qualification flight and all future flights must be single deployment only. This is due to regulatory requirements of ejection charges used in dual deployment systems. On board electronic devices are permitted as long as they are not used for deployment.

    As models with hybrid motors require regulated ejection methods, they are not permitted to be used by the Junior HPR Level 1 Participant at this time"

Please correct me if there is a more recent revision to the NAR program.
 
Tripoli and NAR handle this a bit differently. Tripoli allows mentored flights within the certification and competence level of the mentor. The TRA mentor is charged to 'ensure that every rocket used in a mentored flight is built with the level of skill necessary for the project'. If you can build it and demonstrate to your competent & qualified mentor (who should be monitoring the build, much like a TAP monitors a level 3 project), your mentor can allow you to fly it.
NAR's web page states as of their 2009 rules revision:
  • "Qualifying junior members at this level permits them to fly single or multiple motor rocket flights with motors having a maximum total impulse of 640.00 Newton seconds.

    The qualification flight and all future flights must be single deployment only. This is due to regulatory requirements of ejection charges used in dual deployment systems. On board electronic devices are permitted as long as they are not used for deployment.

    As models with hybrid motors require regulated ejection methods, they are not permitted to be used by the Junior HPR Level 1 Participant at this time"

Please correct me if there is a more recent revision to the NAR program.

You are correct. The NAR Jr. L1 program specifically prohibits a Jr. L1 flyer from flying dual deployment during or after certification, until their 18th birthday. I was wrong. [emoji17]
And yes, the Tripoli mentoring program would allow him to fly dual deployment, but he would still have to have an adult prepare the motor and handle the BP.
 
You are correct. The NAR Jr. L1 program specifically prohibits a Jr. L1 flyer from flying dual deployment during or after certification, until their 18th birthday. I was wrong. [emoji17]
And yes, the Tripoli mentoring program would allow him to fly dual deployment, but he would still have to have an adult prepare the motor and handle the BP.

OK, that's what I thought. Guess I won't be testing DD capabilities after all. :sigh:

However, what I can do is have some kind of visual "charge" that doesn't actually do anything functionally- anybody know if a Christmas light is visible at 1000ft?

This also brings up an interesting point. I'm planning on testing with staging to get around the "no BP" rule, and many clubs require a tilt lockout when possible (not mine AFAIK, so this is just a thought experiment.) The ArdIU can do tilt lockout with its MPU6050 IMU, however, if the motor locks out, I don't get an ejection charge. So which is preferable- the upper stage igniting off center and traveling for miles, or not igniting at all and lawn darting? I would assume any parachute is better than none, but I'd be interested to see what people think.
 
However, what I can do is have some kind of visual "charge" that doesn't actually do anything functionally- anybody know if a Christmas light is visible at 1000ft?

I sincerely doubt it, especially in daylight, they're often barely visible from tens of feet during the day. But is the rule strictly against BP? I'd wonder if you could set off e-matches even if they didn't have any BP, then you could at least see if the matches fired. But I haven't read any of the rules, just asking questions.
 
I sincerely doubt it, especially in daylight, they're often barely visible from tens of feet during the day. But is the rule strictly against BP? I'd wonder if you could set off e-matches even if they didn't have any BP, then you could at least see if the matches fired. But I haven't read any of the rules, just asking questions.

I think the regulation is because BP has to be handled by adults, so an ematch taped to the side or something would be OK- not sure though. Here's an interesting idea- many reload manufacturers are OK with people putting foreign objects in their BP wells. So can I legally use the BP well on a reload as a charge well as a backup- similar to what I've seen people do with 2 matches per charge? The idea would be to drill a hole in the little red cap (or poke a hole in the paper with CTI) and stick an ematch in that, with some kind of breakaway connector to the ArdIU.

The first step of course would be to just fly it "dry" and record on the SD card when charges "fire".
 
Question: Do the rules regarding BP for Jr. fliers also include BP alternatives like Mr. Nakka's Crimson Powder?
 
Before I get into deployment of any kind, I need to build an altimeter. Speaking of which, my PCBs came in the mail today. Very nice quality, I'll post pics soon.

Now to wait another week or two for the rest of the parts...

Sent from my LGL44VL using Tapatalk
 
So I got the prototype altimeter assembled over the last few days. Came out pretty nice:
0121181347.jpg0121181404.jpg

I first built it without breakout boards and tested it, then added the boards afterward, just in case I needed to fix something.

My comments:
- Several footprints were mis-sized, most significantly the SD breakout. I can work around it but it's annoying enough that I'm going to want new footprints for the first beta run.
- The polarity on the LEDs was very hard to see. I was using Sparkfun's library for these- I'll switch to the Adafruit footprint, which is much clearer, in the future.
- Most of the info text on the back was practically invisible. Easy fix.
- The programming header was set up backwards. I can work around it by just flipping the programmer, it's just not ideal.
- I'm planning on running the entire board at 3.3V with internal clock on the next iteration. I found a high-efficiency version of the 1117 that can run 3.3V off of as little as a 2.5V input, so I can run 1S LiPos- I have quite a few lying around.
- I'm also planning on moving the SD card from a breakout board to a standalone holder. I just need to find one that's reasonable to solder...
- Several bugs in the Arduino library have been worked out- mostly related to the annoying way C handles floats- float x = 1/2 will give zero because the 1/2 part is reading as an int. float x = 1.0/2 fixes it. Still have a lot more to go there.

Two quick polls-

How much interest is there in a beta run once all of these issues are taken care of? OSH Park sells boards by 3's so I'm planning on getting 6- one for myself and if that goes well 5 beta kits. Beta kit price would probably be around $30-40, and gain you my undying gratitude, your name/handle on the production board, and first pick at debugging help and/or code customization, plus maybe more stuff.

For datalogging, which would be more useful by default- CSV or TSV? I can make it configurable, I'd just be interested to know what people prefer.

Thanks for all the interest!
 
Congrats on such a cool project! For my arduino data logging payloads, I always use CSV format. Doesn’t make a bunch of difference, I use Excel and MatLab for data analysis and both probably wouldn’t care TSV vs CSV. I notice to that most other altimeter manufacturers use CSV also.

You could count me in for getting more info on a beta-run.


Sent from my iPhone using Rocketry Forum
 
For datalogging, which would be more useful by default- CSV or TSV? I can make it configurable, I'd just be interested to know what people prefer.

Binary. You can always mangle it into CSV later if you want.

It is easier and faster for the micro-controller to deal with. One big problem with using an SD card is that there can be long delays while writing a sector. (The SD card specification says up to 750ms!) If you don't want to lose data you must be able to buffer that much data. Since RAM is at a premium in most micro-controllers, using an ASCII format is going to make this problem worse. You have 2K of RAM so at best you have space for three 512B buffers. Which limits you to 1.5KB/750ms = 2KB/sec. I figure that gives you about 32SPS with an ASCII format while binary would be around 4 times that.

This assumes that you know how to write code for the Arduino that can gather/process data while the data write to the SD card is in progress. If you don't, then you are going to lose data no matter how much buffer space you use.

Even skipping a file system like I do doesn't completely eliminate the delays although it does reduce them.
 
I might be interested in a Beta board. What kind of time frame for feedback are you considering? And how often?
 
Binary. You can always mangle it into CSV later if you want.

It is easier and faster for the micro-controller to deal with. One big problem with using an SD card is that there can be long delays while writing a sector. (The SD card specification says up to 750ms!) If you don't want to lose data you must be able to buffer that much data. Since RAM is at a premium in most micro-controllers, using an ASCII format is going to make this problem worse. You have 2K of RAM so at best you have space for three 512B buffers. Which limits you to 1.5KB/750ms = 2KB/sec. I figure that gives you about 32SPS with an ASCII format while binary would be around 4 times that.

This assumes that you know how to write code for the Arduino that can gather/process data while the data write to the SD card is in progress. If you don't, then you are going to lose data no matter how much buffer space you use.

Even skipping a file system like I do doesn't completely eliminate the delays although it does reduce them.

Hmm, now that's a thought... What I could do is have it write to a binary file during boost, and then revert to CSV as well during descent, when it doesn't have to sample nearly as often. I'd be planning around a 32B per frame sample width:
-4B timestamp (unsigned long)
-2B altitude (unsigned float)
-6B axial acceleration (3 floats)
-8B orientation (calculated by the IMU; quaternion- 4 floats)
-12B spare for other things- e.g. pin states, raw readings, etc.

I can also change the sizes of the floats for more or less precision as I see fit- for example, the current scheme maintains 1m stored accuracy up to 2km and 32m accuracy well past the Karman line, but switching to double precision would vastly improve that.

I do want to keep the card in a file-formatted state though for ease of debugging- also, then if you crash and damage your altimeter, you can still recover data relatively easily. I'll have to run some performance tests to see what the delays will look like.

I might be interested in a Beta board. What kind of time frame for feedback are you considering? And how often?

I don't really have any formal plan for feedback at the moment- basically, I want to know how well it works and any improvements you'd suggest. Any feedback is welcome!

Glad to see there's interest! I'll get working on the beta PCB & library when I have a bit more time.
 
Floats are 4 bytes.

A long int (4 bytes) has more than enough precision for most of your data.
 
Floats are 4 bytes.

A long int (4 bytes) has more than enough precision for most of your data.

C data widths are adjustable based on the device and OS. On Arduino "standard precision" is only 2 bytes, "long" is 4. On most "normal" devices standard is 4 bytes, long is 8- Arduino uses less because of the low specs of the chip.

I think floats make the most sense in terms of accuracy- the accuracy drops at high altitudes, where you don't care as much anyway. An (unsigned) int would wrap at 65km, a reasonable range for some extreme projects, but nobody's gonna break the upper bound for a float- 4 billion meters, well into interplanetary space.
 
C data widths are adjustable based on the device and OS. On Arduino "standard precision" is only 2 bytes, "long" is 4. On most "normal" devices standard is 4 bytes, long is 8- Arduino uses less because of the low specs of the chip.

I think floats make the most sense in terms of accuracy- the accuracy drops at high altitudes, where you don't care as much anyway. An (unsigned) int would wrap at 65km, a reasonable range for some extreme projects, but nobody's gonna break the upper bound for a float- 4 billion meters, well into interplanetary space.

"int" defaults to 16 bits, "long" to 32. (if portability is a concern and type widths matter, I like to use the types in stdint.h: int16_t, int32_t, etc.) "float" is 32 bits. Double is usually 64 bits but I haven't seen an Arduino implementation that supports that. (MAXFLOAT (see math.h) is much greater than 4E9, more like 3.4E38).

And there is not much reason to record anything other than the raw sensor data. Let your fancy Intel/AMD processor do the conversion to engineering units later.

Even if the altimeter is controlling deployment there is rarely any reason to convert from the raw sensor value. They only one I can think of is when using a Kalman filter and you must have altitude and acceleration in compatible units.
 
"int" defaults to 16 bits, "long" to 32. I agree. (if portability is a concern and type widths matter, I like to use the types in stdint.h: int16_t, int32_t, etc.) "float" is 32 bits. You're right, now that I look... I assumed everything would follow the same width standards... Apparently not. Depending on write speed constraints I can either widen the sample size or use a short float. Double is usually 64 bits but I haven't seen an Arduino implementation that supports that. (MAXFLOAT (see math.h) is much greater than 4E9, more like 3.4E38). I was going by the 5 bit exponent for a "short" float. Now that I actually read the **** manual (i.e. Arduino reference) I see that a float is the same length as a long...

And there is not much reason to record anything other than the raw sensor data. Let your fancy Intel/AMD processor do the conversion to engineering units later.

Even if the altimeter is controlling deployment there is rarely any reason to convert from the raw sensor value. They only one I can think of is when using a Kalman filter and you must have altitude and acceleration in compatible units.
Fair point- however, I'd be concerned about loss of precision across various widths, especially with things that integrate and therefore are subject to huge errors from tiny imperfections. Additionally, the MPU-6050 has support for on-chip data processing, which runs MUCH faster and more accurately than any other option.

Again, thanks for the help, everyone! I really appreciate all the ideas!

I will get the beta boards sent to the fab as soon as I can... While they're processing I'll chew away at the Arduino library. So much to do! bandman444, Tobor, I'll try not to keep you waiting too long... It'll be a month or so at minimum though- just printing the PCBs takes around 3 weeks.
 
C data widths are adjustable based on the device and OS. On Arduino "standard precision" is only 2 bytes, "long" is 4. On most "normal" devices standard is 4 bytes, long is 8- Arduino uses less because of the low specs of the chip..

I was just correcting you on the size of floats in the standard Arduino library. Floats are 4 bytes, so are doubles, no difference in precision.

https://playground.arduino.cc/Code/DatatypePractices

However, UhClem is right, you do not need to use floating point in an altimeter, especially one that is using an 8-bit processor. You can do everything you need with fixed point integer math. It will run alot faster too and use much less program memory.
 
However, UhClem is right, you do not need to use floating point in an altimeter, especially one that is using an 8-bit processor. You can do everything you need with fixed point integer math. It will run alot faster too and use much less program memory.

Personally I would stick with the floats if you have the processing power during flight. I have seen people stuff up integer and fixed point integer maths, just because they are not used to it. You can be clever writing code, but if it is not understandable or maintainable then you should probably consider doing it differently. YMMV.

BTW, I used integer maths to calculate Pi to 10,000 decimal places back in the late 70's, just for fun, when I was a teenager :wink:
 
Personally I would stick with the floats if you have the processing power during flight.

I would agree that if you have an ARM or similar you can trade off bloated code and clock cycles for an easier program.

But the OP is using an AT328P which is an 8 bit processor and 32kb of code space. I am guessing that the quaternion multiplies and normalization for the IMU functions is going to use ALOT of clock cycles and code space using the GNU floating point library on an 8-bit machine. It may be hard to fit all the other desired altimeter functions in there. Also he programming in the Arduino library not native, there is some extra overhead there.
 
I would agree that if you have an ARM or similar you can trade off bloated code and clock cycles for an easier program.

But the OP is using an AT328P which is an 8 bit processor and 32kb of code space. I am guessing that the quaternion multiplies and normalization for the IMU functions is going to use ALOT of clock cycles and code space using the GNU floating point library on an 8-bit machine. It may be hard to fit all the other desired altimeter functions in there. Also he programming in the Arduino library not native, there is some extra overhead there.
Yes, my processor is slow as ****- and I had to drop to 8MHz to run at 3.3V, so it's even slower- but all the integrating is being done onboard by the IMU itself. It's not a well documented feature but the library I use supports it. (Thx Jeff Rowberg!)

Sent from my LGL44VL using Tapatalk
 
Yes, my processor is slow as ****- and I had to drop to 8MHz to run at 3.3V, so it's even slower- but all the integrating is being done onboard by the IMU itself. It's not a well documented feature but the library I use supports it. (Thx Jeff Rowberg!)

Sent from my LGL44VL using Tapatalk

Even if you had to do the integration on the AT328P its not impossible. I use the Arduino IDE and can get SD card data logging of gyro/accel/baro, dual-deploy, 2-stage functions, and quaternion tilt-lockout all on the AT328P. That said, I'm using 75% of RAM and 99% of Flash, so it BARELY fits, but it fits.
 
Back
Top