Goliath Fall 2016
Final Blog Post
Kristen Oduca (Project Manager)
Diana Nguyen (Missions, Systems, and Test Engineer)
Sou Thao (Electronics and Control Engineer)
Dylan Hong (Design and Manufacturing Engineer)
Table of Contents
Executive Summary
Program Objective
By: Kristen Oduca (Project Manager)
Using the 3Dot board, create an operational toy scale model of the German Goliath 302 Tank. It will autonomously follow a biped robot for the game, “Save the Human”, however if it were to lose track of the biped it will use custom commands and follow the biped in RC mode. [1] The Goliath Tank 3D print time shall be less than six hours, with no single print should be greater than two hours. The design envelope should be the minimum in order to accommodate the custom I2C shield, 3Dot board, motors, and sensors. Cost should be under $150. The project should be completed by December 17, 2016.
Mission Profile
By: Kristen Oduca (Project Manager)
Throughout a course defined in the game play, “Save the Human”, Goliath will follow the Biped at a fixed distance of 20 inches. It will provide a live video feed for the biped in the Arxterra Control Panel through an Android phone using the Arxterra Application [1].
Key Features
By: Kristen Oduca (Project Manager)
Moveable Side Panels
When not in use or RC mode, Goliath side panels are tucked in, but when wanting to use autonomous mode, the side panels can be pulled out. Depending on the size or shape of the object, the sensor doors can also be tilted upwards to get a better reading of the object.
Triangulation Algorithm and SMD LEDs
The control algorithm uses a triangulation method in order to determine the exact location of the Biped. Because we know the exact location, we can see how far away it is and whether it is right in front of us or to the right or left. This allows us to use five SMD LEDs to display the exact location.
Switches from RC to Autonomous Mode
On the Arxterra Application or the Arxterra Control Panel, Goliath has the ability to switch between autonomous and RC mode. This was designed just in case Goliath lost track of the Biped.
Level 1 Requirements
By: Kristen Oduca (Project Manager)
- Based on our program objectives and mission profile we developed Level 1 Requirements.
- L1-1 Goliath shall be completed by Wednesday, December 14, 2016 (According to CSULB final exam schedule )
- L1 – 2 The budget should not exceed $150. (Based on the allocated budget)
- L1 – 3 All parts being 3D printed will be printed under 6 hours with no single print over 2 hours (Based on the Program Objevtive) .
- L1 – 4 The Goliath shall follow the biped at a distance of 20 inches with 15% margin of error. (Based on Sensor FOV [2])
- L1 – 5 The Goliath shall participate in the game for 1 hour. (Based on the game objective [1])
- L1 – 6 Goliath shall be able to switch between autonomous mode and RC mode by custom commands. (Based on the program objective)
- L1 – 7 The 3Dot board should send custom telemetry to the Arxterra Control Panel via Bluetooth. (Based on the program objective)
- L1 – 11 Goliath shall have a custom PCB (Based on the program objective)
- L1 – 10 The Goliath shall be a scale model of the Goliath 302 tank. (Based on the customer objective [1])
- L1 – 12 Goliath will use the 3Dot board. (Based on the program objective)
- L1 – S The Goliath will be capable of traversing the terrain of the game arena. (Based on the game objective [1])
- L2 – 2 Goliath shall be Biped’s vision during the game shall be provided by the camera and periscope on the Goliath (Based on the game objective [1])
- L2 -3 Goliath will not surpass a mass of 2.7688 g. (Based on the mass report.)
System Design
Level 2 Requirements
By: Diana Nguyen (Missions, Systems, and Test Engineer)
- L2 – 1 Goliath should use triangulation to find the location of the Biped. (Based on the game objective [1])
- Once Commands from the Arxterra Control Panel will be sent to the Arxterra Application via wifi, these commands will be sent to the 3Dot board via Bluetooth LE.
- L1 – 8 Goliath shall use five SMD LEDs to indicate the location of the Biped. (Based on the program objective)
- L1 – 9 Goliath should make motor noises during the game that fall between 20 to 65dB. (Based on human hearing)
- The Goliath should have an approximate ratio of 1 : 0.566 : 0.373 (Length: Width: Height). (Based on Goliath 302 tank design [3])
- Goliath shall house the 3Dot Board, sensors, and custom PCB
- The Goliath will have a total of two gears in the front, two driving wheels in the rear side, and fourteen wheels in the center. (Based on Goliath 302 tank design [3])
- L1 – S1 Goliath shall be able to travel on flat surfaces. (Based on the game objective [1])
- L1 – S2 Goliath shall traverse the cardboard and linoleum surfaces of the 12ft and 15ft course. (Based on the game objective [1])
- L1 – S3 To drive the Goliath up the 6 degree incline, the motor shall provide a minimum torque of 0.0249 Nm. (Based on calculations of moving up a ramp)
- L1 – S4 Goliath shall be able to travel on uneven surfaces up to 0.5mm.
![[3]](https://upload.wikimedia.org/wikipedia/commons/8/80/Sdkfz302elektr.jpg){kind=link}
System Block Diagram
By: Diana Nguyen (Missions, Systems, and Test Engineer)
The system block diagram is a quick way to overview the product and how product works and interact with each other.
Updated System Design(Linked to http://arxterra.com/updated-system-design/)
Interface Design Definition
By: Diana Nguyen (Missions, Systems, and Test Engineer)
The purpose of the interface matrix is to keep track of what pins are being used already. Since this is a 3Dot board that we are using it is we will be keeping track of what pins are being used on that. This will make it easier to see what pins are available when coding the project.
Mission Command and Control
By: Diana Nguyen (Missions, Systems, and Test Engineer)
In case if we lost track of Biped, we developed a custom command that allowed us to switch between remote control mode and autonomous mode. We also indicated which mode we were in with the SMD LEDs that are located on the front of Goliath. When in RC mode all the lights would be white and while in autonomous is would indicate the location of Biped.
http://arxterra.com/custom-telemetry/#Telemetry-2
Our code can be downloaded here. https://drive.google.com/open?id=0B4XdpzxPg7pHSXNlVDMwdXplOU0
Experimental Results
Determining Torque Needed
By: Sou Thao (Electronics and Control Engineer)
Because the initial estimated weight of the Goliath model was 329g, we needed to find a motor that would supply enough torque to drive the Goliath. Since we had the previous Spring 2016 Goliath model, we performed a torque to weight ratio test for the tracked vehicle to get an estimated torque needed to drive our new Goliath. Thus, the test showed that our new motors should be able to supply a torque of 9.15oz*in.
Experiment to Determine Torque to Weight Ratio (Linked to http://arxterra.com/experiment-to-determine-torque-to-weight-ratio/)
Motor Trade Off Study
By: Sou Thao (Electronics and Control Engineer)
By making Goliath smaller, we had to use smaller motors. Thus, a motor trade off study was performed to see which smaller motors were powerful enough to provide Goliath with enough torque of 9.15oz*in. From the study, the Pololu Micro Metal Gearbox Motors were the most ideal motors for our application.
Motor Trade Off Study (Linked to http://arxterra.com/motor-trade-off-study-4/)
Sensor Trade Off Study
By: Sou Thao (Electronics and Control Engineer)
Based on Mission profile, in order for Goliath to be autonomous, sensors must be used to track the BiPed. From research, there needs to be at least two sensors in order to track an object. Therefore, a sensor trade off study was performed to determine the best sensor needed for tracking. From the study, the ultrasonic sensors were the most ideal sensors to use because they provide the most accurate readings out of all the sensors compared.
Tracking Sensors Trade Off Study (Linked to http://arxterra.com/tracking-sensors-trade-off-study/)
MaxSonar Sensor Field of View Test
By: Sou Thao (Electronics and Control Engineer)
From the sensors researched, the MaxSonar I2C Sensors were the best sensors in our application of making Goliath autonomous. Thus, two field of view tests were performed to determine the resolution of the sensors and to determine if Goliath was able to track BiPed within a 20 inch range. From the tests performed, it was determined that the sensors provided enough resolution to track BiPed from a distance close to 20 inches.
MaxSonar Sensor Field of View Experiment (Linked to http://arxterra.com/maxsonar-sensor-field-of-view-experiment/)
Updated MaxSonar Sensor Field of View and Resolution Test (Linked to http://arxterra.com/updated-maxsonar-field-of-view-and-resolution-test/)
Control Algorithm Using Triangulation
By: Sou Thao (Electronics and Control Engineer)
In order to effectively track BiPed from a distance of 20 inches, a control algorithm that consisted of using triangulation was created to track BiPed accurately. By maintaining the triangle formed by the two sensors and the tracked object, the control algorithm was able to keep BiPed within its field of view and follow it from the given set distance. The control algorithm consisted of 2 PI Controllers: one for controlling the vertical speed to tell how fast the motors shall go and the second for controlling the horizontal speed to tell which motor should go faster than the other one for turns. Thus, the PI controllers were manually fine tuned until the system was finally able to track BiPed within the 20 inch range.
First Control Algorithm (Linked to http://arxterra.com/control-algorithm/)
Control Algorithm Using Triangulation (Linked to http://arxterra.com/control-algorithm-using-triangulation/)
Controlling RGB LEDs
By: Sou Thao (Electronics and Control Engineer)
In order to fulfill the requirement of having a visual display to show the direction and distance of BiPed, we used 5 RGB LEDs mounted to the front of Goliath. To control the LEDs, we conducted an experiment using the Adafruit PCA9685 PWM Library to see if we were able to show an object’s location. The two leftmost LEDs would turn on if the object was to the left, the three middle LEDs would turn on if the object was in the middle, and the two rightmost LEDs would turn on if the object was to the right. Also, the LEDs would be red if the object was too close to Goliath, it would be green if the object was within range, and it would be blue if the object was out of range. Furthermore, the experiment fully turned on the LEDs and did not changed the intensity of each light as the object moved away. This experiment served as a proof of concept in showing that we were able to display the object’s location. However, it should be noted that the final model did include intensity based on the object’s location. This was achieved using the map function and is shown here in the final algorithm on line 198. (Link “here” to https://github.com/southao94/EE400D-Fall-2016-Goliath/blob/master/NewControlAlgorithm.ino)
Controlling RGB LEDs (Linked to http://arxterra.com/controlling-rgb-leds/)
Playing Tank Noises
By: Sou Thao (Electronics and Control Engineer)
One of the requirements was that Goliath should make tank noises throughout the game. In order to play those tank noises, timer interrupts were used to consistently play the noises as the Goliath roamed around. An experiment was conducted, and it was noted that there were problems when playing the tank noises using Timer 1 and Timer 3 Interrupts. Thus, the tank noise was played in the setup of the code to show that we were able to get the noise to work.
Playing Tank Noises (Linked to http://arxterra.com/playing-tank-noises/)
Rapid Prototype PDR
By: Sou Thao (Electronics and Control Engineer)
For the first rapid prototyping, we tested the Sharp IR sensors versus the HC-SR04 ultrasonic sensors to compare which sensors were better to use for tracking. From the experiment, we determined that the ultrasonic sensors were better because their signals were less prone to distortion. The prototype with the ultrasonic sensor followed our box more smoothly than the IR Sensor, and it tended to track the object longer than the IR sensors. In addition, the lighting from the room seemed to distort the signals from the IR sensors, therefore, the ultrasonic sensors were the best types of sensors to use for our application.
Rapid Prototyping of Ultrasonic and Sharp IR Sensors (Linked to http://arxterra.com/rapid-prototyping-of-ultrasonic-and-sharp-ir-sensors/)
Rapid Prototype CDR
By: Sou Thao (Electronics and Control Engineer)
For the CDR Rapid Prototype, we used the previous Goliath model and integrated the RGB LEDs along with the first control algorithm. We noticed that Goliath was not able to track an object as effectively as it should from 20 inches away, and the code needed to be changed to compensate for errors in creating a triangle. Thus, we had a proof of concept that triangulation would work for our final design, and that we needed to determine a way to get the actual values for the triangle. From this learning experience, we were able to research and find different ways to solve for the triangle using the law of sine and cosine, and we were able to refine our code to in order to track Biped close to 20 inches away.
Manufacturing
Initial Design
By: Dylan Hong (Design and Manufacturing Engineer)
The initial design process consisted of the preliminary design sketch, the calculations of the dimension ratio, implementing the sketch in Solidworks to create a 3D model, and creating scaled model of the 3D model. For the design sketch I completely remodeled it and gathered blueprints on the actual 302 Goliath’s architecture. This made it much simpler to 3D model by designing the Goliath by four major parts, the top panel, bottom panel, and the two side panels. For calculating the ratio I gathered the measurements of the real 302 Goliath and used simple math to determine the L x W x H.
Real 302 Goliath Dimensions:
1.5 0.85 x 056m
Goliath ratio calculations:
Reference ratio factor: 1.5m
L = 1.5m/1.5m = 1
W = 0.85m/1.5m = 0.567
H = 0.56m/1.5m = 0.37
1 x 0.567 x 0.37m
I modeled the chassis dimensions to be 8.55 x 5.06 x 3.21 inches, but soon realized that the customer desired a model that was half that size.
Initial Design (Linked to http://arxterra.com/initial-design/)
3D Printing Filament Tradeoff Study
By: Dylan Hong (Design and Manufacturing Engineer)
3D printing is listed as one of the level 1 requirements (L1-3) and to fulfill this requirement we must distinguish the types of filament and perform a tradeoff study to see which filament would work best for our product. First, I did research on ABS, PLA, and nGEN filament. Throughout the semester, I would conduct an experiment and print prototypes of our model in each material. I concluded that the best material for our product was nGEN because it was well rounded and met the toughness of ABS and the printability of PLA.
PDR Design
By: Dylan Hong (Design and Manufacturing Engineer)
After speaking to the customer about his expectation for the Goliath model, he stated that the Goliath must be “humanly small as possible” and tightly fit the 3Dot Board. This called for a major design change with the chassis dimensions, which led to the change for smaller motors and sensors. Since we based the length of the chassis from the 3Dot board and the width from the newly selected metal gearbox motors (taken from the Segway Bot), we determined the dimensions to be 4.27 x 2.94 x 1.5 inches. Next, we printed our first prototype of the chassis by 3D printing with nGEN material and inspected its build quality. We noticed that there were problems such as the fragility of the top panel, in which we created a static study since we were placing the phone on top. The study showed that the force applied by the phone will cause the top panel to deform inwards, which prompted us to reiterate the design process for CDR.
PDR Design (Linked to http://arxterra.com/post-pdr-redesign/)
CDR Design
By: Dylan Hong (Design and Manufacturing Engineer)
After going through the design process again, we determined the flaws with our PDR design. The top and bottom panels were thin and flimsy, the side panel sported idle wheels instead of rotating wheels and was much too small to fit any type of tracks. Therefore, for the CDR design we decided to increase the overall thickness of each part to secure sturdiness, we changed the idle wheels to rotating wheels to reduce the friction for when the tracks are in motion, and we changed the dimensions again to 4.71 x 3.77 x 1.8 inches. The change in dimensions were increased in length, width, and height to compensate for the newly selected sensors and prefabricated Tamiya tracks. Also, the sensors were a huge problem for us, we had difficulties in determining the placement of the sensors without compromising the size of the Goliath. We spoke with the customer and he suggested making a door on the side panel for the sensors to be mechanically opened or closed. First we implement actual brass hinges to fasten the doors, but the customer was not a fan of it and suggested snap on hinges.
CDR Design (Linked to http://arxterra.com/cdr-redesign/)
Post CDR Design
By: Dylan Hong (Design and Manufacturing Engineer)
With each iteration of the design process, our product was starting to get where we wanted it to be. This time, the design of sensor doors were not functional as a snap on hinge. In our printed version of the CDR design, we actually broke the doors when trying to snap it onto the hinges. This called for a second redesign of the hinges, where I decided to incorporate a steel rod that inserts into the bottom of the side panel and through the sensor doors. The steel rod as hinges were also incorporated to the bottom and top panel.
Post CDR Design (Linked to http://arxterra.com/post-cdr-redesign)
Final Design
By: Dylan Hong (Design and Manufacturing Engineer)
For the final design, the majority of the design changes were small tweaks that would improve the functionality of the tracks, sensors, and appearance of the Goliath. After experimenting with the sensors we realized that the sensors would detect the uneven surfaces and the ramp of the obstacle course. To resolve this problem, I redesigned the sensor doors by extending it to its max length and decided to separate the door into two parts and stuck a steel rod horizontally into the center of each part so that it would function as an up and down hinge. This up and down hinge allows the sensor to be angle upwards to avoid any uneven surfaces on the ground.
Final Design (Linked to http://arxterra.com/final-design/)
Final Product (3D Printing and Polishing)
By: Dylan Hong (Design and Manufacturing Engineer)
After finalizing the design, it was time to produce the final 3D printed product. The final product was printed with white nGEN filament and had a print time of 5 hours and 22 minutes. Since nGEN does not dissolve with acetone, we decided to polish it by sanding, priming, spray painting, and clear gloss coating. With the little time we had, we could not polish the prints as successful as we would have liked. When applying coats of primer, paint, and clear gloss, it is recommended that we wait 24 hours for it fully dry before handling and applying another coat. This led to uneven sets of paint and fingerprints on the surface. For future reference, be sure to start early on the polishing and painting phase to achieve maximum quality.
PCB
Schematic
By: Sou Thao (Electronics and Control Engineer)
In order to fulfill the requirement of having a custom PCB, we designed our PCB with a I2C I/O Expander along with SMD RGB LEDs and a speaker port with volume control. The PCB was tested and it worked perfectly with the control algorithm and the lighting for the distance and direction of BiPed. The speaker was able to play the tank noise and the potentiometer was able to limit the volume. Below is the link to how the schematic was designed and how the PCB was tested once it was manufactured.
PCB Schematic (Linked to http://arxterra.com/pcb-schematic/)
Layout
By: Dylan Hong (Design and Manufacturing Engineer)
The PCB layout was a major component in fulfilling the requirement L1-11, L1-9, and L1-8. The PCB is designed to display the 5 RGB LEDs to detect Biped’s location, play music and adjust its volume, control the left and right sensors, and to connect to the I2C mount on the 3Dot board. The PCB layout was created using EagleCAD, where the dimensions of the board (53.34mm x 16.41mm) was the tailored to fit the front of the top panel. The board is double sided and consist of a ground to ground plane. The top layer of the PCB includes one 100 ohm 805 resistor, one NPN transistor, five SMD RGB 5050 LEDs and a trimpot. The bottom layer includes a PWM LED controller (PCA9685), ten 10 ohm 805 resistors, five 47 ohm 805 resistors, two 2.2k ohm 805 resistors, one 0.1 uF capacitor, one 10 uF capacitor, one servo header, one speaker, two sensor headers, and an I2C header mount.
PCB Layout (Linked to http://arxterra.com/pcb-layout/)
Assembly
By: Dylan Hong (Design and Manufacturing Engineer)
The PCB Assembly was manufactured by Oshpark and included two stencils for the top and bottom layer. The bottom layer consisted of more components so we decided to use the stencil and SMD solder it first. Since the bottom layer was baked and reflowed first, we could not use the stencil for and bake the top layer because it would cause the bottom layer to remelt and potentially ruin the bottom components by falling, or shifting off the solder pads.This meant that we had to hand solder the top components, which worked fine but affected the cleanliness of the board.
PCB Assembly (Linked to http://arxterra.com/pcb-assembly/)
Software
Software Block Diagram
By: Sou Thao (Electronics and Control Engiener)
Software Block Diagram
Running Averaging Filter
By: Sou Thao (Electronics and Control Engiener)
In order to smooth out the signals from the readings of the sensors, an averaging filter was used. We noticed there were jumps in the readings, and this caused the motors to jump in different speeds due to the control algorithm. As a result, we noticed jitters in Goliath’s movements so a running averaging filter was developed. From the filter, we noticed that Goliath was able to transition around the course in a smoother way. Therefore, we were able to incorporate the filter in our final design to smooth out the signals from the sensors.
Creating a Running Averaging Filter (Linkd to http://arxterra.com/creating-a-running-averaging-filter/)
The Control Algorithm
By: Sou Thao (Electronics and Control Engiener)
As previously discussed, a control algorithm was needed to convert the signals from the sensors into speed values to enable Goliath to track BiPed autonomously. Therefore, we came up with a final control algorithm using triangulation to accurately track BiPed from 18 inches away, which was well within the 15% margin of error of 20 inches away.
Control Algorithm Using Triangulation (Linked to http://arxterra.com/control-algorithm-using-triangulation/)
Verification Matrix
By: Diana Nguyen (Missions, Systems, and Test Engineer)
The verification matrix is essential our test plan but it covers the main points of your test. This allows you to quickly skim through what test you have completed and the results of the test.
https://docs.google.com/spreadsheets/d/1nidxLcOYEpPlr_o6vkksaHdT84JXj-LlkuektFs7Hwg/edit?usp=sh
Project Documentation
Resource Report
By: Diana Nguyen (Missions, Systems, and Test Engineer)
The purpose of the resource report is so that we are aware of are budget, not only money wise but also how much current and mass our product is allowed.
https://docs.google.com/spreadsheets/d/1nwtMtcTOUBgLlOb-PYG_VztthjQfg4zfSouVQTwZGZg/edit?usp=sharing
Cost Report
By: Kristen Oduca (Project Manager)
Cost Report
We asked Professor Hill if he wanted to use the four motors we bought and he agreed. These were to be used for future classes. Without the motors, we are $31.99 over budget, which is a little over 30% over the budget. In the beginning of the project, we were informed that 3D printing would be free and we would not have to pay, but one day he charged us $25 for using his filament. We were under the impression that we would not have to pay and would have gone somewhere else if this was the case. Given this information, if we were not charged 3D printing, the total amount would only be $156.99, which is $6.99 over the budget. This is less than 7% over the budget. For our project, we had to have a custom PCB. When creating these cost, we thought the sensors alone would be fine for our PCB. However later on in the project, we found out that they connected straight to the microcontroller. We had to add more to our PCB design, thus increasing the costs.
Schedule
By: Kristen Oduca (Project Manager)
I used Project Libre to create my schedule. Here is the file to download the schedule.
Schedule (Linked to https://drive.google.com/open?id=0B5StdKJ3VISgaWNYamlQSDN1Snc)
Burndown
By: Kristen Oduca (Project Manager)
Burndown (Linked to /wp-content/uploads/2016/12/Burndown-Autosaved-Autosaved.xlsx)
PDR
By: Kristen Oduca (Project Manager)
By: Kristen Oduca (Project Manager)
CDR
By: Kristen Oduca (Project Manager)
What We Learned From This Semester
By: Kristen Oduca (Project Manager)
This class takes a lot of time and effort. You really only have five weeks to actually build the project, since the first few weeks are just research and creativity, It is HIGHLY important to go a little ahead of Professor’s Schedule that he has assigned. Professor Hill has the PM generate a project schedule about week 6. I would suggest creating a more general schedule for yourself before that time in order to get an idea for the amount of work you need to do. The link of the generic schedule can be found here. Also, during the research phase make sure you research anything and everything you can about the project. http://web.csulb.edu/~hill/ee400d/Lectures/Week%2005%20Project%20Plans%20and%20Reports/c_Generic%20Schedule.pdf
One thing that helped us out the most was having a group chat with members actively telling each other what issues we had with our part. In doing so, people were able to change their part in order to adjust it to the issue. Waiting for the next meeting in order to discuss your problem can hurt you because time was wasted. It is also important to make your changes around that issue as soon as possible in order to conduct test to see if the issue was resolved or another issue arises.
Try to manufacture your robot as much as possible. We printed around seven Goliaths this semester, which helped a lot in our final design because we found so many small issues every time we printed a new one. Having a physical model allows you to plan better in how everything is going to fit together. Professor Hill and Lawrence, TA, and the President appreciated our placement of our PCB because it was well thought out and it wasn’t just placed on the robot.
Lastly, constantly going to Professor Hill will help you a lot. For presentations, going to him before your presentation and showing him what you guys have done can help a lot and increase your grade because Professor Hill will tell you what he does not like about your project giving you time to fix it. Whenever any design changes are made, going to Professor Hill about it helps to ensure the customer is getting what he wants. He is also very knowledgeable and friendly and will help you in any way that he can as long as you are trying your hardest doing your part.
Project Video
At the end of the semester, we had to create a video to sum up the engineering method. The following link is the video the Project Manager and MST created.
Resources
EagleCAD Files – Eagle Cad Files
Fritzing Files – https://drive.google.com/open?id=0B2uuXSsK9_mManFMaWVkYnpab0k
Arduino and/or C++ Code – https://github.com/southao94/EE400D-Fall-2016-Goliath
Design and Manufacturing Files (Solidworks, STL, PCB Layout) – https://drive.google.com/open?id=0B61nB_r86SEQYjRPanNvVXhoQWM
Verification & Validation – https://docs.google.com/document/d/1BNZ2lVi7rmK6oV8GnIzRW0eITl-uScW0dAV0iss0veA/edit?usp=sharing
Bill of Materials – Reimbursement 2