Week 14: Final paper and moving forward

    I have submitted my final paper (late) and I am okay with the content, although it could definitely be better. The database is in good shape on my end, my other team members seem enthused for their side of things, and we are all working hard over the break to put some finishing touches on it for a full demonstration. 

Overview of my final paper on building the BAT-MON database.

     I will be forever grateful to this scholarship program, which introduced me to opportunities I could never have had otherwise. Working within TRAIN has helped me grow as a person, given me the strength to face difficult challenges, and learn to work under pressure. I have learned what it's like to consult on a project and help plan out the steps to move forward, while also getting an understanding of how to complete a research project. I know that these skills will be very useful in the near future and I couldn't have had them without this program. Thank you to everyone including Amanda Chapman, Josh James, Matt Haberkorn, and all the other TRAIN scholars who have been so helpful and
welcoming since I have been a part of it. Good luck and keep putting in hard work to reach your goals.

Week 13: Approaching the end

 I hope everyone had a good Thanksgiving break. It was definitely a time for me to relax and catch up on things I have been wanting to do all semester. The transition to a new submission is mostly complete, with a few changes pending some meetings. I think that this new system is much easier for the average user and will help make incorporating map utilities much more seamless. 

Part of the new feature includes some reverse GPS lookup, called reverse geocoding. A surveyor will have their location saved, and predictive measures will be taken to see if the user is at a commonly accessed site. If the surveyor confirms that the suggestion is the correct place, then all of the habitat information will be filled out from previous sessions. Plans to incorporate a search bar with predictive text will also make this process very simple.

Large chunk of code, and that's not all of it!

I plan on continuing to work on this project even beyond the walls of PC, because it has meant so much to me to have the opportunity. Being able to help put together someone else's vision by supplying the mechanics behind how it works is satisfying and I know that I am helping contribute to an area of study that needs more researchers backing it. 

So far my paper has reached 8 pages and probably have 2 more to go, but its a full write up on the system as it is intended to work. I am very happy with how it is turning out.

Anyway, I wish everyone good luck on their finals, and I hope that you all get to wrapping up your projects as you had hoped since the start! 

Week 11: New data collection method, geolocation API

After completing the PDF parsing version of the project, I realized that this process can be simplified by parsing data from the KML files that are generated after each recording session. I put in a lot of hard work for the initial approach but we now have a better method of execution, which shouldn't take long too implement. This will also reduce the requirements from the end user when submitting their data.

Within KML files lies entries for each "hit" when the echo meter detects a bat call in the app. It includes everything needed like name of species, coordinates of each hit, time stamps, and more. With this information available, the process will now skip using a PDF entirely, and the user will only be required to submit audio files with the supplied KML file. That's it, no filling out forms or anything, just bring the generated files and you are set... Simple! 

This change has led me to working with a reverse geolocation API, and I believe I have settled on one that will fit our needs without costing anything. Reverse geolocation is the process of gathering location data from a set of coordinates. I have only recently started working with JSON and now have much respect for how easy it makes the process of collecting data from online sources for use in any application. In this case, the user's average coordinates will be referenced and relevant geolocation data will be returned such as address, neighborhood, city, state, etc. 

Example of a pin drop and the returned results from the API. In place of a pin drop would be coordinates from the user's KML file.

The plan is to hopefully prime this for scalability on the national or even global level. Imagine a bat database that serves the entire planet! Pretty exciting stuff. Can't wait to see how far this thing can go.

Week 10: Front-end to back-end translation

As I have been getting reacquainted with HTML and JavaScript, I have had to pass information regarding file uploads to the PHP script that works with the database. Progress has been made but I have learned some ugly things about the nature of interacting with PHP along the way. Multi-file uploads are sent via POST as a bizarre 3-dimensional array with file information split into string-based indices. The last index is a number associated with the index of the file you are trying to access. It took me a while to realize that and finally figured it out after using a var_dump. PHP is a great language but it can be a bit wonky sometimes. The good news is that I have files uploading and posting from front-end to back-end, although accessing the file information I need is still underway. Hoping to have it done by next week, as we are close to the final steps for this project.

Week 9: Uploader and exception handling

