| User | Post |
|
5:17 pm
February 26, 2010
|
craiggers
| | Cambridge, MA | |
| Member | posts 7 | 
|
|
|
Hey everyone! I just found this project through brmj recently, and couldn't help but get interested. I'm a graduate computer science student at RIT in my last year of school, with particular interest in computer vision and robotics. My choices for school were either computer science or astrophysics, so I've been itching to help out with something like this for a while now.
This is a really neat project that I'd love to see succeed, so I'm willing to help out in any way I'm able.
|
|
|
5:25 pm
February 26, 2010
|
brmj
| | Rochester, New York, United States | |
| Member | posts 402 | |
|
|
Welcome to the team! I look forward to working with you. I'm a bit busy getting ready for SpaceUp tomorrow or I'd post something more involved. Anyway, you've already heard from me on Reddit, so I'm not entirely sure what more there is to say until we start discussing the specifics of our plans and what we have so far.
|
Main work groups: Propulsion (booster), Spacecraft Engineering, Computer Systems, Navigation and Guidance (software)
|
|
|
6:03 pm
February 26, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
Post edited 6:05 pm – February 26, 2010 by Rocket-To-The-Moon
Welcome to the team, since we have not launched any rockets yet, getting new members is the most exciting thing we do.
I'm not a software person myself so my inputs may not be too productive, but I think that it is about time to begin work on the mission software for OHKLA (our small 100km altitude rocket). We basically need a small and lightweight system that can integrate data from accelerometers and GPS, record the raw data to flash, transmit telemetry data, sequence the parachute, and relay the landing coordinates.
Since we don't really have anyone with firsthand hardware experience it is difficult for us to select the exact components that we need.
My thoughs are that we can develop the software first and just feed the code with simulated hardware inputs (ie. a flight simulator). This allows us to actually get working on it without having to wait on hardware.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
6:28 pm
February 26, 2010
|
Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
 
Like I said, I'm not a software person, but this is how I envision the software looking.
- 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.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
Login 
Register 
Search 
Home
Topic RSS 
