Next Generation Tilt Sensor/ Attitude Monitor

[SMR]

I am a huge fan of Frank Hermes' Rocket Tiltometer, which senses the attitude of rocket and prevents timer/altimeter based secondary events (airstarts, sustainer ignition, etc.) when the rocket's attitude exceeds a preset angle from vertical. If the preset angle had been exceeded at any point in the flight, the Tiltometer would not initiate the secondary event. A little bit pricey at $250, but worth every nickel when you consider the cost of a motor it would save, let alone your investment in the rocket that might be lost, or your liability should something dreadful happen. Unfortunately, they are no longer in production, and very few seem to surface on the secondary market. (Which is a true testament to their value - they are in permanent homes.) I wish I had bought more when they were available.

The only limitation with the original is that it kept the firing circuit on the board itself, so each Tiltometer could only fire one time. (i.e. the external trigger told the Tiltometer when to fire, and if the attitude was acceptable, the Tiltometer would then trigger a momentary current to the igniter.) If you wanted to fire multiple airstarts in sequence, it would require multiple Tiltometers.

My good friend and fellow FVR member Ed Chess has come with a novel solution to both problems, using an Arduino Pro Mini computer with a 6 axis accelerometer and two on-board solid-state relays. Software he wrote (called sketches in the Arduino world) allow the Arduino to continuously monitor the attitude of the rocket, and to hold the relay contacts closed as long as the orientation is acceptable. The ignition of subsequent events is therefore made by external triggers, with the relays only functioning to "consent". Ed is using the MissileWorks PET2+ timer for triggers, but it should work with any trigger that switches ground (using a continuous hot).

Initial introduction of the system was in a presentation at the Feb 2017 Northern Illinois Rocketry Convention in Woodstock, IL, and subsequent discussions on the NAR Facebook page, (follow this link). Ed was kind enough to provide me with the components to build one, and this thread will focus on its assembly, programming, and test flight, planned for early fall. Hopefully by then, this very useful device will have an equally cool name.

P.S. Anybody else here getting tired of auto-correct? Seems to have trouble with technical words. I typed airstarts about 20 times, TRF kept changing it to aristocrats. Really? Which word is more likely to be used on a ROCKET FORUM?

 

[djs]

I've met Ed at some of the FVR and WOOSH launches, and am very interested in using this for staging. I've never programmed (sketched?) an arduino before, but I'm sure it's in my capabilities to make this work with the pieces that Ed has graciously provided.

@Sather- you are an aristocrat of airstarts

 

[ekchess]

