Forum | OHKLA Software Block Diagram

You must be logged in to post login Login register Register

Search Forums:


searchicon 






topic

OHKLA Software Block Diagram

small tagNo Tags
UserPost

9:00 am
February 28, 2010


Rocket-To-The-Moon

Grand Forks, North Dakota, USA

Member

posts 556

offline
link
print
1

Post edited 9:02 am – February 28, 2010 by Rocket-To-The-Moon


dscqemouse

Here is a rough outline of what the software may look like that runs aboard OHKLA.

  • The big central block is the core software, that is, the part that takes sensor inputs, runs calculations on those inputs, and then outputs raw data. This block is used both for simulation and for the actual flight, it won't know the difference since the input interpreter makes sure that simulation and real data is identical.
  • The input interpreter takes either simulated inputs or real inputs and ensures that they are in the correct format for the core to process.
    • The idea behind this is that we can write the core software without worrying about what the native output format of the physical sensors is.
      • Once we get real hardware we can re-code the input interpreter so that it can understand the sensor outputs but it will still be passing data to the core software in the exact same format as the simulated inputs.
  • The output interpreter takes data from the core and either sends it to a software output that can be analyzed or (in the case of a real mission) it can output raw data to flash and to the transponder
    • Like the input interpreter, the job of the output interpreter is to take data output by the core and put it into a format that can be used by the output hardware.

The rationale behind this is that the most complex part of the software (the core) can be made without knowing how we are going to input or output data. Once we do know this then we can write the input and output interpreters to interface with the hardware. 

Swamped with work & school at the moment. Main Workgroups: Propulsion & Spacecraft Engineering

1:04 pm
February 28, 2010


DenisG

Saarbr├╝cken, Germany (GMT+1)

Member

posts 49

offline
link
print
2

I thought we would prefer to use off-the-shelf hardware? That means the software is already written, tested and debugged and only the parameters need to be adapted.

5:57 pm
February 28, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1024

offline
link
print
3

I am not sure if we will be able to find open source software which does everything we need (i.e. processes data from all the different sensors we may eventually place on OHKLA) and which is written in the appropriate language for whatever processor we eventually use, but if we can we should use it.  If we can find something close but not quite right, we should modify it to suit our needs rather than search from scratch.  We should probably spend some time doing research to see what we can find.

If we do end up having to write our own from scratch, though, Rocket's block diagram seems entirely sensible.  I do really like the idea of the input abstraction layer: it lets us get started on the core software before we have chosen exact sensors, and reduces the cost of making changes to those sensors later in the project.  It would also open the door to code reuse on later rockets with slightly different hardware (like a future staged/clustered version of OHKLA).

Starting a new TA job next week, might be busy for a while! Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

6:08 pm
February 28, 2010


Rocket-To-The-Moon

Grand Forks, North Dakota, USA

Member

posts 556

offline
link
print
4

Post edited 6:09 pm – February 28, 2010 by Rocket-To-The-Moon


During the SpaceUP webcast one of the presenters made an interesting comment about commercial GPS receivers not working above a certain altitude and speed (intentionally since those parameters fit a missile's flight profile). He did say that it is possible to disable this "feature", apparently those involved in high altitude ballooning are the ones to talk to about this.

It sounds like the two biggest things at SpaceUp were ITAR reform and funding issues.

Swamped with work & school at the moment. Main Workgroups: Propulsion & Spacecraft Engineering

6:17 pm
February 28, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1024

offline
link
print
5

Thanks for these updates.  I really must try to find the time to watch some of the other presentations at SpaceUp.

Do you know anything about the legality of disabling the altitude/speed cut-offs on commercial GPS receivers?

Starting a new TA job next week, might be busy for a while! Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

6:28 pm
February 28, 2010


Rocket-To-The-Moon

Grand Forks, North Dakota, USA

Member

posts 556

offline
link
print
6

Post edited 6:46 pm – February 28, 2010 by Rocket-To-The-Moon


He made it sound like it is a common practice so long as you have a need. It was a little bit unclear how one goes about this, I presume a firmware update. I'll have to checkout some ballooning sites.

http://forum.sparkfun.com/view…..php?t=8425

http://ipp.gsfc.nasa.gov/ft-te…..GATOR.html Interesting, but not a low cost solution.

http://www.gpscity.com/item-ga…..18xlvc.htm Supposedly no altitude limit with 2.80 firmware

http://hackaday.com/2008/06/28…..no-shield/

http://www.wiredhouse.fr/2008P…..ogger.html Best source


Kind of a random splattering of links, nothing too useful.

We really need to get someone on board who knows about building circuit boards and working with this type of stuff. I'm sure this would be a fun and challenging project.

Swamped with work & school at the moment. Main Workgroups: Propulsion & Spacecraft Engineering

8:27 pm
February 28, 2010


Luke Maurits

Adelaide, Australia

Admin

posts 1024

offline
link
print
7

Rocket-To-The-Moon said:

We really need to get someone on board who knows about building circuit boards and working with this type of stuff.


I was under the impression that DenisG knows a fair bit about this kind of thing?

Good collection of links, thanks.  Maybe we should have some recommended reading pages in the Wiki for OHKLA, like we currently do with the CLLARE Workgroups?

Starting a new TA job next week, might be busy for a while! Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.

3:52 am
March 1, 2010


DenisG

Saarbr├╝cken, Germany (GMT+1)

Member

posts 49

offline
link
print
8

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:
  1.  
    1. identify the requirements for such a system
    2. define our budget
    3. find and evaluate commercially available systems and chose one
    4. 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 . . . 
  1.  
    1.  
      1. 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]
      2. 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.


small tagNo Tags

About the CSTART – Collaborative Space Travel and Research Team forum

Most Users Ever Online:

28


Currently Online:

3 Guests

Forum Stats:

Groups: 4

Forums: 32

Topics: 352

Posts: 2477

Membership:

There are 86 Members

There has been 1 Guest

There are 2 Admins

There are 0 Moderators

Top Posters:

Rocket-To-The-Moon – 556

brmj – 327

rpulkrabek – 142

DenisG – 49

noumena – 36

maciejm – 20

Administrators: Luke Maurits (1024 Posts), Rizwan (144 Posts)




  • Share/Bookmark