This week I dusted off my JavaScript knowledge to implement a new uploader. It has been years since I last touched the language, and I appreciated taking a look at it again now that I have more experience programming. I am still trying to remember how to appropriately style pages but it will come in time! Since users will be required to submit both a pdf form along with their data, I felt it was important to keep things simple for the user and make a drag and drop uploader that does the sorting and checking for you instead of having separate upload pages or entry boxes. The script will now sort through the files and manipulate them as needed. On top of all this, I have started the process of exception handling for all possible outcomes when using the uploader. This process can be challenging, but it feels very rewarding to know I am identifying all possible issues that may occur and supplying a procedure to deal with them appropriately.

Week 8: File management

Work on the project has transitioned into handling uploaded files. Since surveyors will have both a data form and ultrasonic recordings, the intention is to save these files on a server using a file naming scheme that is easily searchable. I have yet to receive a sample recording to understand what I will be working with exactly, but I have been told that the files are quite large, and can expand into sizes over a gigabyte. This would require a large server just to maintain a record of audio recordings. Thankfully magnetic drives are getting cheaper, so getting a few terabytes wouldn't be too much of an issue. As of now, I am able to upload and rename files as desired to a folder. Looking forward to checking out some data samples this week.

Week 7: Parser complete

The parsing setup is fully functioning. I still have to run extended tests but everything looks great so far. Users will upload their forms, the data will be parsed and sorted for upload, then added to the database without the need for intervention. I still have to address the process for uploading data from new locations, but this shouldn't be much of an issue. I will be finishing up some of the smaller things within the code and once testing is complete, I should be able to throw anything at it and keep it working as intended. The next steps are to work on user authentication and accounts, along with a method to store uploaded information that includes the document for backup and the audio files from surveys. As this project continues to move forward, it will be harder to post screenshots of completed work if we want to protect the integrity of the system since it may one day be public facing. I will do my best to include relevant media but it will be tough!

Week 6: New form and reference table

I ended up recreating the bat data form so that it is parsed in the order needed for upload, and to clean things up a bit. The database now has a reference table that will be used to compare against submissions. When a user selects a location, all other relevant data to that location will be auto populated in the new entry. This keeps the number of items on the submission forms minimal, reducing the risk for errors. I am becoming much more comfortable with MySQL. Using a query, I can scan the reference table to see if a location matches the user's selection, then pull all data from the matching row.

Week 5: Steady progress

Not much to report this week except progess is still underway. The reduced form fields in the PDF means that code will have to fill in missing information based on the location selected by the user. The biggest struggle right now has been finding the appropriate PDF creation system, since not all of them operate the same. It is important that the PDF creator allows drop-down menus that are compatible with the parsing system. As of right now, the drop-down menu included in the current PDF is not visible to the parsing system, so I will likely have to resort to paid software such as Adobe Acrobat Pro to fix this. I have gotten better at working with SQL queries through PHP. It is quite powerful to request information from a large database instead of having it stored locally. I hope that in the future, I can lay groundwork for a system that will request infromation from the database and be used to create reports or generate charts. I will be working with Matt on goals for the system and other features that I can implement. Looking forward to the future of this project!

Week 4: Form design

