I'm going to echo what Paul said a couple of weeks ago - it's going to
be hard to get folks to agree on anything common. I'm not knocking the
idea of trying to make a common flight controller, go for it if that's
what you're interested in. I can't speak for others but I would have no
interest in using it. I've spent too much of my life debugging other
people's code and "discovering" interesting and unexpected behavior
along the way. When I looked at that OSAL/CFe code a while back, my
first thought was it looked very powerful but also comes with a lot of
overhead. For me, the flight computer is an area where I can be
creative and try out clean-sheet concepts. This may sound silly but part
of what makes amateur rocketry interesting for me is that it's hard and
you can't just buy the pieces off the shelf. I actually enjoy learning
the details of how all this stuff works. When everybody is launching
actively controlled rockets with off-the-shelf H/W and S/W (like the
drone folks are doing), that's probably when I'll lose interest and move
on to something else.
But to answer your question, here's my wish list (coincidentally similar
to what I'm working on):
1. Decentralized architecture with a robust messaging system between
components. This allows S/W functions to be combined on cheaper boards
or distributed out to separate boards (similar to what PSAS is doing).
2. A sequencer / state machine that allows for an orderly startup of a
liquid engine with appropriate sensor checks along the way for
out-of-tolerance values, etc. Also include the ability to hold the
countdown and be able to override any checks, jump to other steps, etc.
3. Specifics of individual sensors decoupled from the architecture so
you can try out different IMU, GPS, pressure sensors, etc.
4. Every variable in the system should have the units appended to the
name (temp_deg_c, etc.) so there's no confusion about the units.
5. Support for digital as well as analog bridge-type sensors. For
chamber pressure sensors, you want as little dead space as possible and
almost all of those miniature transducers have millivolt output. This
implies an instrumentation amplifier or similar. You also need
appropriate filtering for ADC inputs. Most in-amps don't have very good
CMRR above 1 MHz and with a bunch of high-speed buses around, they
generate lots of high-frequency noise that typically shows up as mystery
offsets in your data. A simple one or two pole RC filter may be good
enough but the data system needs some thought.
6. Support for several high-current outputs for recovery, solenoids, etc.
7. Regulated 3.3V power (maybe also 5V for sensors and 10-12V also for
any servos) from an onboard battery. Capability to charge the battery
from an external source and monitor the battery voltage.
8. Two-way telemetry, either serial or network based for ground control.
9. Backup recovery system independent of the flight computer that
allows you to deploy the parachute on command from the ground.
10. Ground station S/W that allows you to debug the flight computer and
monitor additional messages (beyond the TM stream) prior to launch.
11. Navigation S/W that integrates IMU data with GPS and altimeter for
position reporting and guidance (Kalman filter).
12. PWM or serial outputs for flight control servos, gimbal actuators, etc.
13. Onboard time source synced to UTC for messages (TM and onboard) and
for synchronizing with other offboard systems. Most GPS units put out a
1 PPS that you can wire into an IRQ pin on the CPU to calibrate its
onboard oscillator. Most regular XO units are far enough off that over
a few minutes, the error can be several tens of milliseconds.
Is all this needed to send something up? No but hey, it's my project
and if I find these things interesting, that's what I'm going to work on :)
-Bob
