I do indeed. But I was under the impression, that a custom avionics system is not what is wanted, especially after reading http://cstart.org/wiki/CSTART_…..r_possible and http://cstart.org/wiki/OHKLA#Overview where it specifically says:
Since the main focus of OHKLA is propulsion research, all other subsystems on the rocket, such as those related to altitude and velocity measurement, parachute release, location reporting, etc. will be standard, off-the-shelf components from the amateur rocket industry, wherever this is possible. For this reason, OHKLA is not divided into workgroups like CLLARE.
This means:
- using existing, 'commercial' solutions is definitely the fastest way to get to a solution. Take module A that outputs binary 1 if 100km is reached, take module B that ignites the parachute ejector. This may or may not be the cheapest solution. The tasks with this approach are about:
-
- identify the requirements for such a system
- define our budget
- find and evaluate commercially available systems and chose one
- buy, put them together, test, fly
-
- this means we collect little to no data (except some simple altitude recordings), and little to no way to influence the flight (except maybe an abort system); re-use in more complex systems means just dabbling the modules together again in whatever manner works for us.
- using our own solution allows us to collect as much data as we want and do whatever we want
- the software "abstraction layer" is the trivial part here. The hard thing is to define the hardware layer between the processor and the sensors . . .
-
-
- how many sensors do we want to connect? Do we want to add more sensors at a later stage? The Sugar Shot guys have five temperature sensors alone in their nose cone in their small rocket. [pdf]
- what are the realtime requirements on the communication between sensors, processor and actuators? how fast do we need the data, how fast must we react to changes (if we can/want react at all)
-
- this will tell us whether we need a parallel, serial or some kind of bus design. Whether we want sensors and actors on the same bus; whether we need multiple busses; what redundancy is necessary etc. etc.
- then we might want to re-use the system; this means adding more abstraction to it, more interfaces, which makes it more complex but immensely increases reusability
- of course we have to figure out all of the details and little tricks; we have to test very thoroughly; development becomes much longer, and maybe more expensive, since more iterations might be needed.
As far as I can see, here the 'features,' that is the answers to the question 'what do we want?', are not defined yet, and doing any research or work without this definition is pointless.
I am not sure if we will be able to find open source software which does everything we need.
I get the impression that we don't know what we need yet.
Login 
Register 
Search 
Forum
Topic RSS 
