Space docking simulator

The below video shows the planning and construction phases of my solo final project in NMD 102. For my project I combined Arduino and Unity to create a realistic control panel for a space ship. My constraints that all input and all data output had to go to the console.

In unity, I had to create a zero gravity environment with newtonian physics, as well as create a goal for the user.

Programing in the unity and arduino environments done by me.  All 3D models are my design, as is the design of the control console.

 

 

New Media 102 – Final Project

Jason Dignan

Spacecraft Manual Control Simulation Box.

 

Introduction – What is all about

This project focuses on the union of Arduino and Unity environments. The Arduino supplies a human interface device for humans to interact with virtual objects within Unity. The goal was to be able to control a spaceship with realistic physics to perform a docking maneuver. This project was broken down into five phases of development.

 

Phase 1 – The Interface

The hardware interface was the first part of the development process. The interface had to integrate controls for maneuvering a spaceship. This required maneuvering thrusters for lateral motions in the X, Y, Z directions. It also must include the ability to rotate on the x and y planes.

Additional functions that were accounted for were LCD display readouts, and the ability to change cameras to get a better vantage point while maneuvering. The wiring, and design was all created from scratch and utilized no. The greatest difficulty was involved in the LCD screens. This was a hardware issue in that it was very difficult to maintain any level of connectivity. This was corrected with the purchase of a butane soldering iron, and soldering on connector pins. Despite this being my first time soldering, it came out surprisingly successful. Assembling the device required a great deal of patience, and iterative design. The device was fully assembled into, and then portions of it were wired, and programmed to ensure continual functionality, and make bug fixing easier.

 

Phase 2 – The Hardware Programming

The purpose of the Arduino in this project was to interpret data coming in from user inputs and transmit data to Unity. Additionally, the Arduino had to take data inputs and output that information to the LCD screens. Using Serial communications, two way data is achieved. Difficulties that were experienced involved transmitting multiple data values and taking in multiple data points. Distributing that information out across multiple values was also required. The greatest difficulty lay in the two way communications. Fortunately, finding a way of processing strings by char made communication lag non-existent. Reading by full strings caused significant lag in Unity. By reducing each output of the Arduino to a single character, a great deal of information can be passed very quickly.

 

Phase 3 – Unity Programming

Unity is the main output of the project. It takes the Arduino output and turns it into action on a space craft. This required a little bit more work then the hardware programing. Step one of this phase was simply just to make it work. Iterative design processes continued to be used. With the hardware programming and communications completed, the hardware interface was used to ensure that all controls worked as expected. At first all controls were configured to move the craft one step. This helped to ensure that all controls worked in the proper directions. Once this was fully mapped, a momentum carrying system was integrated. By creating a fake set of Newtonian physics, a close facsimile of space navigation could be attained. While physics were not used, simulation of them was successful. This involved taking the values that described motion or rotation, and made it additive for every action the user took while interacting.

Cameras were integrated and made to work, to add to the realism of the environment. Finally, the LCD screens on the hardware had to be populated, and communications were designed to send to the hardware. This unfortunately could not be represented by a single character, and had to be handled with more care.

 

Phase 4 – Added Features

A few extra ideas were integrated into the design after all base functionality was established and working. These included a fuel feature. Every action the user took using the interface expended a limited quantity of fuel. This added another level of realism to the environment, and added a challenge point to the user. A distance indicator was also added to help the user know how much further it was to the point of destination. The LCD screens were very important to this, as it was the only user interface element that was made available. Motions are very hard to discern while traveling in space, and having the visual numerical indicators improved the user experience significantly. Significant lag was being produced from the two way communications, but a redesign of the code helped to alleviate this issue.

 

Phase 5 – Aesthetics

A great deal more work was applied in the attempt to make the hardware and software look appealing and impressive. The hardware was fully disassembled and reassembled multiple times during the development project through all phases. The finally disassembly resulted in improvements in the aesthetic qualities. Covering the box with Duct tape, while cheap, was effective in dressing it up. I describe it as “NASA shiny”. Electrical tape was used to border certain hardware elements. Wires were controlled, and fed through holes made in the box. The Arduino itself was mounted to the inside of the box, keeping the rats nest hidden.

The Unity environment was improves significantly as well. A ring system by which the user traveled through helped to give the user a reference point by which to navigate, and gave an immediately recognizable goal. The end goal however was to dock with a space carrier located in the distance. The only thing that I did not personally create was the skybox, and was a free asset acquired from the store. All other models, textures, and effects were of my design.

Adding maneuvering jets that fired when the user interacted with the hardware added a visual feedback that their action is having an effect, and was resulting in motion. The maneuvering jets were mapped out, and would fire accordingly to match what maneuvers were being performed. Finally, a beautiful piano score was added to add a bit more depth to the experience. The biggest area of pain was the ring system. I wanted the rings to change color and activate the next ring in sequence as the user went through them. Since I was not using physics to move the craft, no collisions could be used to trigger the code. After a few days of trying to make it work, I ended up using a distance algorithm, so that when the craft was close enough, it would be triggered. This solved all my issues. While this may not have been the most efficient means, it completed the job.

 

Improvements that could have been done

The physical hardware could have been made better looking. I unfortunately lack manufacturing facilities to allow me to create a much prettier interface. Time also was of essence. As such, a simple wrapping with duct tape was about all that I could achieve to this end. I would have like something that was more ergonomic. I also wish that I could have been able to eliminate all wires from showing. This would have improved the visual aesthetics.

In the unity environment, a significant amount of improvements could be achieved. Time was the limiting factor here as well. More models could have been implemented, and textures could have been designed to suit the needs of the models.

All the code could definitely use an overhaul, to clean it up and make it more efficient. With the unity coding, I would have liked to have used the physics system. This would most likely have allowed me to achieve a much more true Newtonian physics model. More coding in unity would have allowed me to produce multiple levels for the user to progress through. Least I say it, given more time, the overall quality of the product would have been even better. Given that I had proper manufacturing and materials, the quality would have been completed. This may become a long term goal, or used as a proof of concept in creating hardware interface devices.

 

Conclusion

I am absolutely happy with what I was able to accomplish in this task. What seemed to be a very large goal, ended up being achievable, and all my stretch goals were also achieved. If I could have been allowed to spend more time on this project, an even more impressive suite of controls could have been developed. However time was my only limiting factor in creating the Unity environment. All assets except the sky box were developed by myself, and more assets could have been created to flesh this out. I did meet all my goals, and achieved a working product that was usable.

Leave a Reply

Your email address will not be published. Required fields are marked *