UPDATE: We won the Phase II $ 3/4-million contract, which you can read about here!!!! One step closer to the moon!
Space has always fascinated me, that’s why joining this project was a no-brainer. Although I’m a MechE, I took the role of lead systems engineer. This project was part of a class which I had already taken (16-861 Mobile Robot Development/16-865 Advanced Mobile Robot Development), so being lead systems engineer allowed me to be highly involved in this project, and also function as the TA for the class. I picked up some new skills by working at a systems level, and also by acting as a leader for the class through managing younger students and even peers.
The current US administration has made two things clear:
- The US is going back to the moon
- It is going to happen with private-public partnerships
As an engineering student with work experience in the private sector (Honeybee Robotics), this is very exciting. I became even more excited when I found that CMU would be working with Astrobotic, Inc., a local aerospace company, to develop a small, 2-kg lunar rover, CubeRover. This was part of a NASA SBIR (Small Business Innovative Research) contract. The project became more than just a project; with this many stakeholders, this is something that has the potential to fly. In the same way that CubeSats revolutionized space exploration, CubeRover has the potential to revolutionize extraterrestrial exploration.
The first main objective for this CubeRover is to weigh less than 2-kg. (For comparison, Curiosity on Mars is 900 kg.) Sending anything to space is VERY expensive, so the lighter the design the better. In addition, a lighter design allows you to send multiple rovers for the price of one. These rovers can be sent into areas deemed too dangerous for one-rover missions, because they can be more expendable.
The second objective for this rover is to “do science”. Rovers are cool, but if they’re going to be sent to space, they have to do something. We picked two NASA defined Strategic Knowledge Gaps (SKG’s) for this rover to accomplish, modeling of blast ejecta (what do the thrusters from a lander do to lunar regolith) and terrain traffic-ability evaluation. These were chosen because they could be accomplished by a rover of this size with only a few sensors (camera and IMU).
Before I got started on systems work, I had to better understand the role of a systems engineer. A diagram that we used in the class final presentation is shown below:
The systems team is the glue that holds the project together. They set the timeline and goals, facilitate communication between subsystems, and monitor different budgets. Systems is the first team to arrive and the last to leave. In order to do all this, a systems engineer needs a thorough understanding of what each subsystem is doing. Even though I was a TA, I learned a lot because I had to broaden my understanding of avionics, something that I haven’t worked on much as a MechE.
Along the way, the project encountered a few roadblocks, but the systems team worked with subsystems to overcome them. Below are some examples:
One of the most challenging parts of developing a rover of this size are the thermal constraints. During the lunar day, the regolith can get very hot, and because CubeRover is small and close to the ground, it absorbs a lot of the heat radiated off of the regolith. Early designs of CubeRover included a solar array for recharging. This extends the lifespan of the rover, but also adds more heat to the rover. One early decision that had to be made was to cut the solar panels from the design. This limited the lifespan of the rover, but also simplified the design. The rover could be lighter, have a larger radiator panel for electronics to be mounted and cooled, and have a simpler avionics design. Future analysis on the PEL (Power Equipment List) also showed that the rover could operate for a substantial time, long enough to travel and get meaningful data, using only the 6 batteries we had in our design. This issue was first brought up by the mechanical team because of difficult mass constraints, but it was ultimately a systems level decision to cut the solar array.
Single Board Computer
The Single Board Computer (SBC) houses all of the electronics of the rover except for the rover. Having all electronics on a single board saves space, and allows the electronics to be easily thermally grounded to the radiator. In the timeline set out early in the semester, the SBC was supposed to have been designed and fabricated for testing with a midterm rover prototype. As the midterm date approached, we realized the chances of that happening were very slim. In response, we made the decision to control and test the midterm (and final) prototype using an Arduino, and later an ODROID, and have the Avionics team work on SBC development separately. Instead of having testing by the mechanical team stall, the systems team was aware of the schedule and the state of the project, and made a judgement call that allowed the project to move forward.
At the end of the day, the team was able to design, build, and test CubeRover. We compiled a 70+ page summary report to NASA, and wont the Phase II contract! In addition to that, I traveled with Astrobotic to present this project at the Lunar Exploration and Analysis Group (LEAG) in October of 2017. The abstract can be found here.