Send Everyone To Space!

I'm going to design, build and document a space simulator for school use.

Similar projects worth following
The project is an enclosed space simulator designed to be 'flown' by four 7th to 12th graders as a team. I'll be designing a physical cockpit, programming simulation scenarios and developing a curriculum to teach the basics of spacecraft design, orbital physics, and piloting to kids of various ages and education levels.

The project is going to consist of several parts -

The most visible part of the program will be the cockpit. The window display will be provided by an HD projector aimed at a curved surface... and viewed through several fresnel lens -windows to collimate the image and give the image a sense of infinite depth.

The instrument panels of the simulator will be 'glass cockpit' style with two 20" displays built into the panel face. Custom bezels will be built to divide the screens into several smaller instrument panels, giving the sense of many instruments instead of two computer monitors.

Input from the pilot will largely be through momentary push-buttons to minimize the 'reset' time between simulations that toggle switches would induce. Input will be processed by a microcontroller and relayed to the simulation computer.

Outside the simulator a control station will let instructors monitor the kids progress, trigger situations for the kids to respond to, and communicate with the 'astronauts' inside as their 'mission control.'  

  • 1 × PC for Running Simulation
  • 1 × PC for Drawing External Displays
  • 1 × TM4C 1294 TI Connected Launchpad Microcontroller for button input - communicates via keyboard emulation and by network with simulation computer so it can call higher level API items as necessary
  • 1 × HD Video Projector
  • 1 × Curved Rear Projection Screen - Details to Come!

  • Control Panels!

    Art Whaley08/24/2014 at 03:52 0 comments

    Today I took a break from coding and played with tools.  I got all 4 primary control panels built.  There's a pic up, but you really can't tell how extraordinarily good they look from that picture.

    I cut the panels out of clear acrylic, used a drill and dremel to cut all of the holes, and painted what would be the back side with semi-gloss white 'Fusion' paint.  I can't say enough how gorgeous this finish looks from, the front side - it's like a glossy white piano when you peel the protective plastic off the front!

    I glued all of the square buttons in place.  I ordered a cheap pack of 50 'keyboard style' buttons from Ebay, and had assumed they'd be keyboard sized as well as style... but they weren't.  They really weren't keyboard style either.  They came with no bezel... but were too thick to comfortably surface mount them on the panels.  So I cut holes, glued the button body into the holes, and then cut keys off an old PS/2 keyboard and glued them on top.  Since the keyboard buttons were substantially bigger than the 'keyboard style' buttons, it covered the hole and hid the glue mess.  I really should have just paid the extra money to use proper panel mount buttons throughout...  but I saved $50.00 by being cheap, and I'll just promise myself that I'll put that money to good use somewhere else on the project.  They have a good feel when it's all said and done... but I can see myself ripping them out and replacing them some day.  The buttons ARE the human facing part of this project...  They need to be great!

  • Instrument Progress!

    Art Whaley08/21/2014 at 04:34 0 comments

    I've got the rough architecture built for the external instrument panels.  I haven't done a lot of C#, so it's been a good chance to learn that.

    There are a couple of Kerbal plugins that get flight data out of the program and onto a network already - Telemachus hacks a webserver to actually run into Kerbal Space Program.  It's a great program with two-way communication... but it's a little taxing on KSP.  When I was polling the amount of data I needed... there were noticeable hickups.  

    So I looked at GoAtThrottleUp... which is also great.  The GATU approach is to have the plugin just shout the data out via HTTP POSTs.  They're using a python relay server to make the data available via webpages.   I've decided to borrow the approach of shouting data out through POSTs, but instead of using the python webserver as a relay, I'm catching the data directly into a C# program that handles all of the display options.  

    I'll get pictures up of the instruments after I publish this!

  • Kerbal Command Pod

    Art Whaley08/21/2014 at 04:20 0 comments

    I've got a completely transparent cockpit build for KSP.  Obviously building invisible stuff is pretty easy - ithe IVA view is just a sphere with a fully alpha texture mapped on it.   I played with adding navigation indicators on the inside of the sphere-  degree markers like a HUD to help maintain orientation, but different builders may want to set the zoom differently, depending on the field of view of their cockpit, how many displays they want to output, to, etc...  so I decided it was best to just keep it clear.   The clear cockpit IVA can be put into any ship in the program with a quick config file edit, but to make it more immediately useful to the kerbal community I went ahead and built a command pod with a giant window in it  to justify the wide FOV.  

    I built the pod and IVA in Blender, processed them through Unity, and they just worked in KSP!  I'm going to do some testing to make sure it works properly in career mode then get it released on Curse so other Kerbonauts can start using it.

  • Software Choices

    Art Whaley08/21/2014 at 04:10 0 comments

    I've really only found two pieces of software that could serve all of my needs as a basis for the simulation project.  Orbiter, and Kerbal Space Program.  They've both got advantages and challenges.

    Orbiter is open source.   The visuals in orbit are gorgeous... and feel a little more realistic.  The distances and velocities are realistically scaled.  The controls for the various ships are modeled with so much detail! There's already support for external instruments built by the community, so using a second machine to render instruments would be easier.

    The downsides of Orbiter are similar to the upsides!  Because the physics are very real... getting into space is harder and slower in Orbiter.  The controls could be too complicated for kids to learn in a quick training session.   In the interest of keeping the flight quick I want a vertical launch vehicle, so the stock and community made orbiter spaceplanes wouldn't work out of the box - I'd have to design something and designing and tuning a ship for Orbiter would take a lot of work.

    Kerbal Space Program abstracts the details in a way that I find really approachable to kids.  I also like the spaceship building component... I could see a future class where designing the rocket is the focus.  The KSP development community is really active right now, so there's a lot of support to bug with questions along the way.

    The downsides of KSP are that it's not really set up to be a first person simulator right now.  The first person views of the existing ships are mostly internal views of the ships - rendered 3D views of the instruments and panels... with tiny views out little windows.  Most people play the game in external views.  So I'd have to do a bit of 3D modelling to build a command pod with a completely open field of view.   I'm also not thrilled with the external instrument options for KSP at the moment.  There are a couple of web browser based options that create some gauges... but there's not a complete offboard instrument suite yet.  This is development I'm pretty comfortable with though... and I think it would benefit the KSP community a lot as well, which is always nice.

    In the end, my decision is that I'm going to make sure I build the simulator to handle both programs, but I'm going to focus on KSP first, because I think it's easier to get kids into the simulator without hours and hours of instruction in how to use the ship.   I want to make the whole experience fun and I want the takeaway to be about how awesome space and physics are - so I don't want to spend the whole time learning the details of how a particular ship works - I want to teach the general concepts in a way that lays the foundation for kids to go out and learn more on their own.

    I know it's not open-sourced, but it's really affordably priced - it is open to plugin development, there's an active community, they're involved in education and it's just the right tool for the job.   The number of parts required to make all of this work means that the simulator isn't going to be free to put together... and I think less than 30 bucks for a great piece of software is worth it as a part of the simulator.  I'm going to make sure I design everything to work with Orbiter too.. so someone who's less compromising than me can build a completely open sourced simulator on top of what i'm doing.  

  • Mission Design

    Art Whaley08/21/2014 at 03:15 0 comments

    I've started with designing the 'missions' that I want the kids to complete in the simulator.

    Obviously, the exact scenario will need to be different for kids with different prior skill levels. Towards that end, I'm starting by designing two scenarios.  There will obviously be flexibility build into the system to allow for future missions to be created...  but having a firm grasp on how it will work 'at first' always helps to prevent scope creep and get the project done on time!

    In this log I'll detail the younger kids mission.

    The mission will be to rescue a similar craft stuck in orbit.  The kids will need to launch, rendezvous, dock, transfer fuel to the stranded ship, undock, deorbit, and land.  

    We'll start with a one hour introduction class.  The class needs to cover the following - 

    1.  Introduce the fictional spacecraft we'll be flying - a next generation reusable spaceplane similar to Sierra Nevada's DreamChaser that launches vertically on top of a rocket stack and lands as an unpowered glider.  

    2.  Explain the concept of orbit - getting above the atmosphere, and getting enough velocity that you keep missing the earth as it tries to pull you back home.  

    3.  Explain how to get into a specific orbit - launching and performing an orbital insertion burn.

    4.  Explain how to raise and lower an orbit, and how to execute a plane change.

    5.  Give a really basic overview to how we're going to handle orbital rendezvous on this mission - launching into an orbit lower than our target, making sure our planes are aligned, and then performing a Hohmann transfer at the right time to meet the target.

    6.  The basics of docking two spacecraft.

    Next we'll break the kids into groups of 3 and assign jobs.  

    The three jobs will be -  

    Commander - pilots the ship through ascent, acts as copilot for landing, and deorbits the ship.

    Pilot - Pilots the ship during docking and landing.  Acts as copilot during ascent.

    Engineer - Controls staging and engines during ascent.  Monitors fuel, electrical, and environmental systems during flight.  Acts as copilot during docking.

    The instructor will demonstrate each job on a computer and projector setup, and use pictures and 3D models to demonstrate where the controls they'll be using are located inside the simulator.  

    The teams will all cycle through the simulator for a quick 'practice' turn at each job - each team will fly an ascent, then each team will practice docking, then each team will practice landing.  

    Finally the kids will be briefed about the ship that needs rescuing and each team will get a chance to fly their complete mission start to finish.  