I'm a novice myself in microprocessors, having started learning about them a few years ago, but I do know how this circuit works, so I'll follow along with Sather's build and ensure that he doesn't lead you astray in construction and programming of the device. First clarifications (picky ones, I'll admit): the Arduino Pro Mini is really just a microprocessor, and not a fully computer like a Raspberry Pi, and the 6-axis accelerometer would better be described as 6-axis accelerometer/gyroscope breakout board that uses the MPU6050 chipset.

 

[BDB]

op: Subscribed....

 

[Crumb fire]

Subscribed too...

 

[markkoelsch]

Sweet. What would it cost to set one up?

 

[SMR]

I'm a novice myself in microprocessors, having started learning about them a few years ago, but I do know how this circuit works, so I'll follow along with Sather's build and ensure that he doesn't lead you astray in construction and programming of the device. First clarifications (picky ones, I'll admit): the Arduino Pro Mini is really just a microprocessor, and not a fully computer like a Raspberry Pi, and the 6-axis accelerometer would better be described as 6-axis accelerometer/gyroscope breakout board that uses the MPU6050 chipset.

I'm sure there will be quite a few more clarifications needed as I plow into this. I freely admit I know absolutely nothing about solid state electronics. While I have built guitar amplifiers and radios in the 70's (vacuum tubes), and have built over a dozen launch controllers in various configurations, my comfort level ends with mechanical switches and relays. I can solder two twisted wires together, but this will be my first venture into surface mounted stuff. That being said, I was in deep shock when I unboxed my bag of parts. This stuff is small! The picture on FB is many times larger IRL than the tiny stuff that fell out of the bag. So, my first concern for this thread is going to be image quality. I changed cameras a few years back, going with a wider aperture lens (77mm filter size) to allow a higher shutter speed for launch pictures. The loss of my smaller diameter lenses (58mm) also was the end of my closeup diopter set. I will do my best to take and post decent images. Lets see how that works...

Attached is a list of the parts I received from Ed. The three resistors are surface mounted devices (SMD), which is in itself an art requiring skills beyond my ability, so Ed was kind enough to attach them to the companion board for me in advance. The remainder came in an assortment of static resistant bags. Photo to follow.

 

[SMR]

First stab at pictures, admittedly poor (interior) lighting. Flash pix were worse, outside lighting will be better when weather improves.

First picture is the companion board itself. 3 resistors and one LED pre-installed. Measures approx 3" x 1 1/8". Second picture is the complete set of parts, listed from left to right (and top to bottom) are...

- the companion board
- 6-pin terminal block
- 4-pin terminal block
- solid state relay
- solid state relay
- Arduino Pro Mini (circuit board)
- 6-axis accelerometer / gyro (circuit board)
- 3 DIP switch block
- assorted connector pins

 

[SMR]

Better images of the companion board are from the source

https://oshpark.com/shared_projects/Xa8MRGnW

 

[SMR]

For those who wish to get ahead of my admittedly slow work, Ed has already posted instructions for assembly on GitHub.

https://github.com/ekchess/PET2_Companionv7

I will be following those instructions in slow motion as this thread evolves.

View attachment CompanionBoardv7schematic.pdf

 

[mikec]

For those who wish to get ahead of my admittedly slow work, Ed has already posted instructions for assembly on GitHub.

This is awesome. I'm a little surprised that it makes very heavy use of the MPU-6050's internal Digital Motion Processor to get integrated roll/pitch/yaw out of the 6050's gyros. The DMP presumably hasn't been optimized for rocket applications. Does Ed have a lot of flight experience with this system?

 

[SMR]

This is awesome. I'm a little surprised that it makes very heavy use of the MPU-6050's internal Digital Motion Processor to get integrated roll/pitch/yaw out of the 6050's gyros. The DMP presumably hasn't been optimized for rocket applications. Does Ed have a lot of flight experience with this system?

He has had three (100% successful) flights that I know of.

 

[dhbarr]

Definitely very interesting!

 

[ekchess]

Yes, the board has been through several revisions as perfboard, an earlier OSHPark board (Rev 3), and now this one (REv 7) from OSHPark. All flights have been successful, although, admittedly, it hasn't been challenged by an errant flight yet. It works well at the bench, though, and I know the relays have shut off when the tilt exceeded the critical angle because the relays are off when I recover the rocket. I used the DMP to get integrated roll/pitch/yaw because it was an easy path for programming. You need to calibrate the accelerometer and gyro once the board is assembled. I've been using one board for over a year, and the calibrations are holding well enough to still work. Over time, though, the gyro cals will slip, and you'll likely need to recal. I'll look into adding some code for that sometime so a recalibration could be done without loading new software as would be needed with the current sketch. Even though the DMP hasn't been optimized for rocketry, I did testing on the MPU-6050 breakout board to ensure the readings for yaw/pitch/roll were being properly calculated during the high gees of boost (built an Arduino Uno shield containing the MPU-6050 and a FRAM chip to record the data on boost).

 

[SMR]

The assembly instructions as posted on GitHub start ...

1. Tape the PC board to work surface face up to mount all SMD components. Since the three resistors are located underneath the Arduino Pro Mini, they must be placed first.
2. Solder the three surface mount resistors, R1, R2, and R3 at positions marked.
3. Solder the LED in place taking care that the LED polarity is correct. The cathode (negative) side is marked on the LED, and the positive side is marked on the PCB.
4. Check the circuit connections for the four SMD components using a DVM to ensure there are no shorts or open circuits. This is important because once the Arduino Pro Mini is in place, you cannot rework the resistor solder joints.

Since the board was delivered with the 3 resistors and the LED already in place, I can begin with step 4 of the instructions. Using a digital multi-meter, I confirmed that there were no shorts or open circuits. The resistors were correctly placed and read 559, 559 and 220 ohms, respectively.

 

[SMR]

All flights have been successful, although, admittedly, it hasn't been challenged by an errant flight yet.

One of my plans for testing prior to the big event is to fly her in a testbed rocket with triggers set to a variety of conditions (post apogee, etc) to confirm her proper operation. If I was smarter, there must be a way to strip data off the Arduino in real time and save it to a chip for post-flight analysis. Way beyond my abilities, though.

 

[SMR]

Continuing with the assembly instructions...

5. Solder the 6-pin header to the Arduino Pro Mini so the long pins extend above the board. This header will serve as the serial interface to the programming computer.
6. Solder two 12-pin headers to the Arduino Pro Mini so that the long pins extend below the board.
7. Solder the 2-pin header into the companion board PCB into positions D4/D5 such that the long pins extend below the board, and the plastic header is on top of the board. Trim the long pins close to the board on bottom.

Notes - In the parts bag were five pin connectors, specifically...

8 pin x 90° angle
6 pin x 90° angle
8 pin straight
18 pin straight
19 pin straight

The instructions call for a 6-pin, a 2-pin, an 8-pin, and two 12-pin connectors. The plastic header (spacer / insulator) has grooves between the pins to easily cut the headers to the appropriate pin lengths. The 8-pin straight can be used as is, and I cut a 6-pin and a 12-pin from the 18-pin, and another 12-pin and a 2-pin from the 19-pin. This left an extra 5-pin and the two angled connectors for a future project. (Hey, maybe I'll get around to starting my Peggy2.) Soldering was straight forward, using a simple soldering iron on low (20 watt) setting. Soldering is a bit of an art, best to practice on something disposable before committing to the expensive parts. (Which is why I never started the Peggy2.)

I started with the 2-pin connector in step 7. Which was a good thing, 'cause I had a lot of mis-steps on a rather steep learning curve. (a) I used too much solder and got solder between the pins, connecting them. (b) I then tried just heating the pins and blowing off the excess solder, which then went into another (unintended) hole in the printed circuit board. (c) Finally, I got the pins so hot they pulled right out of the plastic header. Thankfully, I had that extra straight piece to cut another 2-pin section from. Then back to steps 5 and 6. Eventually I got into a kind of rhythm, just long enough for a little bit of solder to flow across the base of the pin.

pictures to follow...

 

[jeff2space]

Subscribed, very interesting.

 

[mikec]

Even though the DMP hasn't been optimized for rocketry, I did testing on the MPU-6050 breakout board to ensure the readings for yaw/pitch/roll were being properly calculated during the high gees of boost (built an Arduino Uno shield containing the MPU-6050 and a FRAM chip to record the data on boost).

I did a quick skim of your code and the Rowberg library and it appears to me that dmpGetYawPitchRoll uses the accelerometer values as a reference axis, which isn't what you want to be doing during boost since the "gravity" vector will be along the thrust line regardless of orientation. I would think that to validate this completely you'd have to have some other source of tilt data to compare your results with -- maybe magnetometer data or some other IMU? I've done some flight testing of a system using the Sparkfun Razor where I integrate the gyro rate data in the Arduino.

Don't intend to be negative, just want to be helpful any way I can -- this is a really exciting development that could improve launch safety for multistage flights at cost low enough that most people could use it.

 

[cerving]

Along those lines, you might want to use the accelerometer on the ground to get the initial tilt angle (you can do that pretty easily since it's 3-axis), then use the gyro to modify that tilt angle over time after you detect liftoff. Since this essentially being used for airstarts and/or separation and we're talking only a few seconds, you probably don't need to worry too much about gyro drift... use whatever value you got right before liftoff as your "zero" and go from there. Of course, if the DMP is doing all the work for you, that's all the better.

 

[mikec]

Of course, if the DMP is doing all the work for you, that's all the better.

That's my concern, that the DMP is using the accelerometer inputs under thrust to "correct" gyro drift as though thrust was gravity -- if true that would defeat the whole purpose. I can't tell from the fairly minimal DMP docs I've been able to find online so far exactly how it works.

 

[SpaceManMat]

My concern with allowing multiple events would be situations where the tilt was too far off of the first event but ok for the second. Once you miss an event you need to lockout any further events otherwise weird things mat happen.

 

[Banzai88]

I need to follow this, looks like an exciting development that could open up multi-stage flights to a whole lot of folks.

 

[cerving]

That's my concern, that the DMP is using the accelerometer inputs under thrust to "correct" gyro drift as though thrust was gravity -- if true that would defeat the whole purpose. I can't tell from the fairly minimal DMP docs I've been able to find online so far exactly how it works.

I was thinking of that this morning, the accelerometer on the MPU6050/9250 is only good for 16G... it's gonna get pegged. That's why my original thought that it's better to use the accelerometer for the initial tilt calculation on the ground and for launch detect may be a better solution. It's nice to have the chip do things for you, but if you don't know exactly what it's doing and how it's doing it, then you may better off doing it yourself with the raw data.

 

[SMR]

My concern with allowing multiple events would be situations where the tilt was too far off of the first event but ok for the second. Once you miss an event you need to lockout any further events otherwise weird things mat happen.

I believe that is what it does... Both relay contacts are held closed as long as attitude is okay, and held open for the duration of the flight should things go awry. So, if event 1 is prevented, event 2 is also.

 

[ekchess]

My concern with allowing multiple events would be situations where the tilt was too far off of the first event but ok for the second. Once you miss an event you need to lockout any further events otherwise weird things mat happen.

Yep, the current code locks out the relays once the critical angle has been exceeded.

 

[SMR]

Progress update. I am through step #10 of the instructions and have the 3 printed circuit boards attached to each other. Basically, the companion board is sandwiched between the Arduino Pro Mini and the GY-521 boards. They are (or should be) parallel to each other. The Arduino is supported along both edges, while the GY-521 is cantilevered out from one side, so take care not to break it in handling. It will be safely tucked in under the board once installed on a sled with stand-offs.

8. Solder the Arduino Pro Mini to the companion board, ensuring that all 26 connections are made. Trim leads close to board on bottom.
9. Solder 8-pin header to the GY-521 board so that the long pins extend to the bottom of the board.
10. Solder the GY-521 board to the underside of the companion board as depicted in the silkscreen. Ensure that the two boards are parallel to each other

The next steps are to attach the solid state relays, DIP switch(es), and terminal blocks to the companion board. Also planning the finished sled, to use 3 POPO switches in the same configuration as my Tiltometer sled, so they can be used interchangeably. But since this will be starting clusters in addition to sustainer motors, I am adding 2 clustomatics from Whooshtronics (great product:smile:, also discontinued:cry. Since plans call for starting up to 6 motors, and I have some concerns about the amperage limitations of the solid state relays, this will move the high amperage ignition circuit from the companion board to the Clustomatic, as well as meter out proper current to each individual igniter and not allow one short from stealing all the electrons.

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

 

[ekchess]

I was thinking of that this morning, the accelerometer on the MPU6050/9250 is only good for 16G... it's gonna get pegged. That's why my original thought that it's better to use the accelerometer for the initial tilt calculation on the ground and for launch detect may be a better solution. It's nice to have the chip do things for you, but if you don't know exactly what it's doing and how it's doing it, then you may better off doing it yourself with the raw data.

I very much appreciate the feedback on how the DMP may or may not be working, because there are parts of it that Jeff Rowberg couldn't figure out either, and that guy's a genius in my book. I don't currently have the programming chops to sort this out beyond using the DMP, so I'm very open for someone to work through the code, using the MPU6050 board to keep the circuit design the same, and implement Cris's suggestion to use the accelerometer to calibrate the gyros, detect launch, and then let the gyros do the work in flight to monitor tilt. In the development of the RocketTiltoMeter by Frank Hermes a few years ago, the gyros were used this way, and were corrected for rocket spin by use of a magnetometer, which, unfortunately, is not on the breakout board I used. In the RocketTiltoMeter instruction manual, it states that an "Efficient, attitude-transformation-specific Direction Cosign Matrix (DCM) algorithm is used rather than generalized Kalman filter determination which provides fast response with no null solutions". That would be good, as the yaw/pitch/roll function I'm accessing here does suffer from gimbal lock, although I haven't experienced that in testing. I agree that improvements to the code are needed to make this device work better, and I'm very open to collaboration. After all, this is an Open-Source project to improve HPR safety. Thanks, everyone, for the interest and help.

 

[SMR]

Continuing with the assembly...

11. Solder the two SSRs to the companion board as marked. Ensure the proper orientation of the ICs as marked on the silkscreen.
12. Solder the 3-position DIP switch to the companion board. Ensure correct orientation of the DIP switch as marked on the silkscreen.
13. Solder the 4- and 6-pin screw terminal blocks to the companion board. Ensure the correct orientation of the terminal blocks (open side faces to edge of board).
14. Trim any soldered leads close to board. This completes the assembly.

Next step is Programming and Calibration of GY-521. Awaiting on an adapter since this flavor of Arduino does not have a USB port.

 

[cerving]

The MPU9250 board DOES have a magnetometer, but if you think about it you don't really need it. You aren't trying to figure out which direction your rocket is pointing, just what the tilt is. Using the accelerometer to give you the tilt on the pad and the gyros to correct it in flight is the easiest way to do this, and it's not dependent on the velocity or acceleration of your rocket. For that matter, you don't need to worry about the z-axis gyro either, it doesn't affect the tilt.