martinjaymckee
Well-Known Member
- Joined
- Mar 14, 2015
- Messages
- 61
- Reaction score
- 0
I thought that I'd show people what I've been working on recently in the area of rocket electronics. I'm working on developing a high-speed data-acquisition flight computer. I decided ( on a whim ) to call it the TinyTIM ( Tiny Timing and Instrumentation Module ). It's basically just a flight computer. The only real "innovation" is that this first version will be able to sample most of its sensors at 500Hz. The available sensors on the board are:
MPU6050 ( with 3-axis, 16-g, accelerometer; and, 3-axis, 2000 deg/s, gyroscope )
ADXL375 ( 3-axis, 200g, accelerometer )
MS5611 ( 24-bit, barometer/altimeter )
HMC5883L ( 3-axis, magnetometer, which I'll not be using in the first versions )
All of the sensors except the magnetometer would support 500Hz. The magnetometer is something of a dog, at 80Hz max. In any case, I may not use it for anything. It just happens to be on the board.
I'm actually using breakout boards for the sensors while I'm working out a first version of the software, here's the setup:
Working from right to left, the first board is a USB-Serial converter that is being used -- initially -- for debugging output and power ( the 5v from USB ). Eventually, of course, this same serial connection will also be used for configuration and data download. Above the breadboard is the JTAG interface I'm using to program/debug the processor on the TinyTIM. The middle two boards are: above, the IMU breakout board, and, below, an accelerometer breakout board. Most of the sensors are on a Chinese IMU sensor breakout board, the GY-86. They are readily available and inexpensive. The GY-86 carries the accelerometer/gyroscope, the magnetometer, and the barometer. The secondary accelerometer is on a board I designed ( just to see if I could hand solder the blasted things! And yes, I was, indeed, successful
). Since It was a soldering test, mostly, I have an ADXL343 on the board. It has the same interface as the ADXL375 that I would use in flight, but it is cheaper ( about half the price ) so I decided to use it for the soldering test and ground testing. The last bit, all the way to the right on the breadboard, is the TinyTim itself. It's actually designed for the GY-86 to be back mounted. This is the v0.1 TinyTIM board which didn't have a spot for the secondary accelerometer. Later versions mount that as well ( on a board the same size ).
The board features a 32-bit ARM microcontroller, two deployment events outputs ( the drive MOSFETS are not currently mounted, however, they will be good to about 10A ), a built-in magnetic switch, and 16MB of storage memory. Additionally, the board has the serial interface and two GPIO pins that can be configured as either digital input/output or analog inputs with a range of 0-3.3 volts. The board itself is 21mm x 45mm, around the same size as an Eggtimer Quark or the Featherweight Altimeters Raven ( that I'm still lusting over! ). It's not targeted to compete with current flight computers, I have one, fairly specific, goal in mind for this one -- blazing fast acquisition rates. Missing, at the moment, are separate deployment and logic batteries, a buzzer, a couple of GPIO ( I'd like to have four, at least ), and an on-board button for configuration/testing. I'm not sure that I'll ever add the "missing" items though. I'm not designing this to be a "kitchen-sink" flight computer.
As I said, it's a fairly standard flight computer. It does have a couple more sensors than usual, but, the real kicker is the sampling rate that should be possible. The version above -- v0.1 -- has all of the sensors on the I2C bus and the sample rate target is 500Hz continuous ( which will fill the memory in about ~400sec. ). The final goal, however, for a real version 1.0 board is to have barometer sensing at 700Hz and the gyroscope and accelerometer sensing at 2.1kHz. That will necessitate moving the sensors over to an SPI bus ( and putting them on my board, as the GY-86 doesn't break out the pins needed for an SPI interface ). At that speed, the memory will only last for a bit under a minute-and-a-half, but it will have stored a whole ton of data. I like data!
The sensors are all of fairly high resolution ( 24-bits on the baro, 16-bits on the magnetometer, gyro, and accelerometers ), so after calibration, the data will be clean. Clearly, though, the high data rate is going to mean a fair amount of noise in the system. As such, later work is going to be going towards developing software that can process the data to it's best effect. Also, I've got some ideas about how I want the deployment events to work. I like everything to be flexible ( some would say, too flexible ), so I'm planning to have a number ( likely sixteen ) of programmable events of different types: comparison events ( against values in the system ), timer events ( for expiration of a timer that can be started by another event ), boolean events ( to combine other events ), and maybe others. Setting up deployment actions would be based on these events. Of course, the actions would be configurable too. Once again, lots of work will need to go into PC software to make all this work. And, because it would be such an involved setup of the system, I think that a ground-test facility is absolutely necessary. I'd be tempted to integrate it into OpenRocket, but that might be a bit more than I really want to undertake. In any case, I'll need some way to do a complete simulation of a whole flight to check the configuration.
Some other thoughts on features that I would like to include -- with the same basic flight firmware and possibly different hardware -- are: telemetry ( actually, with an external radio, this board could do this just fine ), GPS tracking, more deployment/staging outputs ( and safer outputs... the current design has almost zero protection ), more inputs and outputs. My goal for the TinyTIM is to keep it small enough to fit in a 24mm tube, and for a more complete version to fit in a 38mm ( or, if I'm really good, 29mm ) tube.
It's a fairly ambitious project ( if only for the data-rates involved in both sensing and streaming to the memory ), but it's coming along fairly well so far. I don't have much to show at the moment, as I've just been assembling the hardware, doing very basic electrical tests ( it didn't blow up when I connected power check; it does turn on check; etc. ), and writing a first version of the libraries to communicate with things, and it's working. I can read from the sensors and talk to the computer. The SPI, as well, seems to be working though I have yet to actually do a write/read test with the memory. I've actually got quite a bit more work to do on the memory interface because I need to get that working with DMA ( direct memory access ), so that writing data to memory is done mostly without processor intervention. Otherwise, I won't be able to make the loop timing.
So, thinking about time frame here. I've got a version 0.3 board at the fab right now and I should receive it in a week or two. I'm hoping to have all the components I need for that before hand and most of the test code done so that I can have a working device by mid-May. I've already got the two mule airframes built ( just waiting on final markings and parachutes ).
They are nice and small -- based on BT-55 tubing -- so they should be able to loft the the test payload I have in mind ( an Eggtimer Quark along with the TinyTIM ) to nearly 275 m on just an Estes D12-7 ( the mule can also easily handle an E12, E15 or even F50 ) should make for an inexpensive and flexible flight program. Once I can actually fly it in recording mode ( with the basic lift-off triggering in place ), I'll do a half-dozen flights for sensor checking and so forth, then start working on the next major piece of this whole thing the flight software. Version 0.3 is going to upgrade the processor speed from 24MHz up to 72MHz ( max ) and the data memory from 8kB up to 36kB, so it should allow for many more capabilities than I had originally intended for this small board. I'd guess I might have a really functional Version 0.3 with flight software and a basic computer-based interface in about six months ( another couple dozen flight tests too, of course, without actually activating any flight events ). Then I'll build a new mule for dual-deploy tests and do a series of a half-dozen or so. By that time I should have enough information to do a solid redesign of the board, moving all the sensors on-board, and possibly doing another processor upgrade for expanded memory and processing rate. Then another couple of months to finalize the firmware and computer interface. If I'm lucky, I'll have it all done by December, just in time to start thinking about using it for an R&D project for NARAM 2017.
Oy!
Any thoughts or comments are greatly appreciated. This won't be a quick build by any means, but I'm hoping to have something more to show here soon.
Cheers,
Martin Jay McKee
MPU6050 ( with 3-axis, 16-g, accelerometer; and, 3-axis, 2000 deg/s, gyroscope )
ADXL375 ( 3-axis, 200g, accelerometer )
MS5611 ( 24-bit, barometer/altimeter )
HMC5883L ( 3-axis, magnetometer, which I'll not be using in the first versions )
All of the sensors except the magnetometer would support 500Hz. The magnetometer is something of a dog, at 80Hz max. In any case, I may not use it for anything. It just happens to be on the board.
I'm actually using breakout boards for the sensors while I'm working out a first version of the software, here's the setup:
Working from right to left, the first board is a USB-Serial converter that is being used -- initially -- for debugging output and power ( the 5v from USB ). Eventually, of course, this same serial connection will also be used for configuration and data download. Above the breadboard is the JTAG interface I'm using to program/debug the processor on the TinyTIM. The middle two boards are: above, the IMU breakout board, and, below, an accelerometer breakout board. Most of the sensors are on a Chinese IMU sensor breakout board, the GY-86. They are readily available and inexpensive. The GY-86 carries the accelerometer/gyroscope, the magnetometer, and the barometer. The secondary accelerometer is on a board I designed ( just to see if I could hand solder the blasted things! And yes, I was, indeed, successful
). Since It was a soldering test, mostly, I have an ADXL343 on the board. It has the same interface as the ADXL375 that I would use in flight, but it is cheaper ( about half the price ) so I decided to use it for the soldering test and ground testing. The last bit, all the way to the right on the breadboard, is the TinyTim itself. It's actually designed for the GY-86 to be back mounted. This is the v0.1 TinyTIM board which didn't have a spot for the secondary accelerometer. Later versions mount that as well ( on a board the same size ).The board features a 32-bit ARM microcontroller, two deployment events outputs ( the drive MOSFETS are not currently mounted, however, they will be good to about 10A ), a built-in magnetic switch, and 16MB of storage memory. Additionally, the board has the serial interface and two GPIO pins that can be configured as either digital input/output or analog inputs with a range of 0-3.3 volts. The board itself is 21mm x 45mm, around the same size as an Eggtimer Quark or the Featherweight Altimeters Raven ( that I'm still lusting over! ). It's not targeted to compete with current flight computers, I have one, fairly specific, goal in mind for this one -- blazing fast acquisition rates. Missing, at the moment, are separate deployment and logic batteries, a buzzer, a couple of GPIO ( I'd like to have four, at least ), and an on-board button for configuration/testing. I'm not sure that I'll ever add the "missing" items though. I'm not designing this to be a "kitchen-sink" flight computer.
As I said, it's a fairly standard flight computer. It does have a couple more sensors than usual, but, the real kicker is the sampling rate that should be possible. The version above -- v0.1 -- has all of the sensors on the I2C bus and the sample rate target is 500Hz continuous ( which will fill the memory in about ~400sec. ). The final goal, however, for a real version 1.0 board is to have barometer sensing at 700Hz and the gyroscope and accelerometer sensing at 2.1kHz. That will necessitate moving the sensors over to an SPI bus ( and putting them on my board, as the GY-86 doesn't break out the pins needed for an SPI interface ). At that speed, the memory will only last for a bit under a minute-and-a-half, but it will have stored a whole ton of data. I like data!
The sensors are all of fairly high resolution ( 24-bits on the baro, 16-bits on the magnetometer, gyro, and accelerometers ), so after calibration, the data will be clean. Clearly, though, the high data rate is going to mean a fair amount of noise in the system. As such, later work is going to be going towards developing software that can process the data to it's best effect. Also, I've got some ideas about how I want the deployment events to work. I like everything to be flexible ( some would say, too flexible ), so I'm planning to have a number ( likely sixteen ) of programmable events of different types: comparison events ( against values in the system ), timer events ( for expiration of a timer that can be started by another event ), boolean events ( to combine other events ), and maybe others. Setting up deployment actions would be based on these events. Of course, the actions would be configurable too. Once again, lots of work will need to go into PC software to make all this work. And, because it would be such an involved setup of the system, I think that a ground-test facility is absolutely necessary. I'd be tempted to integrate it into OpenRocket, but that might be a bit more than I really want to undertake. In any case, I'll need some way to do a complete simulation of a whole flight to check the configuration.
Some other thoughts on features that I would like to include -- with the same basic flight firmware and possibly different hardware -- are: telemetry ( actually, with an external radio, this board could do this just fine ), GPS tracking, more deployment/staging outputs ( and safer outputs... the current design has almost zero protection ), more inputs and outputs. My goal for the TinyTIM is to keep it small enough to fit in a 24mm tube, and for a more complete version to fit in a 38mm ( or, if I'm really good, 29mm ) tube.
It's a fairly ambitious project ( if only for the data-rates involved in both sensing and streaming to the memory ), but it's coming along fairly well so far. I don't have much to show at the moment, as I've just been assembling the hardware, doing very basic electrical tests ( it didn't blow up when I connected power check; it does turn on check; etc. ), and writing a first version of the libraries to communicate with things, and it's working. I can read from the sensors and talk to the computer. The SPI, as well, seems to be working though I have yet to actually do a write/read test with the memory. I've actually got quite a bit more work to do on the memory interface because I need to get that working with DMA ( direct memory access ), so that writing data to memory is done mostly without processor intervention. Otherwise, I won't be able to make the loop timing.
So, thinking about time frame here. I've got a version 0.3 board at the fab right now and I should receive it in a week or two. I'm hoping to have all the components I need for that before hand and most of the test code done so that I can have a working device by mid-May. I've already got the two mule airframes built ( just waiting on final markings and parachutes ).
They are nice and small -- based on BT-55 tubing -- so they should be able to loft the the test payload I have in mind ( an Eggtimer Quark along with the TinyTIM ) to nearly 275 m on just an Estes D12-7 ( the mule can also easily handle an E12, E15 or even F50 ) should make for an inexpensive and flexible flight program. Once I can actually fly it in recording mode ( with the basic lift-off triggering in place ), I'll do a half-dozen flights for sensor checking and so forth, then start working on the next major piece of this whole thing the flight software. Version 0.3 is going to upgrade the processor speed from 24MHz up to 72MHz ( max ) and the data memory from 8kB up to 36kB, so it should allow for many more capabilities than I had originally intended for this small board. I'd guess I might have a really functional Version 0.3 with flight software and a basic computer-based interface in about six months ( another couple dozen flight tests too, of course, without actually activating any flight events ). Then I'll build a new mule for dual-deploy tests and do a series of a half-dozen or so. By that time I should have enough information to do a solid redesign of the board, moving all the sensors on-board, and possibly doing another processor upgrade for expanded memory and processing rate. Then another couple of months to finalize the firmware and computer interface. If I'm lucky, I'll have it all done by December, just in time to start thinking about using it for an R&D project for NARAM 2017.
Oy!
Any thoughts or comments are greatly appreciated. This won't be a quick build by any means, but I'm hoping to have something more to show here soon.
Cheers,
Martin Jay McKee
