I don't know what propeller board to use on my rocket project. (Also some rocket code couldn't hurt)
Elnino2002
Posts: 5
I'm currently at the sourcing stage to build a rocket with a data logger and I'm thinking of using the Basic Stamp with a BMP280 (Barometer), and a MPU-6050 (accelerometer/gyro). Does anyone have any recommendations? Also if anyone has done something similar before I would like to hear about it! Also if anyone is willing to share any information that could be used in my coding that would be appreciated as well. Thanks!
Comments
It looks like these sensors have an I2C bus.
Yes Basic Stamp 2's will be able to communicate with I2C
What is the sample rate you would like to acquire the sensor data at? (for example number of samples per second).
Also where do you want the data to be stored?
This will help determine what controller you would need.
But I have used Propeller chips as commercial data loggers on very many occasions in many products. An 8-bit memory constrained Basic Stamp just doesn't compare to an 8-core 32-bit Propeller chip, not just in processing power, but also in ease of use.
Sparkfun has 9DOF SENSOR STICK.
Adafruit has BNO055 breakout board.
There is also a sensor fusion board that combines these sensors with a high speed processor to read all these values and return EULER angles. EM7180 + LSM6DSM + LIS2MDL or EM7180 + MPU9250 + BMP280.
Mike
-Phil
It seems to be targeted towards the education market rather than embedded because it emphasizes on-board USB serial which you hardly ever use, and certainly not in flight, but does nothing about data storage such as Flash or microSD.
-Phil
The on-board USB serial interface is used to load the program to be run on reset and can be used for debugging.
Having USB on the actual Prop board is more of a hindrance since it precludes other forms of serial coms and also takes up board space that could be used for microSD or high density Flash (not the EEPROM).
Having an extra row of 4 pins allows for +5V and I2C so that this same connector can have a serial Bluetooth module plugged in when it is not sitting on the test bench but is now not as accessible inside a case mounted on some contraption.
Anyway, I would be hard pressed to find a module more adept at meeting the needs of OEMs, so I'm just not sure where your criticism is coming from. Maybe you just haven't tried it?
-Phil
You are taking this too personally (maybe I might react the same in the same situation though). I merely said that I consider it targeted more towards education rather than OEM products, of which I have many more than I can recall using the P1. The FLiP looks nice and the inclusion of a real switcher rather than those linear regs is a welcome inclusion and certainly the USB "is" handy on the bench.
Any boards that I've designed with integrated USB normally need it for normal operation yet I still use series resistors in there so that I can override the USB port if I need. Otherwise in the bulk of my designs I have no need for USB other than programming. On the other hand, practically all my designs use SD or microSD for all kinds of logging purposes although I see that many times some other Prop designs seem to "run out of memory" and cannot utilize FAT32 software anyway, but the P1 has plenty of capability I find.
Viva the P1!
You may want to just use a flight controller as everything is built in including a flight recorder.
Check this unit out as it is small and has all the sensors built in and ready to go just add power....
PixRacer Auto Pilot
It is only 35mm square.
Mike
Consider too that an SD card recording at the highest rate is going to consume something like 30mA or more. That would drop to less than 1mA if it is not active, deselected. The average depends on your required sample rate. The sensors will probably be an insignificant power drain. Recording to EEPROM or flash memory might take less current, but to use those you'd have to think more carefully about the sample rate versus the total length of the flight. Say 32kBytes with 8 bytes per sample, gives 4096 samples, say at one per 0.5 second gives a total deployment time of ~34 minutes. The point is to minimize weight and size of the instrument package and its battery.
@Elnino2002, There were protracted discussions and learning experiences in the old "Stamps in Class" forum, where a group of middle school students launched a rocket at Black Rock Desert.
https://forums.parallax.com/discussion/113538/ideas-on-off-switch-to-activate-a-datalogger/p1
https://forums.parallax.com/discussion/122688/arliss-team-nh/p1
http://forums.parallax.com/discussion/100967/combining-temp-humidity-sensor-program-with-a-simple-movement-program/p1
They used a BASIC Stamp of course, which is still quite a capable and fun microcontroller. You might find some ideas there, if you wade through it!
https://www.americanradiohistory.com/Archive-Radio-Electronics/90s/1990/Radio-Electronics-1990-10.pdf
G force measurements on the way up seems safe, but how
do you plan to measure atmospheric pressure & temperature
accurately? Depending on how your cargo compartment is
vented during the assent, the internal air pressure may be
either greater or less than the the outside pressure, and it will
skew the data.
If the air pressure is less during assent, your altitude data will
be higher than it actually is, and lower if it pressurizes.
Air temp affects density altitude also.
On the other hand you could monitor the altitude data on the
descent, but that might rely on good interpretation of the
accellerometer data.
Another good project would be a hand held weather station
like what the Drag Racers use. I think you will find that your
rocket data will change depending on that days weather.
Bill M.
The "model rocket static ports" are what I was talking about, and there is plenty
of info to be found with a quick search. The problems with pressure or vacuum
are real, and careful design your vents should be an important design feature.
Bill M.
I found examples of rockets pressurizing and separating before apogee because
of the pressure build up. Other examples of the Bernoulli (venturi effect) causing
a vacuum.