IEEE Snow Drone Project

IEEE Snow Drone Project

A C# Windows Form Application that allows the user to communicate with an autonomous snow drone in the Antarctic. 


About.

  • Team size: 3 members
  • Duration: 16 weeks (whole semester)
  • Personal role:  Programmer, UI designer, Technical Writer, Presenter
  •  Project role: Team leader, Project planner
  • Software: Visual Studio (final design), Construct 2 (prototyping), Unity (abandoned)
  • Platform support: Windows
  • Other tools: Github (code sharing), Google Docs (project documentation sharing)
 

Project Outline.

The IEEE Snow Drone Project is a joint effort project, sponsored by PSICE and various Penn State department, aimed at creating an autonomous snow drone for speeding up the ice sheet mapping process in Antarctica.

Subsystem Outline.

Snow Drone Control Interface (S.D.C.I.), is one of nine subsystems teams to the IEEE Snow Drone Project. As a capstone project, the primary goals of our subsystem was to building a skeleton of the control interface and hand it off for students next semester to build upon. 

Our team believed that we had the ability to develop fully functional control interface and presenting a proof-of-concept prototype. This prototype was then our target to developed the interface for the semester.

Project Beneficiaries.

The main beneficiaries of the IEEE Snow Drone Project are the PSICE geologists, who is currently studying the ice thickness in Antarctica. Their current method of achieving PSICE's objectives has been by pull a ground-penetrating radar (GPR) with a snowmobile over the surveying ice sheets. By deploying an autonomous snow drone, our project seeks to help achieve the goals of set by PSICE in two ways: One, removing the need to physically drive the snowmobile, and Two, reducing the time needed to plan and survey the ice sheet. 

 

Design Details.

Customer Requirements & Specification

Hurdles & Solutions.

When developing the specification for our subsystems, one of the biggest hurdle during the entire development was obtaining the PSICE geologist's requirements/needs for the software application.

Solution: We remained in close contact with our capstone professor who is responsible for contacting the sponsors, and developed our subsystem specification with our professors input.

Proof-of-Concept

Hurdles & Solutions.

Creating a proof-of-concept prototype could prove our ability to take on developing the interface but our teams primary goal was still to create a skeleton for hand-off.

Solution: In my spare time, I utilized my game design skills to  developed two interactive interface on Construct 2 as our prototype. One, more visual detailed (two on the top left) as our vision for the project and the other (one on the top right) as our minimal viable project.  

Result: Prototype was a success with the professor and generated motivation among the subsystem team we where working with.

Critical Design Review (CDR)

Hurdles & Solutions.

With not just the system members we were to present our CDR, members of the Applied Research Lab (ARL) were also coming to review and critic our subsystem design. Getting their feedback was critical.

Solution: On top of presenting our prototypes, we've created flow charts for how the application will receive, store, and transfer user inputs. Software that we will be using to accomplish the design was explained and defined. The ARL members provided many useful feedback during our CDR: pointing out logic flow errors on the flow chart we created and suggestions on how we should design our subsystem, which we took serious notes on.

Final Design

The final implementation met a huge set back when the software our team used to develop the graphical interface had proven too hard to program for our teammates.

Solution: We quickly researched other alternatives and found Visual Studio Windows Form Application to meeting our design requirement and programming capabilities. Immediate development as set in place to makeup for loss time. The final design was created, with all specification verified and requirements validates, and we finished the hand-off document all meeting exactly on the project deadline.

Hurdles & Solutions.

 

Memo.

  • Observation:
    • When developing the requirements and specification tables, it is impotent to leave room for changes before the actual production. Customer requirement can change mid-way, and worse, exponentially increase when the team demonstrate the capability to meet them. 
    • Flow charts are critical tools for understanding an application before development. We have made critical logic errors when we broken down the design steps and would have carried them into the design if it wasn't for presenting the flow chart on our Critical Design Review. 
  • Note:
    • Always have a development log, documenting all implementation and changes to the design at the end of everyday. If it wasn't for this documentation our team would never have got the hang-off document ready in the deadline specified.
    • Never be afraid to create a software on paper. Boxes as buttons and slides, transition between menus with different paper, the quicker the team can let the user test the design the better. Most often the not when a problem is found on the development stage of the application, the fix required exponentially increase depending on how deep the design is at. Having paper designs allows for quick product testing and can point out obvious design error early in the development stages.
Project-V (FPGA Design)

Project-V (FPGA Design)

Boney&Barry

Boney&Barry