Matt pointed out that the PDF forms from last week had a lot of fields to fill out. This can create more opportunities for a user to enter the wrong data. As a solution, the forms will now ask for location only, and the rest will be populated automatically with code that references a categories table. I am still working on a better way of counting bats, since PDFs can be difficult to make dynamic (I also don't have the pro Adobe suite).

I have made some progress on the app this week as well. It has been fun to work on and I am learning a lot. I think this approach may be possible, since the mobile platform would be fully dynamic and worth setting up developer accounts for. The user coold select locations or species from menus, add or subtract rows for species, and use more. An app would allow uahtorized users to view graphs and statistics about the existing database if they wanted to.

Other than that, my research proposal came out okay although I was behind by a day or two. Normally I am on top things but the past week has been a bit too much work. I may have to modify my approach but I plan on observing assets and drawbacks of the current methods of data collection and get user feedback. I hope to then test the methods for susceptibility to error by including randomized test cases or scenarios that are likely to occur. The last bits of the project would be to modify the methods to better suite surveyor's needs and repeat the testing process.

Week 3: Prototype application

After reviewing some of the form functionality last week, I have been messing around with making a data entry application on the side. I am figuring out how this will work with an air gapped network for now, but I have decided to build the prototype layout first and work on that a bit later. I have plenty of other features I would want to implement that make the data entry experience much easier for the user, but I don't want to give out too much information yet.

Building the skeleton of the application 

Using Flutter makes this build very intuitive and easy from my end, and will help me stylize the forms to make it visually appealing for the users. When ready, deploying to Android is no problem, but publishing an application for iOS requires a developer license plus the application is made available to the public. Access control would be needed here but that is something for another time.

Week 2: Database and form progress

This week I was able to work on a new form for data entry to the bat database. The existing PDF had issues with tab order, which also controls the order of parsed elements placed into the array. PDF designing applications will arrange tab order based on the first element being the lowest index, with the most recent being the highest index. With tab order fixed, it is easier to navigate using the tab key and also simplifies the code for parsing documents. The only requirements to fill out the form are Adobe Acrobat which is present on both Android and iOS.

For now this method is a temporary solution. There are easier methods of filling out forms without the need to manually fill each entry and reduce the risk for errors or other issues. I currently have the submission page set to that it rejects uploads that do not have the appropriate forms filled, prompts users to check their form data, and try again.

The existing data from previous surveys has been uploaded to the database and resides in a central table. I am working out a system where submissions are added to the table and flagged for review, so that acceptable entries can be verified.

Week 1: Ozone update, BATMON, and more

Hello again!

It;s nice to be getting back to work. I am grateful to have been given this internship opportunity again. I had a blast last semester and know it will be just as good this time around.

Over the summer I worked on my ozone project and came to a dead end. The equipment within my price range is not going to be suitable for getting any sort of useful readings. Although it's unfortunate that I cannot proceed with it any further, I have other things that I can work on. I gained a wealth of knowledge throughout the research and build process so although I am moving on, I feel this experience had so much value for me. Working on this project helped me better understand the process of pursuing ideas from scratch and how to compose a research paper. For now, this will go in the archives.

Database table entries created from a PDF parsing script!

So far in this first week, I was able to pick up where I left off last semester with the BATMON project (PHP, HTML, MySQL). I am really excited to have this going again! I took a slightly different approach to uploading data and implemented some measures to prevent injection attacks (server will not be public but always good practice). After some reworking of the structure I was able to get the system generating new database tables for each upload, which is the foundation of what needs to be done! Next step will be to add data to an existing table that holds all previous survey records. Retaining uploaded documents, storing audio files, features for registered users, and some input validation are next on the to do list. I need to thoroughly test things before adding more complexity so working in small steps is the best approach right now. So far so good!

Over the summer I did some work on an augmented reality project using Unity (C#), which I plan on developing throughout the semester. I also got invested in learning to use a development kit called Flutter, which is a project from Google designed to allow software development in one language (Dart) which can then automatically compile to both iOS and Android. I believe integrating the two would make a custom applicatin interface with AR capability a simple and seamless process.

In other news, I am serving my final semester on the ASCEND team, assisting with special projects and working on the video streaming system. The spring launch was cancelled due to COVID, but we have rescheduled a launch for this October! The work being done this semester will not be deployed until sometime in the spring so the pace is a bit slower than usual. I find it nice that I can still be part of the team and have a bit more flexibility for other things that I need to work on (like this stuff!).

I wish everyone good luck this semester and to keep moving forward no matter what!

Week 14: Research Paper and BAT DB

It has been a busy week for my TRAIN projects! I happened to have a bit of an easier week compared to most with my other classes, allowing me to devote more time to my ozone monitor and database projects.

I had a bit of confusion on exactly what I had to do to finish the research paper, but thankfully I have found some sources and references to help me write a good one. I really want to start strong and have a good looking research paper. It feels nice to be back on track with a clear vision of what I need to do. In its current state, my research paper is more than halfway done and looks great. Plenty of figures that explain what I am trying to do in a manner that is easy to understand without avoiding specifics of how/why I have chosen this research. I have also been making a little more progress on the operations, including the basic flow chart, gathering parts, compiling figures, and other information to help assemble and test the device.

Basic flowchart of the device's methods for gathering and examining samples. Detailed measures will be included that offer input validation, ensuring mechanical operations, and more at some point in the future.

The BAT DB is progressing but I have run into a few issues. Since I have had to completely set up the test database on my own computer, it has been tough to push information into the database tables for some reason. I am new to working with PHP/MySQL/XAMPP, so I have to learn what I am doing wrong that is preventing me from populating tables. The document parser works like a charm and prepares an array of information ready to send to the table, so the only thing left is to populate, test, and possibly refine the list of data points. I am hoping that I can move on from this soon, because we are close to a fully functioning system that would make uploading bat data much easier and available to all platforms regardless of device.

I hope everyone is working hard and making good progress on their final papers/posters. Good luck, make sure to eat healthy and go outside!

Week 13: O3 Sensor Parts, Symposium Complete

The parts for most of the O3 sensor package are in. I have been able to select a UV-C LED that emits within the ± 275nm wavelength range, keeping most of the emissions below 280nm. This is far enough into the UV-C band that any fluctuations should correspond to a voltage change from the UV-C sensor. I am still researching materials that I can use for the air tube. Quartz seems to be a good fit, but it is quite expensive. UV-C also can degrade certain materials so I need to find something suitable for shielding 

The symposium presentation went well. We had a few rehearsals and were able to share our findings, while hearing from the other participating colleges. Holding the symposium online turned out better than I could have expected. Research was presented from all aspects of space, and I was able to learn a lot. The main keynote speaker was Moriba Jah, who specializes in management of space debris. He presented a mapping project which is meant to track man-made objects orbiting Earth, while making it publicly available to hold nations accountable for what they place into space. This is extremely important to have, especially now that private space services are becoming realized and with nations likely moving to satellite based warfare. What makes it even more important is that there are few regulations regarding space object management. Many of these presentations should have been recorded and I will post links once they are available.

I am very proud to have taken part with the Fall '19 and Spring '20 teams, and they are all destined to move onto big things. I really have a soft spot for the program, and I have volunteered to work on special projects for Mr. V for the next semester. This will include assisting with transitioning to a new team, building the O3 sensor, and creating a battery monitoring system for the next launch.

Week 12: Adjusting, final paper, ASCEND symposium

This past week as been a bit difficult. I have been trying to adapt to this new work situation as best I as I can while managing the new structure of my classes. I am typically used to going from place to place to take care of things, and chatting with my peers once in a while to get through the long hours. This pandemic has really highlighted the reasons why I prefer to take classes in person.

I have been prepped on the next steps for the rest of the semester and have to pick up on my final project again. I still have my abstract and project background for the ozone package but I also have the option to write about the database work I have done. Maybe I will do both? Who knows.

ASCEND symposium has transitioned to a Zoom format and is happening this weekend. The team will be doing a quick slideshow on the technological achievements and progress made over the past academic year. Hoping all goes well, and looking forward to seeing what other teams have put together.

I hope everyone is managing well. Hang in there.

Week 11: Back to work

It's nice to be back. I hope that everyone is healthy, well rested, and ready to get back to work.

Although everything has transitioned to an online format, I am grateful that I can still work on some aspects of the database from home. I prefer to be around other people and in a lab environment since I do well with structure, but I have to adapt to the situation in order to move forward.

I am a bit stuck on my research project right now. I am very much a novice at writing abstracts with variable tables and don't know where to look for help. The variable table is the biggest problem, since I am not exactly altering any inputs to analyze output. Testing the device would require this, but the results of the project are based more on if an optical ozone sensor is sufficient for high-altitude ballooning or not, and whether or not it can be done within the given constraints.

ASCEND symposium is still happening, but it is voluntary and will be held through a web conference. I have been working on slides as well as the battery monitor/status indicator for the payload but we don't have the ability to assemble and test. According to my last phone call with ANSR, it appears that all the other colleges are in the same position. Nothing is set in stone but it is looking like we will have to carry out the launch in the Fall semester, separately from the next incoming ASCEND team. I am glad we will still get a launch but it will be some time until then.

Battery monitor (left breadboard) using the Arduino Uno as a programmer/power source.

Looking forward to seeing you all when this is over! Until then be safe and healthy!

Week 8: ASCEND and TRAIN Lab Close Temporarily

Thursday of last week, the ASCEND crew got together to get in some extra work time. Our team had time to prepare for a battery test, 3D print structural components, and work on the custom PCBs that finally came in.

3D Printing one of the internal shelving pieces.

Constantino, Javier, and Misgana work together
to make custom cuts to our new PCBs.

The lovely 3D Printer!

Genesis soldering components
for the atmospheric profiling system.

Custom PCBs from CustomCircuitBoards.com!
Thanks for the freebies!

     

Friday however, we showed up to campus and were told to not come back until further notice due to the corona virus. The team grabbed what supplies we could, and we are now working remotely. The space grant people have advised us that both the launch and symposium have been cancelled, and it is starting to look like we won't reschedule until Fall semester. In the mean time, we have been working on abstract submissions, the presentation, and will be polishing up whatever contributions we can from home.

Spring break has been extended by another week, and it looks like we won't be back into classrooms any time soon. I will miss seeing everyone around, I hope you all stay safe and make the most of quarantine time!

Week 7: Spring Break and She Se Puede

Spring Break hasn't been much of a break, but it has been full of great experiences. I was given a chance to work for She Se Puede teaching a circuits and an Arduino course.

Instructing students how to build a buzzer game circuit. Great for learning the breadboard.

Teaching is something I have considered pursuing. Nichole Spencer has been organizing a 3-day event for the Si Se Puede Foundation, that has a group called She Se Puede, which is specifically for young women in STEM. Through the experience, students will get exposed to engineering concepts and get a chance to work on Arduino projects.

The students had no prior experience, so my partners and I had to develop a curriculum that went from the very beginnings of  using electricity to developing Arduino programs. It taught me a lot about simplifying material, making it engaging enough for kids, and being prepared for unexpected situations.

Wiring an Arduino using the overhead document camera

Overall the course went well. Although there were some hiccups, we were able to quickly switch to projects that we had the time and supplies for. It is very rewarding to know that through foundations such as Si Se Puede and Hermanas, I've been given a chance to inspire the next generation of engineers, and hopefully get more women into STEM careers. In the future I hope I to have more opportunities to help young people get the drive that has inspired me to work in science!

Week 6: BATMON and Payload Battery Monitor

BATMON:
Progress on the BATMON project forms is going well. The goal is to import the existing data into a MySQL database and add onto it using form submissions. The forms will be parsed and automatically upload the data to the database. We are finalizing the lists of data needed to be included, and I will be working on learning to auto populate fields within MySQL if a survey location already exists within the database. Hoping to do this with another database table that can be searched to find existing locations, and auto populate based on a match.

ASCEND:

The carbon fiber housing has been cured, so internal components are the focus of the project right now. Both the mechanical team and the video stabilization team are 3D printing parts that will hold the internal components. Our custom PCB designs were sent to the manufacturer for printing, and will arrive March 10th. We were able to work with CustomCircuitBoards.com, who was kind enough to donate these to our project. Thank you Zack!

Battery monitor with OLED display, tracks voltage, amps, and Watts with values and a graph.

We are hoping to do a full capacity battery test this week or next week, where we test our main power supply and monitor the output until it runs out of juice. We will also be placing the system within a container filled with dry ice to get as close to temperatures at high-altitude as possible. I recently began taking an interest in building circuits from scratch, and ditching using Arduino all together. Using an ATTiny85 MCU, I assembled a battery monitoring tool with an OLED screen using some libraries found online. I am hoping to hook this up to the system and see if we can graph the output of the battery during discharge period. If all goes well, I can modify it in time for launch to display the state of all device within the payload, so we don't have to open the the lid.

The team is working hard to complete the payload by March 28th, so things have been very busy for all of us. I will try to take more photos!

Week 5: Parsing the PDF

Through our most recent endeavor into data management, there were some issues regarding our ability to parse a PDF containing user-filled data forms. Hours of experimenting with different PDF-to-text classes provided some form of text output but the entered form data was missing. A band aid over the issue was to fill out the form then use the print to PDF function found on most devices, flattening the document into just a layer of text. This presented other unexpected issues that did not provide the results we needed, including blank or unreadable output.

Through some experimenting, I was able to find a parser that will pull just the form data and nothing else. Using a doc parsing class, I was able to pull form data without having to save to a new file or print to PDF.

In order to gather the form data in a way that organizes it for upload to the database, the doc class must arrange data in a way that prepares it for assignment to the appropriate cells. Browsing through the class structure and understanding how it performs text collection from documents shed some light into modifying it to insert delimiters between each parsed form field.

You can think of a delimiter acting as a cell wall like those found in spreadsheets, but instead data is separated by a text character. Using character delimiters allows scripts to easily recognize the start and end data points and can easily isolate what comes before/after/between the delimiters.

In its default state, the doc class uses the space character as a delimiter, which makes organizing data difficult. Using the standard comma delimiter can be useful here, but what if your data points must include commas? This can pose a problem or require limiting the scope of acceptable characters in a form field.Using an uncommon character as a delimiter ensures that almost all characters can be included in the data points, giving much more freedom of choice to the user.

 The resulting combination of code now spits out a delimited string that can be easy converted and organized into an array, that can then be sent to the database.

Week 4: Jet Propulsion Laboratory

Long post, but ever since starting this blog I have found it to be an opportunity to preserve memories I am making through my journey in STEM. I hope you all enjoy the read but if you like just browse the photos!

Monday:

Skipping the small stuff, we arrived at JPL with about half a day to spare. Our team called Navy Nova was assigned randomly so we had to get to know each other quickly. There were 40 students in total, and I was the only one that wasn't from California due to an unusual last-minute change (Coach Luu you were tough but it led to an upgrade, so thanks). Most of the day was spent with introductions to our staff, the competition, and objectives. All of the team mentors were mechanical engineers who have worked on the Mars 2020 project. Our mentor Amiee had worked on the Mars Helicopter, and is now working on the Europa Clipper! Wow!

With backgrounds in physics, math, computer science, mechanical engineering, and chemistry, everyone understood their strengths and weaknesses so positions were assigned with little issue. I was elected team lead for being the only one with previous Lego EV3 experience (shout out to Mr. Villicana and ECE103!) and some public speaking under my belt, so it helped us get the ball rolling quicker. Roles are designed so that if any one person fails to do their job, it can cost the entire project their points to win the competition.

In summary, the project is broken down into building, testing, and deploying a Mars rover made with Lego EV3 kits, while producing progress reports, financial reports, and a final presentation meant to simulate bidding for a NASA contract. This requires thorough planning/testing of mechanical and software designs, including part research, software concepts, and applications for using sensors. Our budget starts at $500 million and we have to keep record of inventory, use of each part, marketing costs, bonuses, and fines. Parts are bought once they are connected to any piece meaning no test builds unless you want to keep them.

As for rules, all sensors in the EV3 kit were allowed except for the proximity sensor, a bit of a setback since it is the primary tool for object detection. Use of a sensor during a retrieval results in double points. The device must have a minimum of three wheels, which should all be touching the ground (roller ball does not count as a wheel). The course will have a square within the starting tile that we call home base. The rover is allowed to be picked up and positioned while within the tile, but once we run a program, the rover must be able to retrieve an object and navigate back to home base without any human intervention. Failing to return to base results in a 30-second penalty where the rover is reset cannot be touched until the time is up. We have a total of 10 minutes to run each course. Beforehand, we are given a 1-hour test period to rent materials similar to those on the course at a cost from our budget. Prior to the missions, we are given a 2-minute period to view the course, and an hour to plan accordingly. Finally, just before the mission, we get a 2-minute test period and another 2 minutes to make any changes.

The white climate-controlled box houses the Mars 2020 rover, seated in a force-dampening structure for protection.

On the way back to the hotel, it was drawn to our attention that the Mars 2020 Rover and its kit were packed for transport earlier in the day, and that it was leaving for Florida that evening! Too bad we didn't get to see it up close, but we still got to see $1.8 billion in a box!

Throughout the rest of that night, I was able to introduce the software team to the fundamentals of EV3 programming as well as the basics of sensor usage. We stayed up late brainstorming on how to accomplish the tasks assigned for the next day, quickly learning that sleep was to be had after the trip was over. Since we had to work with our lack of object detection on the course, our best bet was to retrieve rocks that would be available with a direct, clear path. Since we would be able to rent course tiles and different rock sizes for an hour beforehand, the software team planned on measuring the tiles and using the Pythagorean theorem to get a direct distance to an object. By calculating the circumference of the tire, we would divide the distance to travel by the tire circumference (one wheel rotation) to get an exact number of rotations to travel to an object. The rover would then engage its capturing mechanism and reverse back to the home base. The night ended with a good tone and we had a clearer idea of how to accomplish our goals.

Tuesday:

The Dream Team!

Feeling confident but tired, we arrived at location to begin working right away. This was our longest day to work, as the next day would be spent touring JPL and having discussion panels. The mechanical team quickly began assembling the rover and came up with a sturdy reverse trike design that had enough stability to climb obstacles without rolling over, and would allow us to have freedom to rotate once incorporated. The software team began work on making master code that would be duplicated with variable changes for each distance once we had our 2-minute preview of the course.

Olympus the Mars Rover

Nearing mission time, as per the rules, we were given an opportunity to rent materials if we wanted to use our budget for it. We all agreed that any real mission from NASA included thorough testing of all possibilities with realistic physical elements, so we rented the entire suite of rocks and two tiles to test our range. We created a unit of measurement using 1 tile length, and that became be the fundamental unit for converting into centimeters for our rover commands. Running our various tests, we were able to pull single rocks of each size, and even the entire set of rocks with the first set of code and custom parameters, capable of stopping at measurements down to the centimeter.

Map compiled from the 2-minute preview

During the 2 minute preview, we saw various obstacles on the course and Olympus Mons in the center of the 4 x 4 tile course. Funny enough, Olympus Mons had a stone on top worth the entire board, which was probably an ego test, and we weren't falling for it. We divided the course into 4 sections, and paired up to do detailed drawings of each sector (no photos). After compiling the map drawings, we had rough calculations of X and Y tile lengths for the Pythagorean theorem formula. Each rock's position was numbered and a custom program derived from the master code was made to drive to each rock, totaling in twelve unique programs along with some programs based on single tile lengths. The back quadrant was excluded since there were no direct navigation routes available, and time to refine the turning code wasn't available before the mission.

Since each retrieval that used a sensor would result in double points, I proposed the idea of using the gyro sensor to detect if the rover was on a flat surface before grabbing rocks. If the rover was detected to be sitting flat on the tile, it would lower the mechanism and return to base as normal. If the rover was uneven due to one wheel resting on a rock, it would make a single wheel rotation forward, lower the claw, one single rotation backward to fix the offset, then continue with the reversal to base. Since our trike design and strong claw allowed us to drive over anything and also pull it back on reversal, our rover could attempt to position itself into a better spot before returning. Incorporating this as a necessary step before any action with the claw was taken made the sensor check orientation on every single run regardless of the situation, giving us bonus points no matter what.

 

During the run tensions were high, but our 2-minute test run seemed to go as planned. Realizing the short time to do anything significant, we opted to just speak on strategy during this time instead of scrambling through changes. Running the course the first few times with some misses, we grabbed the first few rocks with no issues. However, we soon found that some of the rocks were taped to the tiles, and caused an offset to our rover's backtracking maneuver. This resulted in three 30-second penalties, which were used to discuss the next steps until we could touch the rover again. After all was said and done, we collected nine rock samples, roughly half of the board. Although we didn't know the other team's totals, our confidence was high. Apparently we were the first team to ever use a map (?!) so that added our natural high of a job well done.

Wednesday:

Now for the really cool stuff. The JPL tour took up most of our day, and a large portion of that was for the gift shop (it was necessary). Our tour consisted of The Charles Elachi Mission Control Center, the Mars mechanical testing room, and the Microdevices Laboratory. To keep it short, check out the photos:

The Charles Elachi Mission Control Center, where all spacecraft
communication throughout the universe converges into one place.
Known affectionately as The Center of the Universe

 

If you have ever seen a Mars mission during entry and landing, you have seen this room!

JPL's lucky peanuts, held my many famous people!

Real-time data visualization coming from various spacecraft! So cool!

Room with clones of Insight, and Mars Curiosity for mechanical testing.
When the Insight drill became lodged on the surface of Mars, test methods to safely remove it were attempted here!

Microdevices Laboratory with history of accomplishments

After the tour, we had another rental practice session, and were given a rover to capture instead of rocks. Test runs went as planned, and we decided on two very minor changes of removing the rubber ring around the wheel to assist with pivoting and removing a piece from the claw. We were warned the day before that the next course was going to be harder, and after the 2-minute course preview, we could see what they were talking about although we had prepared for something similar. The new course had a displaced tile housing one of the rovers, there were more sand bags, and alignments of rocks blocked most of the direct paths to the rest of the rovers except for one. Knowing that we could get away with capturing one rover, we had to quickly plan to navigate for the other three.

The master code was modified to account for 90-degree turns. Instead of storing a single variable to track total distance, up to four variables were used to store the segments of each straight distance to travel. Our mapping gave us multiple options to design routes, and the software team decided on what they thought was best for simplicity. They decided on keeping the original programs and adding twelve additional options that included turning routes.

Hamming it up with Olympus

During the run, we felt that we had a good chance of getting two rovers, and at the least were very confident on getting one. The other two rovers were in highly compromised positions, and would only be attempted after grabbing the first two. The stress of the situation added up and a few runs were made prematurely, or with the wrong program selected. We suffered three penalties in the first 5 minutes, which gave us time to think clearly about our next move. 

After the first rover was retrieved, we focused on the one that was tucked in a rock quarry. To clear a path, we attempted to use one of the original programs to go straight and peel away rocks, essentially excavating the area before rescue. The attempt failed as we found out that the rocks were coated with a sticky substance and were partially adhered to the tile. The only thing left was to use the original turning route, and it worked to pull the rover into an empty area but clipping some rocks rerouted us into Olympus Mons. To our surprise the rover was strong enough to move the mountain! This gave the rover its name, Olympus.

We were happy to see that the targeted rover was now out in the open and in a direct path for retrieval. A quick selection of one of the old programs gave us our second retrieval, which had us feeling elated. The odds that other teams would have grabbed more than two were slim, so we felt we were in a great position overall.

Although it was a job well done, there was no time to celebrate. We spent the rest of the night on our NASA pitch and sacrificed sleep to practice our parts and make slides worth presenting. We were given creative control over how to do the presentation, and based on my ECE103 experience, I suggested that we treat it as being real. Our teams made descriptions of  EV3 components by using real-world technology references, such as radio isotope power generation for the battery and aerial imagery for our hand-drawn maps. Our marketing manager had been working social media, planned for presenting an outreach program, and created an awesome intro that showed off the rover. It was a nice touch that really made the presentation shine.

Thursday:

To keep it short, we crushed it with the presentation. Now that everything was over, we were able to discuss the results with other teams before the winning team was announced. Through speaking to other teams, we learned that our team had the highest retrieval score in the first mission due to bonus points, as well as the highest score and rover count during the rescue mission. Once financial reports were released, our team was the only one to have ended with a surplus over the original budget due to bonuses, and although we had incurred the most fines. Our ending budget was roughly $740 million!

I am happy to say that we won the competition! Our team received some cool memorabilia, placards, and Phil from our software team (operating the rover) was declared the team MVP, with a commemorative coin made from Curiosity Rover test metal. The experience was a roller coaster, and I made some great friends for life while learning so much about engineering and professionalism.

With the knowledge JPL has given me, I feel that I have a stronger vision and I am more prepared for what the future has ahead. I have insight from professionals who were once in my position, have learned about being a better job applicant, had a chance to apply my skills in leadership under pressure, have tips on what companies like JPL look for in a resume, all while seeing some of the most remarkable engineering in human history. I hope that I get to see some of my team mates in the near future, as we have some great memories to share.

Thanks for reading!