View all 5 project logs

  • 1
    Step 1

    I'm starting on the build instructions...  though there will be LOTS of edits as the system takes shape.

    The first assembly step is the control panels.  The rest of this cockpit can be scaled up and down a lot, but the heart of it are the buttons and switches that the kids will have their hands on!

    Supplies for this part are - 

    Panel material.  I used acrylic but you could splurge and go for aluminum... or you could skimp and go with masonite.  My big box hardware store has 4X8 panels of masonite that's finished white and glossy on one side for use on bathroom walls and similar environments, and this would make a pretty nice feeling panel at $14.00 per whole sheet!    I may use some of this for the interior walls of the simulator to make it feel clean and shiny without a ton of money spent.

    Buttons and switches - I used 38 basic momentary buttons, 7 lighted momentary buttons (rcs, sas, lights, gear, brakes, staging, and abort) and 5 spdt switches (white lights, blue running lights, cabin fans, master power, and communications.)  I also used a really nice $15.00 8-way microswitch joystick from Amazon for the linear RCS.  I may buy another one and replace the attitude control buttons with it!

    I'll post my layouts for the panels, but feel free to do your own thing designing them if you'd rather.   I organized my controls into 4 panels and built them individually so I could get my hands on them and make sure I liked the arrangement before the whole cockpit was built.  You could absolutely build the whole control panel as one unit if you're confident like that.   I'm putting an "Engineering Panel" on the far right, with controls for all shipboard systems.  In the middle will go attitude control and autopilot where all three kids could reach them.  On the far left I'm putting the linear RCS controls where they'll mostly be used by the pilot for docking.

    I cut my panels out of clear acrylic, then I drilled and dremeled all of the holes for the buttons and switches.  Sanded the edges of the holes and table saw cuts , drilled mounting holes, and then painted the backside.

    When your paint is dry, handle the labels.  I  printed 'repositionable window decals' from Staples with the panel markings, stuck them on, then x-acto knifed out the holes.    They look good... but not as good as the panels looked before the labels.  I may revisit labeling.  

    Mount all of the buttons and switches.  How you go about this will depend on what you made the panels out of.

    Solder umbilicals to the back of every panel.  One side of all of the buttons and switches will get tied together - this 'bus' will be hooked to ground.  The other side of each button gets it's own wire - these will be hooked to the io pins of the launchpad to serve as the inputs.  I used 8 conductor ethernet cable I had laying around for this... so I've got 9 cables running from my panels.  Label them as to where they go, especially if the launchpad and the buttons are going to be far enough apart that it will be a pain to look over and see what cable-3, conductor seven is hooked to!

View all instructions

Enjoy this project?



Greg Kennedy wrote 08/24/2014 at 04:55 point
Bahaha I was about to jokingly suggest Kerbal as your "simulator" and here you are already using it!

  Are you sure? yes | no

zuul wrote 08/21/2014 at 05:02 point
sounds fun

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates