Northeastern University – Students for the Exploration and Development of Space

SCOUT and DOGHOUSE

Team Members: Julia Abouelheiga: Undergraduate Computer Science and Business Administration Major,

Paige Butler: Undergraduate Mechanical Engineering Major, Javier Coindreau: Undergraduate Computer Engineering and Computer Science Major,

Madisyn Dudley: Undergraduate Electrical Engineering Major, Lindsay Euston: Undergraduate Mechanical Engineering Major,

Dylan Gates: Undergraduate Computer Engineering Major, Xinan Huang: Masters Electrical Engineering and Computer Science Major,

Elise Johnson: Undergraduate Mathematics and Biology Major, Naren Kolli: Undergraduate Electrical and Computer Engineering Major,

Grace McDonough: Undergraduate Mechanical Engineering and Physics Major, Julian Morgen: Undergraduate Industrial Engineering Major,

María Belén Ou: Undergraduate Mechanical Engineering Major, Lindsay Riggs: Undergraduate Computer Science Major,

Matt Schroeter: Undergraduate Bioengineering Major, Kyle Tobias: Undergraduate Electrical Engineering Major,

Jake Trimble: Undergraduate Computer Science Major, Jack Tuthill: Undergraduate Physics Major,

Madeleine Weaver: Undergraduate Electrical and Computer Engineering Major, Jeremy Webster: Undergraduate Computer Science and Mathematics Major,

Andris Zonies: Undergraduate Computer Science and Physics Major

Advised by: Professor Alireza Ramezani, Ph.D.

Professor Taskin Padir, Ph.D. Massachusetts Space Grant Consortium (MASCG)

Quad Chart 4

Executive Summary 5

1. Problem Statement and Background 5

2. Project Description 6 2.1 Solution Description, Overview 6

2.1.1 - Potential Stakeholders 6 2.2 Ideation 7

2.2.1 - Communication 7 2.2.2 - Navigation 7 2.2.3 - Power Distribution 8 2.2.4 - Power Transmission 9 2.2.5 - Power Generation 9 2.2.6 - Solar Panel Deployment 10 2.2.7 - Mobility 10

2.3 - Final System 11 2.3.1 - Communications 11 2.3.2 - Navigation 12 2.3.3 - Power Distribution 14 2.3.4 - Power Transmission 14 2.3.5 - Power Generation 15 2.3.6 - Solar Panel Deployment 15 2.3.7 - Mobility 16

3 - Proof Of Concept Testing 16 3.1 - LiDAR 16 3.2 - Pathfinding 17 3.3 - IR Comms 18 3.4 - Solar Panel Deployment 19 3.5 - Wireless Charging 20 3.6 - Battery 20 3.7 - Simulation of Electrical Systems 21

4 - Roadblocks 22 4.1 - Technical Challenges 22

4.1.1 - Pathfinding 22 4.1.2 - Communications 22

4.1.3 - Solar Panel Space 23 4.2 - Scope Changes 23 4.3 - COVID Remarks 24

4.3.1 - Location Logistics 24 4.3.2 - Red Tape 25

5 - Results 25

6 - Path to Flight 26

7 - Timeline 27

8 - Budget 28

Appendix A - Full Spending Reports 29

Appendix B - By System Budget Breakout 31 SCOUT Lite 31 DOGHOUSE 32 Connections 33 Shipping 33 Tools 34

Appendix C - Full Simulation Diagrams 35 SCOUT Lite Simulation 35 DOGHOUSE Simulation Diagram 36

Acknowledgments 37 Additional Acknowledgements 37

Quad Chart

Executive Summary Northeastern University spent the last 14 months developing SCOUT and DOGHOUSE,

a rover and support system designed to navigate permanently shadowed craters (PSRs) at the moon’s south pole. PSRs are believed to be a source of water ice on the moon, so the system aims to explore the area to support future ISRU efforts. The system is split into two parts to overcome the challenges of PSR exploration. SCOUT is a legged rover, designed to carry scientific equipment into the PSR and provide movement versatility to deal with unknown terrain. It navigates using LiDAR and sends the data it receives back to Earth to create a map of the PSR. DOGHOUSE is a support system that sits outside of the crater. While SCOUT is isolated in the darkness of the PSR, DOGHOUSE gathers solar power and relays communications via line of sight from SCOUT to the lander. When SCOUT needs to be recharged, it returns to DOGHOUSE from the crater and is charged wirelessly via DOGHOUSE’s inductive coil charging system. Communication between SCOUT and DOGHOUSE is done via infrared (IR) to keep power demand low, but the relay to the lander is done over WiFi.

Due to the onset of COVID-19, a legged version of SCOUT was not built and needs further development to assess viability. A stand-in demonstration system, SCOUT Lite, was built to test the viability of the core electronics of the SCOUT that had been designed. Additionally, smaller demonstration subsystems were used to perform proof of concept testing for LiDAR scanning, infrared communication, wireless charging, and pathfinding algorithms. DOGHOUSE was built in line with the original proposal.

Despite the descoping of aspects of the system, the core deliverables of SCOUT Lite and DOGHOUSE were successfully confirmed to solve their problem sets. The IR, LiDAR, and wireless charging systems were independently tested with paths for further testing and development for each, and the remaining systems were integrated and tested as a whole. Further development of solar panel deployment and legged locomotion is required to complete the development of the original design.

1. Problem Statement and Background

In 2024, the Artemis III mission will return humans to the moon. This mission and the missions following intend to establish a long-term human presence on the lunar surface through a gradual buildup of infrastructure enabling stays of increasing duration. Integral to this mission is the navigation of PSRs. The lack of sunlight in these regions creates permanent cryogenic temperatures which are expected to trap water in the form of ice. PSRs could become sites of crucial ISRU programs; however, missions to explore these craters and utilize their resources require more information and infrastructure to operate.

Due to the permanent darkness, information on PSRs is very limited. The Lunar Reconnaissance Orbiter Camera’s Narrow Angle Cameras have provided imaging that hints at

the general shape of the terrain in PSRs but is not detailed enough to provide information for navigation or infrastructure placement. The LRO’s data on soil properties indicates that the dust will be even more porous than elsewhere on the moon, which will create difficult navigation challenges on shifting terrain, but the level of difficulty remains uncertain. These predicted difficulties suggest a need for a rover that can cope with uncertain terrain and is protected from the damaging regolith on the moon’s surface. In addition, the location, density, and material characteristics of the water ice in PSRs are unknown. Initial sorties from rovers are needed to map out navigation paths in the craters, give experience with moving through their unique terrain, and characterize the water ice that is motivating the exploration.

These rovers will encounter a few infrastructure challenges along their way. The permanent darkness in PSRs prevents the use of solar panels to gather power, so rovers going in need get access to solar power from outside of the space that they are exploring. Any lander that brings the rovers to the surface would also need to land outside of the PSRs to provide a safe, known, and relatively flat landing surface. Once they dip below the lip of the crater, the rovers would thus be incapable of contacting their lander via a direct line of sight to communicate with earth. These problems together indicate a need for a separate support system which is capable of providing power and communication support for as many rovers as possible.

2. Project Description 2.1 Solution Description, Overview

In response to the challenges posed by PSR exploration, we designed a legged rover, SCOUT, and a support system, DOGHOUSE. On the way into the PSR, SCOUT will deploy DOGHOUSE at the crater’s edge. There it will receive solar power while the rover is in the dark of the PSR. Upon placement outside of the crater, the system will deploy a solar panel. It will charge up while SCOUT is in the crater, then transmit power via wireless charging to bypass lunar dust clogging its charging ports. DOGHOUSE will communicate to SCOUT with IR and relay to the lander with WiFi, thus giving the rover a low power route of communication to the lander.

SCOUT is an exploration rover, designed to carry scientific equipment into a PSR and gather initial data. The system will use LiDAR data to identify obstacles in the dark and plot smooth routes. When unexpected obstacles occur, the system will be able to fall back on the versatility of legs and adapt to the shifting terrain that PSRs are likely to present. The system will additionally relay the LiDAR information back to earth, where it can be used to create maps of explored locations.

2.1.1 - Potential Stakeholders

Future PSR Exploration: DOGHOUSE is designed to be independent of SCOUT. Its wireless charging port can interface with other rovers and support multiple systems, and IR

communication can be implemented for communication on other systems. Beyond its first mission, DOGHOUSE can become a form of infrastructure that can provide power and relay communications for future missions into PSRs. This infrastructure could prove essential in a transition from exploration to permanent ISRU programs.

Exploration/ Humanitarian: Crisis managers may be interested in pursuing autonomous navigation of disaster zones. LiDAR provides a light-independent form of mapping which allows navigation in any condition, and a quadrupedal system provides the versatility needed to deal with any terrain. The wireless charging capabilities of DOGHOUSE could additionally be adapted into a charging system for any environment. The lack of electrical contacts means the system could be fully waterproofed to operate anywhere, including underwater. 2.2 Ideation 2.2.1 - Communication

In the design phase of the project, the communications for the project were split between the three legs of the full mission: the lander, SCOUT, and DOGHOUSE. The lander that would deliver SCOUT and DOGHOUSE to the moon requires WiFi input, so it was clear that DOGHOUSE would need to have a WiFi module. The driving goal for SCOUT to DOGHOUSE communication was to conserve power, so rather than use WiFi across the whole system, infrared communication was chosen. The system began with a single IR transmitter and transitioned to being a two transmitter system after some technical challenges (See 4.1.2). One large design assumption we made was that the background IR interference coming out of the PSR would be minimal to none. Because the regions are unexplored, there’s no definite answer, but that choice felt and still feels reasonable.

Knowing that IR would have a heavy dropoff based on distance in addition to having high background interference, an amplifying and filtering PCB was designed. To ensure the compactness of the system, it was made as small as possible without excessive parasitic capacitance. In addition, the second IR transmitter design created after the mid-project report was made as a notably simpler and smaller system, designed exclusively for reliability while sacrificing bandwidth. 2.2.2 - Navigation

SCOUT will have to navigate terrain with uncertain properties without light to illuminate the environment. The navigation solution should require as little power as possible to allow more time in the crater. We initially considered using stereoscopic cameras like those aboard other rovers and providing light via either a camera flash or mirrors redirecting light from outside of the crater. The camera flash was predicted to be much too power-consuming, however, and a mirror array would create too large a failure point that could leave the system stranded in the crater. Some digging led to specialized LiDAR scanners that rely on singular scans rather than

the now popularized constant scanners found on autonomous vehicles. The team chose this over a constant scanner because the smaller intermittent scanner would have to undergo less stress. This scanner works on the critical design assumption that regolith found in a PSR is not absorbent or semi-absorbent of infrared radiation. This design assumption felt safe given the composition of known regolith does not match any material known to absorb infrared radiation.

When it came to using the data collected by the LiDAR scanners to create maps, the team initially began using three-dimensional maps stored in occupancy grids. We felt that this was an under-utilized technology that would provide additional capability for future missions where we might have an interest in exploring confined spaces like lava tubes. We then decided to transition to two-dimensional space for the sake of information storage space and communication load. For pathfinding, our initial ideation included research into several different pathfinding algorithms. We settled on using the D* Lite graph traversal algorithm. We selected D* Lite because of the rocky, uneven terrain of the moon. D* Lite allowed the ability to take into consideration factors other than distance when selecting a path, including terrain. As the craft encounters unexpected obstacles that it might have missed or misidentified in its original planning, D* Lite would allow for efficient localized re-planning to occur.

2.2.3 - Power Distribution

Power distribution became a critical component of the power system, as each component operates under unique voltage and current requirements. To meet these requirements, a robust power management and distribution system was designed and constructed. We initially envisioned a power distribution system from a set power budget; however, this budget had to be updated throughout the project as new components were added. Power distribution was first designed within DOGHOUSE, from receiving power from the solar panel through the DOGHOUSE electronics, and then finally outputted via the wireless charging system to SCOUT Lite. The first obstacle in development was designing the proper method to deploy and distribute power from the solar panels to the primary battery system. The team eventually decided to use a solar charging controller and buck boost voltage converter to distribute and regulate power.

As the project continued, more parts were added to DOGHOUSE. The first major addition was a rotation state motor on the solar panel: when the motor assembly was added, a separate Arduino was included to delegate data and power for a more modular and controlled power distribution setup. When the needs for IR increased to include both high-power and low-power transmission, PCB systems were designed for both.

On the SCOUT Lite end, power distribution has developed from being a simple setup of discrete components without power regulation and distribution management to a comprehensive system of various voltage regulators and a battery management system to monitor and control the electronics components. The power management and distribution systems also ensure load balancing, in order to provide maximum electrical efficiency and throughput across our systems.

2.2.4 - Power Transmission

Power transmission became the cornerstone in our electrical development throughout the challenge. As our system was split into two systems, DOGHOUSE and SCOUT, the issue of charging SCOUT presented itself. A key problem was the regolith present on the moon. Conventional charging through electrical ports is vulnerable to clogging, and small inaccuracies in positioning could also lead to failed electrical contacts. To address these issues, we decided on wireless charging as the mechanism to provide reliable power transmission from DOGHOUSE to SCOUT. Since the system can be entirely isolated inside of DOGHOUSE and SCOUT, it cannot be affected by dust or regolith clogging. The lack of direct electrical connections also means slight positional inaccuracies will result only in loss of efficiency instead of a potentially mission ending failure. 2.2.5 - Power Generation

The final portion of the electrical system is power generation with solar panels. We developed a power budget for the system to see how much energy was required for the solar panels to generate. We itemized our electrical components and calculated how much power was required for them to operate. This included continuous operation, such as the navigation and sensing applications, as well as one-time-use operations, such as the solar panel deployment mechanism. After this power budget was calculated, we determined what size our solar panel should be. This provided the required panel input wattage required for the DOGHOUSE and SCOUT Lite system to function. Panels were not utilized in our final system due to the fact that we designed around proprietary panels from NASA, but these panels may be implemented in the future. Thus, in order to provide power, we use an external power supply connected to the DOGHOUSE electrical system in order to provide sustained power to the electronics. Throughout the progression of the competition, the power budget was updated, and thus our input power supply was also updated. This was due to the addition of electrical components - including two infrared printed circuit boards, solenoids, and voltage regulators - as well as well as the battery management system. Power was stored in batteries in both DOGHOUSE and SCOUT Lite, accompanied with battery management systems as well as voltage regulators, to distribute the generated power in a safe manner. Using batteries of differing compositions, we ideated various configuration patterns in order to maximize space, as well as increase our ratio of energy to mass. We researched and designed our battery system with both lead-acid and lithium-ion batteries, but chose lithium-ion as it was cheaper, safer, and stored more energy than the comparable lead-acid battery configuration. Progressing through various in-house custom battery systems enabled greater flexibility in producing the required power as well as providing a better lighter form factor than off-the-shelf components.

2.2.6 - Solar Panel Deployment To fit DOGHOUSE under SCOUT, it was necessary to compactly stow the system’s

solar panels. The design needed to ensure that DOGHOUSE maintained a low center of gravity and keep the panels and mechanisms protected from regolith, vibrations, and other sources of damage.

The team primarily considered rolling or unfolding systems to deploy the panels. We also considered a number of mechanisms, such as motors, electro-active shape-memory composite (ESMP) filaments, and springs. In the end, we decided on unfolding solar panels that were deployed via a driven flexible gear rack mechanism. The unfolding system maintained simplicity and allowed the solar panels to face each other without touching in order to protect them from abrasion. The flexible gear rack mechanism was based upon the way a car antenna is deployed. Similar to a car antenna, we also had to achieve a large final height while minimizing the size of the stored system. The car power antenna mechanism, as it is called, consists of a motor that drives a larger gear, which meshes with a flexible gear rack. As the motor turns the large gear, the flexible gear rack is driven out of the housing, where it pushes and extends the telescoping rods of the antenna. The gear rack is long because it has to push the antenna all the way to its final height. However, because it is flexible, it is able to be coiled inside of a cylindrical housing, greatly minimizing the space it takes up. We sought to emulate this system for our solar panel deployment mechanism. Our second improvement was recognizing that the solar panels only need to unfold and extend once, unlike a car antenna. Because of this, we felt that a motor-driven system was unnecessarily complicated, requiring a more complex gearbox and housing. Therefore, we replaced the motor with a set of power springs, also called clock springs. These springs are a type of spiral torsion springs, made of a strip of spring-tempered metal wound around an arbor and held in a circular case. They can store rotational energy by being wound around the arbor. We can then use this energy to drive a gear just as a motor does. The springs both reduce complexity and use less energy than a motor.

2.2.7 - Mobility

PSR mobility systems must be prepared for any environment and wheels are not able to adapt to different ground conditions. In contrast to wheel drive vehicles, legged systems offer a greater range of mobility and are able to actively adjust their center of gravity to regulate stability. Additionally, their feet can be customized, and the legs can avoid undesirable footholds to prevent sinkage. These factors were kept in mind when designing SCOUT’s quadrupedal mobility system.

SCOUT’s leg design is based on the Husky Carbon prototype, developed by our advisor, Professor Ramezani. Husky Carbon is a carbon fiber mobility system that has four legs. Each leg has motorized hip and knee joints, as well as a sliding joint, allowing for motion with three degrees of freedom (see Figure 2). The hip joint consists of two brushless DC motors. The first motor is mounted to an outside face of SCOUT’s box-shaped body so that it is flush with the backside of the motor's casing. The second motor is mounted to the first via a connector so that their faces are perpendicular (See Figure 1). This configuration allows the first hip motor to rotate the entire leg up so that it is horizontal with the body. The knee joint consists of a brushless DC motor mounted in parallel and connected to the second hip motor. The connection consists of a carbon fiber tube. This knee joint motorizes two parallel carbon fiber tubes that connect to a sliding joint at the base of the lowest leg segment of SCOUT’s leg. Based on preliminary simulation testing, SCOUT is capable of carrying the maximum mass allowed for the system (15kg).

However, due to the pandemic, major scope changes were made to the system. In May the goal was to take a pre-built legged system and raise its TRL levels significantly. Plans were made to develop a heating and thermal regulation system, add insulation, dustproof the leg joints, and test out a variety of foot designs in regolith simulant. After receiving more information on the status of the Northeastern campus, restrictions placed on lab spaces, and the whereabouts of team members, it was decided in July that only a single leg (similar to Figure 1) would be developed. The goal was to make some progress on leg development with the limited resources, lab space, and manpower available around the Boston area. At the same time, a backup plan was drafted. It consisted of a small, wheeled mobility system for the purpose of testing the sensing, communication, and wireless charging systems. This wheeled system, dubbed SCOUT Lite, ended up being built and all leg development was halted when it was apparent that the pandemic situation would not improve. SCOUT Lite utilizes SCOUT’s electrical box and contains the majority of its electronics.

2.3 - Final System 2.3.1 - Communications

The final system designed for communication consists of two separate parts: a unidirectional high-bandwidth IR system designed for the transmission of scan data from SCOUT to DOGHOUSE, and a bidirectional low-bandwidth IR system designed for inter-device communication. These systems are run independently by separate microcontrollers and are coordinated through software onboard the primary computer of each device. Both of these

systems use the hardware from the LiDAR scanner for aiming purposes, allowing SCOUT to have a more focused IR emitter, reducing power draw.

Although the increased power consumption of the high-bandwidth IR system is an issue as it counters the expected power savings from using IR instead of radio, we find it to be a good tradeoff due to the decrease in transmission time needed. The increased resilience provided by the two independent systems helps offset the unreliability of using IR in an experimental way like ours and helps balance the power consumption issues with the high power system.

On the component level, the system is composed of a high sensitivity IR photodiode (~810nm) paired with a transimpedance amplifier and analog to digital bit level converter at the receiving side, and a 12W IR LED controlled by the output of a microcontroller. The receiver side goes into a transimpedance amplifier, with an LT1128 op-amp. This op-amp was selected due to its low noise and relatively high slew rate. The gain of the transimpedance amplifier is set to 35MV/V (this can be adjusted to suit the environment sensitivity). We used Schotecky diodes across the negative gain loop to prevent overshooting, and a small voltage input of 100mV voltage divider at the op-amp positive input side to prevent undershooting, both of which prevent dropping the slew rate of the amplifier. A bandwidth filter is situated at the output of the amplifier to further reduce the input noise. The filtered signal is then passed to a comparator, which translates the electrical pulses to logic level signals.

We also designed a PCB for the receiver side since the preliminary result from the breadboard did not allow signals past 100Mhz to be received, likely due to parasitic capacitances. Low-power receiver PCB Schematic

2.3.2 - Navigation

We designed two LiDAR scanners for this project due to issues acquiring parts, with one scanner still in development. The first finished system fulfilled our goal of creating a cheap and lightweight 3D scanning system and can obtain 400,000 data points per minute.

The mechanical design of the scanner can be split into two sections, the lower and upper rotation stage. The lower rotation stage consists of the

microcontroller, quadrature encoder, and the DC motor, the RP360-ST, with its transmission for LiDAR’s continuous rotation around the vertical axis. Due to the relatively low rotational speed of around 120 RPM, we were able to use a geared system which also increases the longevity of the transmission compared to a timing belt. No backlash was incorporated into the design to maintain measurement accuracy. This is achieved through the slight flexibility of the PLA material we’ve used for manufacturing.

The upper rotation stage consists of the LiDAR scanner and 28BYJ-48 stepper motor. The stepper motor was modified into operating bipolar mode to provide 700g/cm of torque, more than enough to rotate the LiDAR unit. To be able to home the stepper motor position, as the stepper motor has no absolute positional feedback signal, the design also incorporates a small optical interrupter module consisting of an IR led and IR photodiode/transistor. The final weight of the entire unit is around 387 grams, which should be light enough to be mounted on a conventional rover unit.

All electrical components operate under regulated power sources (+5V USB source) and consume within the current limit of USB3 standard at 900 mA, as shown in the wiring diagram below. All components are off the shelf, so no PCB was designed.

To effectively reduce the transfer overhead from the microcontroller to the host system, two methods are used. The first was by rounding all XYZ values to the nearest centimeter, as the LiDAR unit itself was only able to provide centimeter resolution. The second was by packing the XYZ value into a more compact string format, allowing a reduction of total bytes sent during each measurement cycle from 18 bytes to 12 bytes.

The second scanner is implemented using an MG995 servo motor for vertical rotation and an ST4209X1004-A stepper motor controlled by a CL4-E-2-12 motor controller. It uses a simple spur gear system to increase the longevity of the structure for horizontal rotation. The system’s other components were 3D printed using PLA. The software is run on an Arduino chip and uses CAN communication to interface with the scanner.

Once LiDAR scans are taken in, they are mapped using the hector_mapping library for ROS systems. This is a SLAM (Simultaneous Localization and Mapping) approach to mapping that creates a 2-D map, which is converted to an occupancy grid for pathfinding.

Pathfinding is done using the Optimized D* lite pathfinding algorithm [1][2]. Using an occupancy grid that dictates where it is possible for the robot to travel, D* lite calculates a path from the goal location to the start location and updates it as new obstacles are detected. This is an indispensable advantage for pathfinding, given that terrains will change in the shifting soil of PSRs. While our system currently stops, scans, and then pathfinds, by implementing D* lite, we allow the system to do simultaneous pathfinding in the future as well. A test environment was developed to perform runtime testing and produce visualizations of the pathfinding (further discussed in section 3.2). 2.3.3 - Power Distribution

SCOUT Lite and DOGHOUSE power block-diagrams, outlining the distributed power

In order to power the various components onboard SCOUT Lite and DOGHOUSE, we use voltage converters capable of stepping down the voltage from the battery to that capable of properly powering the electronics that have lower voltage ratings. For SCOUT, this is the Manifold 2-C and the motor shield. For DOGHOUSE, this is the motor controller and Raspberry Pi. In order to maintain the wireless charger’s receiver output at a constant voltage output, a buck-boost converter had to be implemented to prevent a reverse current from SCOUT’s battery pack, since the output voltage level of the wireless charger can vary substantially depending on the distance between the charging and receiving coils. This came at a cost to efficiency, as the LTC3780 is nominally 89% efficient. The system also utilizes switches capable of stopping and starting power transmission on both SCOUT and DOGHOUSE. When charging, SCOUT’s switch--connected to the battery--will be off.

2.3.4 - Power Transmission

Wireless charging allows for a non-contact method of power transmission which is much easier to maintain and has significantly fewer points of failure. We chose the 200W module from Infineon due to its extensive documentation and support, including a clear layout

plan to upgrade the power output up to 1kW should that become necessary. The module was tested at an actual output of 154W.

The receiver output of the wireless charger requires a voltage regulator to maintain the voltage output if optimal contact between the charging coils is not reached. The output of the wireless charging system can vary from 10V to 28.6V. We set the final voltage output of the regulator to 22V due to the cell configuration of the battery.

In order to facilitate proper alignment of the charging coils, DOGHOUSE is designed with a conical indent with the transmitting coil at the bottom. There is a matching extrusion on SCOUT with the receiving coil. This allows the coil to match up easily as Scout positions itself on top during charging.

2.3.5 - Power Generation

In the finished system, 16 solar panels covering 0.5 m2 will be mounted on DOGHOUSE to generate the 200W of power needed to charge the DOGHOUSE battery.. The solar panels will be mounted on a protective fabric capable of filtering particles as small as 1 μm to ensure their safety during transport and deployment. The filter fabric and solar panel layer will be stretched on an accordion-style frame which will be unfolded during the deployment of the panels. This will allow more efficient use of storage space for the panels and, thus, the ability to hold more panels in total. The frame components will be connected with flexible joints. In addition, the frame will prevent the solar panel layers from touching during storage. For prototyping purposes, half of the frames were made and connected using metal hinges to demonstrate the intent.

The solar panel deployment design was created based on data from NASA’s Glenn Research Center multi-junction solar cell with a Selenium Interlayer [5]. Using the solar panel’s minimum 37% efficiency, and an incident radiation flux of 1320 W/m2, we calculated that the solar panels to generate 200W of power with a 0.5m2 area. Our design is based on a cell thickness of 150μm, a total height of 1.8 meters, and a solar panel mass per area of 85mg/cm2.

2.3.6 - Solar Panel Deployment To unfold the solar panels in the final system, a central mast was designed based on the

deployment method of a car power antenna. To have a system optimized for minimum mass and mechanical reliability, we selected a single mast constructed from nine telescoping carbon fiber rods, ranging from 15cm to 19cm in length. These rods are lifted to a total height of 1.5m by an unspooling flexible gear rack and powered by three 50 Ncm torque springs. Opting for springs in the mechanism rather than a motor is ideal since the deployment only needs to happen once. The springs are coiled prior to the mission launch and store the mechanical energy during mission flight. A single solenoid will be used to release the springs from their coiled position. When released, the uncoiling springs drive a gear inside the cylindrical casing to rotate, pushing the flexible gear rack up and forcing the telescoping rods to expand to their full height. With these three springs, the lifting mechanism is capable of lifting with a force of 38N. On Earth, this provides a factor of safety of 2.5 for lifting the solar panel mechanism.

Springs within the rod connections themselves release pins as the rods expand which hold them at their full height once deployment has completed. Unfortunately, due to problems with the 3D printer used to make the pin connections, these pins were not successfully made.

Deployed Solar Panel System

2.3.7 - Mobility

The final mobility system that was built, SCOUT Lite, was developed for the purpose of integrating and testing SCOUT’s sensing, communication, and wireless charging capabilities without the greater scope of legs. It consists of four brushed DC motors mounted on SCOUT’s original electrical box, which shows that the system’s electronics are capable of fitting in their allocated space. The motors are connected to omnidirectional wheels for easy multidirectional movement and rotation similar to that of a legged system.

3 - Proof of Concept Testing 3.1 - LiDAR

The LiDAR module, once fully operational, takes around 6 minutes and 30 seconds to complete a scan consisting of around 5 million points on average with the packed data format and around 4 million points on average with ASCII BCD data format. The final output data count also depends on the number of invalid data received based on the electrical noise of the environment. Below are a few samples of the scan result we were able to achieve. The point cloud data is visualized in Meshlab.

The geometries of the scans are for the most part clearly defined and thus the measurements and the proceeding calculations are taken quite accurately. The depth map provides more direct visualization of the scanning result. However, from the scans taken outside the MFA, one can observe the smearing effect. This is due to the latency between the measurement taken and the assumed angular position of the lidar. A higher resolution encoder can also help with object details at measure objects further away.

3.2 - Pathfinding

Testing the pathfinding algorithm was done on a simulation of an occupancy grid like one that our robot would use. Obstacles are represented by a binary value of whether or not a particular grid is occupied. We designated a start node (marked in green) and an end node (marked in pink). The path planning algorithm implemented (D* Lite) then generates the shortest path between these two points avoiding the obstacles. The figures to the right feature a 50 x 50 occupancy grid. The second figure shows the path found by the algorithm. The algorithm took 2ms to compute the shortest path in a 50 x 50 grid. We did additional testing on a variety of different sizes to illustrate the difference in time taken with larger scans. The time it

took to pathfind also depended on the percentage of obstacles generated. The times to the right are for occupancy grids where each square had a 1/50 chance of being an obstacle. The figures to the right, however, used a ⅕ chance of being an obstacle for the sake of visualization. We expect to be taking in 2048 x 2048 size occupancy grids after generating LiDAR scans.

One of the advantages of using the D* Lite algorithm is the ability to do re-planning in very little extra time. If the robot encounters unexpected obstacles along the way, it can re-plan its path to the destination. Instead of reordering the entire heap when the robot encounters an unexpected obstacle, D* Lite maintains the information collected in the first search and thus only updates locally, meaning that the time it takes for replanning varies little between sizes of occupancy grids or number of obstacles. Below, there’s a visual of replanning in action. The obstacles that have been added are highlighted in yellow.

Testing was also done on the speed of replanning. We tested these with the same frequency of obstacles in the above tests, 1 / 50 chance of each grid square being occupied.

At worst, the D* Lite planning algorithm took 6 ms to replan. The time taken to replan did increase between grid sizes but didn’t increase directly as a function of the size, but rather the specific problem. This can be seen in the results above when the algorithm planned quicker in a 500 x 500 grid than in a 100 x 100 grid. This is because only local changes had to be made when the robot ran into obstacles. This allowed for highly optimized replanning to occur, always costing only a few milliseconds.

First replan Second replan Side-by-side visualization of path replanning for replanning

3.3 - IR Comms In order to validate the feasibility of IR communications, an initial test system was built

around a very simple platform, consisting of two microcontrollers, one fitted with an IR

transmitter and the other with an IR receiver, both connected to the same computer. A simple modulation script was then used to send streams of bytes from one controller to the other.

While we were able to get a valid signal received consistently on the testing system, the existence of minor per-bit errors was higher than we predicted, especially when targeting the higher-end bandwidth of 2.44kbps for that test system. Although we expected there to be a low maximum bandwidth for this test system, the fast rise of these minor errors meant that any form of interference in the real system would likely cause more retransmissions than expected, leading to a large drop in effective bandwidth. This led to a general system redesign covered in section 4.1.2.

Further testing which was performed on the communications system included a high-volume test of the custom Run Length Encoding algorithm which we implemented for data compression. A sample occupancy grid generated by the mapping team, one of the core pieces of data which it is necessary to transmit from SCOUT to DOGHOUSE and beyond, was found to be approximately 16.8 MB in size. With the expected rate of transmission of 10 kB/s and the overhead from splitting the data into approximately 8200 packets of 2042B each, a single LiDAR scan would have taken around 2021 seconds (about a little over a half-hour) to transmit. With our own implementation of the RLE algorithm, we were able to reduce the size of the grid to 1206 B, a reduction of 99.99 %. With the processing overhead, this leads to just 1456 B (a single packet) that has to be sent over IR, which can be completed in around 0.15 seconds. Our test further indicated that the data could be completely reconstructed without the loss of a single bit. 3.4 - Solar Panel Deployment

Testing for the solar panel deployment system happened in separate parts. There were three components to the deployment system, first the telescoping rods, then the foldable solar panel frames, and lastly, the flexible gear rack driving system which raised the telescoping rods and solar panels to their final height. First, the driving system containing the torque springs and the gear rack was tested and developed. For this process, multiple iterations of gear design, gear rack housing design, and gear racks were tested. The largest challenge to overcome with the system was to ensure that the gear rack unspooled evenly and didn’t cause any tangling within the system. This issue was resolved by including a helical guide to coil the gear rack. Multiple tests were run during development by manually installing the gear rack and coiling the torque springs to 10 rotations (with a maximum allowable of 12). With the system in its final state, a pin was pulled to allow the springs to uncoil and drive the gear rack out of the mechanism.

The final system was tested in the lab several times. However, truly accurate testing of its lifting ability was difficult since the telescoping rods could not lock as they expanded. First, the system was tested without a load or guide to demonstrate that friction within the casing would not inhibit the length that the gear rack could reach. Starting with a 2 m gear rack coiled, after deployment, 1.9 m were released from the casing, which was more than the 1.5 m required to reach the necessary height. Next, we tested whether the system could move the 1.5 kg it needs to raise the panels. 1.5 kg was rested on top of the deployment system and was successfully dislodged when the system was triggered. We also tested the ability to dislodge that same mass at various heights up to 1 m, with a stationary tube guiding the gear rack to the necessary height and the mass to move resting on top of that tube. This worked successfully when the tip of the gear rack was fixed securely to the mass it was lifting to prevent it from folding back on itself. Unfortunately, this process was not recorded on video. That result tells us that, in lunar gravity, the mechanism should have no trouble lifting the necessary mass to 1.5 m. All of this was done with the use of a solenoid to successfully pull the pin that triggers the system.

3.5 - Wireless Charging

The concept of using wireless charging for power transmission between SCOUT and DOGHOUSE remained mostly unchanged throughout the entire span of the development process. Despite numerous setbacks in other areas, relative simplicity and ease of implementation of the wireless charging system made it the first subsystem built in its entirety. The final wireless charging system consists of an Infineon & Würth Elektronik 200W wireless power development kit which includes two 53mm diameter inductive coils, a transmitter board, and a receiver board. The transmitter board and associated coil are installed in DOGHOUSE, while the receiver board and coil are installed in SCOUT Lite. Since the wireless power development kit purchased was essentially plug-and-play, not much had to be done to render it operational for our purposes.

Testing of the wireless charger system measured a continuous current of 4A at an output voltage of 23.5V. This drop is most likely due to the 89% efficiency from the voltage regulator, as well as the inherent limitation of the BMS, which is rated for a continuous 8A at a 10-second configuration. The initial spike of 5.2A is likely due to the BMS’s instantaneous charging limit.

It was also deemed necessary to perform a temperature test to make sure that the unit did not dangerously overheat during peak wireless charging output at 102W. This was done by shorting the output with a power resistor. The components on the wireless charger reached a

constant temperature around the 7-minute mark, with an average temperature of 45.2C. The highest temperature of 52.1C was reached by the capacitors on the transmitter board.

Wireless charging was initially chosen as the method of power transmission between SCOUT and DOGHOUSE due to its reliability when dealing with the difficulties of lunar regolith. Repeatability and reliability are important in an autonomous lunar mission, and all tests have shown that this implementation of wireless charging is both repeatable and reliable under the circumstances tested. 3.6 - Battery

Our initial battery design for SCOUT was based on the desired mobility capabilities of a legged system. The target travel range combined with the estimated speed of the robot gave us a minimum runtime of three hours between charges. The battery also required a minimum continuous output of 143W based on the old design. Since SCOUT Lite is not a legged robot, none of the previous design constraints technically apply, but we were able to construct SCOUT’s electrical box mostly as it was intended for the final system. The characteristics of the original battery were preserved for this reason.

SCOUT’s battery itself consists of 48 individual LG INR18650 MJ1 3500mAh cells arranged in six parallel sets, each of eight cells in series. These cells were chosen due to the high energy density of the final battery, coming in at 259.6Wh/kg, or 240Wh/kg with added cell construction weight. LG cells also offer a total lifetime of 400 charging cycles. This is crucial as greater charging cycles allow less unexpected failure due to premature cell aging. The cell also offers excellent safety specifications, withstanding vibration, drops, and other testing conditions. DOGHOUSE uses the same cells as SCOUT Lite, but given its lower power consumption over time, and based on a 6 hour run time (or a total of 162Wh), the battery is much smaller, at two parallel sets, each of 8 cells in series for a total of 16 cells. Both battery packs were spot welded to minimize thermal stresses on the cells (as compared to soldering).

The battery pack is a big component of power for both SCOUT Lite and DOGHOUSE so it was important for us to begin laying out the different testing methods, constraints, and other design and safety factors needed before going into our final design. There were a few safety features that the battery pack needed in its final design which are overcharging, over-discharging, and fusing in the event of individual cell failure. A BMS with a maximum output of 20A and charging/discharging protection is used to prevent overcharging and over-discharging, and each cell is individually fused with fuse wires to prevent catastrophic accumulator failure in the event of individual cell failure. The fuses were tested and broke at around 24A within 12Msec, which is above our safety regulation as the cells shouldn’t overheat when a short occurs.

3.7 - Simulation of Electrical Systems The main purpose for creating a simulation for SCOUT Lite and DOGHOUSE is to

virtually recreate interactions and communications between each electrical subsystem depending on which respected environment they are in. Initially, we used electrical block diagrams, datasheets, and schematics to help determine the information needed for building our simulation process in MATLAB platforms Simulink and Simscape. The information gathered from these references was useful for finding the inputs/outputs of each subsystem, individual component values, and the pinout information for our main computer. Seven subsystems were focused on in this simulation which are Battery and Power Management, IR Communication, DOGHOUSE Solar Panel deployment, SCOUT Lite mobility, LiDAR scanning, and Wireless Charging. The IR communications subsystem has two levels which are High Power and Low Power. The High Power transmits data from SCOUT Lite to DOGHOUSE and communicates with all of the scans coming from LiDAR while the Low Power IR controls signals that both SCOUT Lite and DOGHOUSE are transferring and receiving from each other while SCOUT Lite is either in motion or stationary. For more information about simulation designs for Simulink/Simscape, please refer to Appendix C. 4 - Roadblocks 4.1 - Technical Challenges 4.1.1 - Pathfinding

While many of the abstract concepts of mapping and pathfinding translate across different systems, some of the finer details are highly dependent on knowing what vehicle we are developing for. Generating a map based on LiDAR information is dependent on knowing the dimensions, pitch, and yaw of the vehicle taking the scan, and determining what terrain is passable is dependent on the mobility system. Since the details of the rover were in flux during scope changes, the team decided to instead develop a generic mapping system. To test pathfinding, we added an implementation of a D* Lite path planning algorithm to a grid-based maze solver program that one of our engineers had built. This allowed us to generate obstacles, plan, and re-plan as we would have in the initial design.

4.1.2 - Communications

An initial issue that communications faced was the error rate of data transmission at higher data transfer rates. To address this, we created a software error correction system with a 25% size overhead, allowing the higher ends of the bandwidth range to be reached while still maintaining signal integrity. This was determined to be the better solution bandwidth-wise, rather than relying on checksums and re-transmission of bad data.

To further solve this issue, the IR transmitter was split into two separate systems: A boosted 5W transmitter designed for transmitting at our target data rate of 100kbps, and a lower power 0.5W transmitter for low bandwidth. This allows us to split data transmission based on type, giving bulk LiDAR scan data to the 5W transmitter while keeping small signaling and inter-robot communication on the lower power 0.5W system. In addition, the known reliability of the lower power system would ensure that a data path is kept between SCOUT and DOGHOUSE if the more complex high power receiver on DOGHOUSE were to fail.

An additional problem that the communication team faced was data size. In order to rectify this, we looked into methods of compressing the transmitted data. Upon examination of the data that would be transmitted, we found that it contained large swaths of identical points, which made it ideal for Run Length Encoding, a lossless form of compression by which strings of identical data, or ‘runs’, are compressed into short sequences denoting their length and value. We implemented a custom version of this algorithm and achieved great success in lowering data size.

A final challenge that was resolved at the high-level software end of communications was the maximum packet size. Initially, one packet was composed of 32,768 B (32 kB) of data. However, due to the higher workload imposed by resending a large packet and the greater risk of said packet corrupting during transmission, it was determined that it would be more efficient to send larger batches of smaller packets. As such, communications packets were reduced to 2 kB in max body length.

4.1.3 - Solar Panel Space One of the major technical challenges in the development of the solar panel deployment system was fitting the required area of solar panels into the amount of room available when DOGHOUSE was stowed. Given the efficiency of NASA’s solar panels the power requirements of DOGHOUSE, 0.5m2 of solar panel area was determined to be needed to supply power to DOGHOUSE. This amount of solar panel area was deployed in a space of less than 20cm2. This was accomplished using a folding design for the deployment mechanism.

4.2 - Scope Changes

The initial plan for this system was significantly different from the current state of the system. The largest scope change we encountered was made in July of this year when our SCOUT system was modified to become SCOUT lite. The largest difference between these systems is the quadrupedal legged system originally present on SCOUT. Our team estimated that the legged system would take roughly two months to build, and another three months to perform debugging and verification. Delays in return to campus led the team to decide that legs were no longer feasible within the time frame, so both the regolith testing bed and the legged system were removed from development, as described in the plan within the mid-project report.

In June, the team developed a build plan to complete SCOUT lite, the demonstration system, and DOGHOUSE, from the start of September until the submission deadline at the end of November. This relied on lab access being gained on return, because the team made the determination that DOGHOUSE would require a full build time of 2 months, with a third month for verification and testing. Though this is not what would have been ideal, the team determined that an intense cycle would still lead to a successful version of DOGHOUSE, even if the deployment vehicle for it would not be complete. That, combined with SCOUT Lite, would be able to demonstrate all but two mechanisms for completion; the quadrupedal system and the mechanism to deploy DOGHOUSE from SCOUT. The summer was spent planning and creating CAD for different systems, as well as component level verification of individual subsystems, to ensure as smooth of an integration process as possible. This included PCB verification, battery testing, and designing the coding framework.

During the delays for our return to campus, the mechanical design of DOGHOUSE went through many iterations because of supply chain issues due to COVID as well as design improvements to what we had planned previously. The deployment of the solar panels, particularly, went through many iterations. Over the course of the project, we considered using solar panels designed for CubeSats, solar panels that were deployed using Electroactive Shape Memory Polymers (ESMPs), and spring deployment methods before eventually choosing our current design.

Upon the return to campus, the team quickly realized that the workspace we expected to gain access to would not in fact be available, as safety protocols slowed the reopening process. Progress, albeit slower than expected, was able to continue simply by having all of the project components in one city, even though there was still no shared workspace. Not having to ship parts cross country was certainly a boon to this progress. At the end of September, it was clear that this delay in workspace access had shifted to require a major descoping of the project. With only two months, the team did not feel confident in their ability to integrate and verify the electrical system, solar panel deployment, LiDAR scanner, and demonstration vehicle. After contact with the NIA and NASA representatives, the team decided to focus on proving individual systems and integrating as much as possible as progress was completed on each subsystem. The main targeted subsystems were: LiDAR and pathfinding, IR communication, solar panel deployment, wireless charging, and electrical layout verification. If solar panel deployment was successful, it was determined that a partial build of DOGHOUSE, without electrical verification, would be possible. It was also decided that SCOUT Lite would still be within reach if electrical verification was complete.

4.3 - COVID Remarks 4.3.1 - Location Logistics

It’d be a disservice not to explain the specific changes to the system that occurred simply because of the obstacles created by COVID-19. Like most companies and organizations, the start of the outbreak was mired with indecision on what the long term effects would be on the team. Our team was removed from campus in mid-March, losing our lab access until it was deemed safe for return. We began to develop backup plans for various timelines on return to campus since our original plan had been to work both through the spring and summer. With members scattered across thirteen states, work over the break was limited to one person in whatever workspace they could find (usually their bedrooms or garage). Because we are a student group without a lab space that was solely ours, we were not able to remove any of the materials needed to do significant testing and development. We were also hesitant to spend funds on infrastructure because, for most of the summer, we were advised by our university that we may be able to return at different points. Relying on this was a mistake on our part, we should have planned for the now-real worst-case and focused more on creating at-home workspaces for our team.

4.3.2 - Red Tape

The notion of always being close to return was based on a lack of guarantees from the university on what reopening meant for student groups. Northeastern had, and still does have, extensive procedures in place to keep students safe. Only critical lab research was allowed into the university, while student groups were approved on a case by case basis. A return to operation form was provided to us in August, but due to the highly volatile situation, the actual delivery deadlines for the university kept getting pushed back. Due to this uncertain timeline, it took until October 8th to get in contact with someone who could quickly get us access, and we were in the workspace on October 21st, 39 days before the deadline. The additional procedures required because of COVID at the university and decisions made at higher levels trickled down to particularly damage us as an edge case. This was driven mainly by our deadline being in the fall, in contrast to most student groups that have deadlines in the spring. This created a unique case where on our end, each day was taken out of crunch time, so we were the only team pushing to urgently get space, making it hard to apply the necessary pressure to drive action.

5 - Results

Throughout the design and building process, some things have indeed changed from our original ideations. However, the system and its individual components were still able to solve the primary intended problem sets.

Mechanically, we were able to design a rover, SCOUT, and its charging and communication station, DOGHOUSE. SCOUT, whether with legs as originally designed or with wheels as in our SCOUT Lite version, will be able to make sorties into the PSRs in order to

obtain data. DOGHOUSE’s deployment mechanism was designed and tested, indicating that, with the path to flight addition of the actual solar panels, DOGHOUSE will be able to obtain solar power to transfer to SCOUT. The deployment mechanism was demonstrated to work effectively, and would be able to successfully lift the necessary mass to the necessary height. 1.5 kg were ejected, in Earth gravity, from a height of 1 m. Unfortunately, the full system was not constructed and tested because the locking mechanism in the joints of the rods was unsuccessful.

While we could not write navigation software for a specific craft, we did create all of the components necessary for our navigational system. We successfully read in LiDAR scans, generated occupancy grids, compressed those scans, passed our data through our communications system, and path found around obstacles. The results of our navigation endeavors indicate that LiDAR and the D* Lite pathfinding algorithms would be an effective solution to navigation in PSRs.

Despite having a rudimentary alignment system and relatively simple commercially-available electronics, the IR system that we devised proved that IR is an efficient way of transmitting information if line-of-sight is guaranteed. We were able to get a bandwidth high enough to transmit bulk data with relatively low power consumption that was also lightweight and adaptable.

6 - Path to Flight

Due to the descoping of the project, three primary elements seen as unique and having especially high technical possibilities were chosen to focus on in terms of future development. These elements have all progressed far enough to have their feasibility tested individually.

Wireless charging’s potential for a large high-power system was proven through the tests in section 3.5. The future developments needed primarily relate to having the charging system work successfully on the much more hostile environment on the moon. The charging coils would need to be hardened and tested with the sharp particles seen in the lunar regolith. In addition, the act of driving up against a charger and getting close enough to initiate a power connection was not tested with our system, and while it would likely not pose too large of a problem, it would help to confirm its feasibility with current positioning systems.

Pathfinding can be successfully applied to navigate around obstacles that can be identified using LiDAR. From this point forward, development should focus on adequate testing and more specialized design. We lacked the ability to develop for a specific vehicle and instead developed generalized pathfinding systems. Once a specific vehicle (SCOUT) could be designed for, writing mapping software that takes into account its specific dimensions is important. Additionally, the environments in which we tested our LiDAR and pathfinding systems were mainly residential areas or academic buildings. Testing in an environment that more closely resembles the kinds of boulders, craters, and other obstacles our vehicle might face is an essential step towards our path to flight.

The path to flight for the infrared communication infrastructure is primarily testing related. Due to time constraints, we chose our transmission wavelength (810 nm) due to the high commercial availability of LEDs and photodiodes at that wavelength. However, we expect that better performance with less interference could be achieved with other wavelengths, ideally those that do not match common emission wavelengths in the PSRs.

Additionally, better hardware and control software would allow a more focused IR emitter through better aiming at the receiver, allowing for lower power consumption at the same distance or longer distances. If perfected, the emitter could be replaced with an infrared laser, greatly decreasing the potential power unusable for transmission.

7 - Timeline This timeline marks the monthly milestones that the project has achieved since our team’s meeting with the NIA and NASA team in the aftermath of the Mid Project report. This is not an exhaustive list, but is meant to illustrate the rate of change, and how access to lab space served to bottleneck the project. June:

● Rescoping based on feedback from the mid-project report ● Wireless charging prototype finished and tested ● First LiDAR prototype finished and tested

July: ● Initial IR communication PCB design and order ● Initial IR PCB verification and soldering

August: ● Run Length Encoding added to IR communications ● Solar panel deployment design completed

September: ● Return to Campus ● Assembly preparations ● Tool acquisition ● SCOUT Lite design completed ● Spring mechanism design started

October: ● Lab Access ● SCOUT Lite fabrication begins remotely ● Start of deployment spring development ● LiDAR software completed ● Final IR reorder ● Pathfinding algorithm started in simulation ● Spring mechanism design completed

November:

● DOGHOUSE fabrication started ● DOGHOUSE fabrication completed ● DOGHOUSE wiring Verification ● Low-bandwidth IR integration ● SCOUT Lite fabrication completed ● SCOUT Lite wiring Verification ● SCOUT Lite first mobility test ● High-bandwidth IR integration ● Spring deployment mechanism completed ● Pathfinding algorithm completed and tested in simulation ● Solar panel deployment build completed

8 - Budget

Below, there is a breakdown by section of expenditure. The Northeastern Team spent a total of $13, 328.73 out of an awarded $90,889. In the appendix of this report, you can find a breakdown by purchase for each expense, sectioned by area. Because our expenditures did not exceed our Phase 1 award value, all of these expenditures come exclusively from the Phase 1 budget. This is due to the significant descoping of the project between the proposal and award determinations. There will need to be discussions between the Northeastern team and both NIA and NASA on what will happen to the remaining funds. Also, on Wednesday, November 25th, the team was informed by our advising professor that Northeastern University collected a 57% indirect cost fee (IDC) from at least the second award and possibly the first award. The source of this decision seems to be that the second award was processed as an MIT subcontract. We believe this to be an error for a multitude of reasons, most importantly because we are a student club, not a research lab. Our project lead was unable to reach the necessary Northeastern staff members that handle these cases due to the holiday but will be in contact as this development unfolds.

Full Spending By Area

Appendix A - Full Spending Reports

Appendix B - By System Budget Breakout

SCOUT Lite

DOGHOUSE

Connections

Shipping

Tools

Appendix C - Full Simulation Diagrams SCOUT Lite Simulation

DOGHOUSE Simulation Diagram

Acknowledgments [1] Beard, Daniel. “DStarLiteJava.” Github, 19 Apr. 2017,

https://github.com/daniel-beard/DStarLiteJava

[2] Github user nopnop2002. “Arduino-STM32-CAN.” https://github.com/nopnop2002/Arduino-STM32-CAN

[3] Github user mersinvald. “reed-solomon-rs” https://github.com/mersinvald/reed-solomon-rs

[4] Koenig, Sven, and Maxim Likhachev. D* Lite. Association for the Advancement of Artificial Intelligence, 2002.

[5] Landis, Geoffrey A. Selenium Interlayer for High-Efficiency Multijunction Solar Cell. 16 Aug. 2016.

[6] Proulx, Viera, et al. “JavaLib.” Northeastern University, 2009, www2.ccs.neu.edu/javalib/.

Additional Acknowledgements Pathfinding testing software was built off of a project originally developed by our

controls lead Julia Abouelheiga in collaboration with Sean Kolczynski; significant changes were made to the infrastructure and code.