Project Logs

Collapse

• Control Panels!

  Art Whaley • 08/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 Whaley • 08/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 Whaley • 08/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 Whaley • 08/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 Whaley • 08/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