Micro Rover Final Project Documentation

By: Rafi Koutoby (Project Manager)

This is the final blog of team Micro Rover for Electrical Engineering 400D taught by Professor Gary Hill in the spring 2015 semester at California State University, Long Beach. Of all the projects being done this semester, we are the only team with the rover project and have high hopes in producing one that satisfies our mission profile. Our team consisted of Rafi Koutoby (Project Manager), Sherman Xa (Mission, Systems, and Testing Engineer), Eagled’Or Am (Electronics and Control Engineer), and Ahmed Abanumai (Manufacturing Engineer).

Overview:

Using Mini RoSco’s documentation as a main point of reference and with Professor Gary Hill’s guidance, our team was able of producing a smaller version of the Robot Scout, which we named, Micro Rover. This rover was set to improve upon the design set by Mini RoSco the prior semester, hence the objectives and requirements were very similar.

Micro Rover (and Mini RoSco) was designed to simulate a United States military personnel crawling under barbed wire. Our budget, which was approved by Professor Hill and Vice President Raul Rodriguez, was not to exceed $220. The project had a deadline of Friday, December 15th 2015. Other requirements included 3D printed chassis, wheels, and tracks, a custom printed circuit board (PCB), a vision system that would allow the rover to avoid any obstacles, control via Arxterra, a single power supply, and the primary requirement, which was that the dimensions of the rover were not to exceed those of a Samsung Galaxy S2 Android phone (which would also serve as our remote control and vision provider) plus one inch on the length and width.

One of the biggest challenges was the chassis. With a look that was inspired by World War II tanks, the rover was to have three wheels on each side with a triangular topology and would be tied together via tracks. Halfway through the semester, the primary requirement was altered so the rover could expand in order to carry other Android devices (possibly even tablets). Hence, our base dimensions were those set at the beginning of the project.

One of the main differences between Mini RoSco and Micro Rover was the vision system. Mini RoSco opted for a pan and tilt system, allowing their mirror to move horizontally and vertically to obtain a better picture. Due to our limited space, we were allowed to use just a panning system. This would only require one servo instead of two.

The PCB designed contained connections to our voltage regulator, H-Bridge motor driver, Arduino Micro, and Bluetooth module. The advantages of using a PCB included reducing the size of the internal electronic components and learning EagleCAD.

We utilized the Arxterra App to connect to the phone via Bluetooth. As a result, to create a connection between the Arxterra App and the Arduino Micro, we must create a Bluetooth connection using the HC-06 Bluetooth module, to connect our Android device with the Arduino Micro. The Arxterra Control Panel will act as our user interface to control the Micro Rover’s movements.

Unfortunately, after completing the PCB layout and connection test, we decided to build and assemble all the parts of the chassis. For our motors, we wanted to mount them directly onto the wall of the chassis. We did this by using an R/C hobbyist glue to attach the motors to the wall of the chassis and the wheels to the shaft of our micro motor. However, due to complications in the 3D printing, one of the openings of the wall of the chassis was printed too big and we attempted to use glue to create a tighter fit. Unfortunately, the glue was too heavy and we ended up stripping off one of our motors. Luckily, with the help of a spare motor from team MicroSegbot, we were able to find a solution to this problem. Next, we moved onto the pan mirror system, which gave us trouble on the viewing system. Unfortunately, for our Samsung Galaxy S2 layout, we could not get a full field of vision on our Arxterra Control panel. We were able to get the mirror to display on half of the available screen of the control panel. This could have been resolved if we had more time with the 3D printed chassis and adjusting the pan system’s height. Overall, this was a good learning experience for all of us as we were able to identify the flaws in our design and hopefully, our mistakes will be taken into consideration for future Rover projects.

The final design of our Micro Rover can be seen through our promotional video on YouTube.

Work Percentage:

Project Overview

Burndown Report:

Project Burndown

Documentation/Blog Posts:

Below are the links to the various blog posts that relate to the mentioned topics.

Project Objectives and Requirements: As per the requirements set by Professor Hill, the objective was to build a rover that would run around a chosen test course with parameters similar to Project Mini RoSco from the semester of Fall 2014.

Micro Rover Objectives and Requirements

Project Budget: With a budget of $220 that was approved by Professor Hill and Vice President Raul Rodriguez, we set out to build the rover. The final and detailed budget is attached.

Micro Rover Budget

System Block Diagram and Interface Definitions: The system block diagram is an overview of the rover design and the interface definitions shows the physical pin connections to our Arduino Micro.

Micro Rover System Block Diagram

Micro Rover Interface Definitions

Resource Reports: The power budget ensures that we are within our power limitations of 850 mAh with an input voltage of 8.4 V.

Micro Rover Power Budget

Project Schedule: The project schedule has been broken down based on the stages of completion.

Micro Rover Schedule

Trade-Off Studies: A number of trade-off studies have been conducted, including choosing a suitable mirror angle, speed requirement, motor drivers, etc.

Mirror Angle Trade-Off Study

Speed Trade-Off Study

Convex Mirror vs. Standard Mirror Trade-Off Study

Servo and Motor Trade-Off Study

Motor Driver Trade-Off Study/Result

3D Printing Filament Trade-Off Study

Verification Testing: Testing on the Bluetooth module, the Arxterra App, the PCB, and other subsystems are detailed in this section.

Arxterra and Code Implementation Test

Bluetooth Module HC-06 Test

Full System/Subsystem Testing

Project Presentations: Attached are the PDFs of the Preliminary Design Review (PDR) and the Critical Design Review (CDR).

Preliminary Design Review

Critical Design Review

Arduino Code: Attached are the Arduino IDE files for running our rover. This was posted on GitHub by our Electronics and Control Engineer, Eagled’Or Am.

Micro Rover GitHub Code

SolidWorks Files: Due to our rover being aesthetically different from Mini RoSco, we drew our design inspiration from World War II tanks. The designs were developed by our Manufacturing Engineer Ahmed Abanumai.

Micro Rover SolidWorks Files

EagleCAD Files: As per the requirement of utilizing a custom PCB, our Electronics and Control Engineer Eagled’Or Am designed the PCB and its layout.

Micro Rover EagleCAD Files

Micro Rover Updated Budget

By: Rafi Koutoby (Project Manager)

As established in an earlier blog, the total budget assigned to project Micro Rover was (and is) $220. This budget was approved by both Vice President Raul Rodriguez and Professor Gary Hill.

Attached below is the table showing the total cost of all parts and/or components purchased and used for the project. The total cost includes taxes as well as shipping and handling. And since this project is to be funded by the electrical engineering department, the appropriate reimbursement forms were submitted and all team members received their share of the spent budget.

Budget Finale

In summary, out of the total budget of $220, we spent $197.81, meaning we have met our budget. It helped that a good number of the required parts were already owned by the team members or they were supplied to us by friends or acquaintances, such as a voltage regulator, female headers, and mounting components/hardware. It should be noted though that the cost of $35.20 for the custom PCB was not just for one board. Each PCB order from the vendor comes with a minimum of three boards.

Micro Rover Final Schedule

By: Rafi Koutoby (Project Manager)

Attached is the final schedule for team Micro Rover.

Capture1

Capture2

Capture3

Capture4

Capture5

Capture6

This is our second change to get our final schedule. The main cause of change was the late delivery of our 3D printed parts – the Manufacturing Division Manager was 2 – 3 weeks late in giving them to us. Not only that, but the parts themselves brittle and easily breakable. We had to consult Professor Gary Hill as to how proceed with only a few weeks remaining till the end of the semester. He suggested we ask Mike Pluma for help as he had some leftover PLA from previous semesters and had offered to print for the class. And thanks to him, we had a newly printed chassis, lock and key mechanism, and plate and clip mechanism.

We are over 90% complete with our project. As of now, what remains is demonstrating the final product to Professor Hill to end this semester.

Micro Rover Final Testing

By: Sherman Xa (Mission, Systems, and Testing Engineer)

As all parts were ready to be assembled, we started to do our final testing on our PCB, before assembling our chassis with it. Using our 7 rechargeable AAA NiMH batteries, we will hook them in series to gain roughly an 8.4 V, 850 mAh power supply. This is due to a shipping complication from our original power supply store. We also connected our two motors to the PCB connections, and pinned in our servo connection. However, after looking at the PCB layout, we realized that the pinning of the servo was wrongly created on the PCB. A servo has a pin connection of signal, power, and ground. However, on the schematic, the pinouts were signal, ground, and power. As a result, we had to switch the wiring on the servo, to allow to us have the correct pinning.

After discovering this layout problem, I decided to check the rest of the connection and start labeling the pins for each connector. As I was checking, I realized the pins of the Bluetooth module connector were also flipped. The pin was in reverse order, so I had to de-solder the pins of the Bluetooth module and invert the pins, so the pins were in the reverse order like the layout of the PCB.

With the correct alterations to conform to the layouts of the PCB, we hooked up the components and the power supply, and paired it with the Android device to start the uplink to use the Arxterra Control Panel. We were able to connect to the Arxterra server after a few tries with the S2 but was always able to connect with the S4. However, to go along with the requirements, we wanted the use the Samsung Galaxy S2 as our selected Android device. When we were able to get a good connection to the server, we tested the motors going forward, backwards and turning left and right, from a low speed to the higher speed. During our testing, we did notice that one of our motors was running at a different speed. When connected to a power supply, we noticed that this was the same situation, which made us conclude that the motor was either faulty or damaged during our initial test of stall current and load. However, after making use of Arxterra, the RPM of each motor was not as severe as we saw with the direct connection to a power supply. As for the servo, before connection to the Arxterra App, there was a current problem, which made the servo vibrate instead of rotate. However, with the Bluetooth connection made, and the Arduino Micro connected to Arxterra, the shaking halted. We believe this to be a current problem, due to another team’s observation and our testings of our servos.

After completing the PCB layout and connection test, we decided to move onto the chassis build and assembling all the parts. For our motors, for instance, we wanted to mount them directly onto the wall of the chassis. We did this by using an R/C hobbyist glue to attach the motors to the wall of the chassis and the wheels to the shaft of our micro motor. However, due to complications in the 3D printing, one of the openings of the wall of the chassis was printed too big and we attempted to use glue to create a tighter fit. Unfortunately, the glue was too heavy and we ended up stripping off one of our motors. Luckily, with the help of a spare motor from MicroSegbot, we were able to find a solution to this problem. Next, we moved onto the pan mirror system, which gave us trouble on the viewing system. Unfortunately, for our Samsung Galaxy S2 layout, we could not get a full field of vision on our Arxterra Control panel. We were able to get the mirror to display on half of the available screen of the control panel. This could have been resolved if we had more time with the 3D printed chassis and adjusting the pan system’s height.

Finally, we were ready to test it on the test course. However, when we got the chassis assembled, we ran into a few problems with the wheels. One major problem that we ran into was the friction caused by the free-spinning wheels of the Micro Rover. We tried to solve the issue by pushing the wheels further out, but that caused the rover to be unbalanced and did not create enough traction to move. We attempted to increase the voltage of the power supply, hoping it would create more torque to push the rover, but that only helped in the short run.

Overall, we were able to perform a handful of the verification tests. But with the requirements dealing with the movements of the rover, we were not very successful. For future reference, to the next Rover team:

1. Use bushing to avoid friction caused by the wheels against the chassis
2. Design the chassis with the angle of the mirror system already figured out
3. Create a wheel that will directly hook onto the wheels – note that the motors you use may have custom mounting equipment by the vendor
4. Make sure components of the 3D printed parts have some room in case of the printing material is overused

Micro Rover Power Budget

By: Sherman Xa (Mission, Systems, and Testing Engineer)

The purpose of this testing is to experiment the power consumption of each of the individual components of the Micro Rover, so the team is able decide on a valuable power supply that will fit the needs and requirements of the mission profile.

Last semester, the Mini RoSco had a total possible run time of 11.85 minutes. Their testing that showed how they came to this run time can be found here.

To find our power consumption and decide on what rating power supply we needed, we took a preliminary power budget report on all the components that we planned to use and what the power draw was for each component. Our preliminary design called for the use of an Arduino Uno, which will consume current to 5 I/O pins, which delivers 40 mA, and a 3.3 V pin, which has a consumption of 50 mA. Next, for our motors, we were to be using two 120:1 Plastic Gearmotor from Pololu, which have a current rating of 70 mA at free run and a stall torque current of 800 mA. For our pan mirror system, we are planning to use a HD-1440A servo, which runs at a rated voltage of 4.8 V at a free-run current draw of 110 mA and a stall torque current of 320 mA. Finally, with the use of Arxterra, we are going with the route of Bluetooth communication. As a result, we were adding an HC-05 Bluetooth module, which has a pairing current draw of 35 mA and a connected current draw of 8 mA, running at a rated voltage of 5 V. After calculating these preliminary current draws, we estimated a maximum current consumption of 2213 mA. The resulting preliminary total run time of 650 mAh, 800 mAh, and 1600 mAh batteries are 17.6 minutes, 21.6 minutes and 43.4 minutes respectively. The results can be seen in the table below.

Power Budget 1

However, after much testing and alternating the design, we determined to switch the Arduino Uno and plastic gearmotor to an Arduino Micro and Pololu micro metal gearmotors due to sizing issues which were discussed in a separate blog post. Also, for future designing, we will be using an SN754410 motor driver, which will supply sufficient current to our motors and a LM7805 voltage regulator to help protect our components.

For measuring our actual amperage draw of all our components, we used California State University, College of Engineering’s power supply and digital meters located in ECS 314 to test and measure all current draws. For our micro metal motors, we supplied a voltage of 8.6 V and measured it at free-run and stall. For our HC-06, we bread-boarded a prototype PCB and measured the Bluetooth module when it is connected and sending commands and when it is trying to connect to our Android device. As for the HD-1440A servo, we measured it at a rated voltage of 5 V and tested it during no load, operating, and at a stall. As for the motor driver and voltage regulator, I tested the components on our prototype PCB at no load to the servo or motor and when both the motor and servo are operating at full capacity. For the motor driver, I measured the current draw from the VS, which is the logic power supply and the VSS, which is the power supply to the motor driver. The resulting data chart can be found below. The resulting current draw, at worst case scenario, maximum current draw is 2301.64 mA, which gave us 16.9 minutes, 20.8 minutes and 41.7 minutes for the 650 mAh, 800 mAh, and 1600 mAh battery respectively. All these data can be found below.

Power Budget 2

As a result of this, we decided on the 800 mAH to give us a maximum duration of 20.8 minutes, which is more than the allotted time we need to complete the mission. As a result, we ordered an 8.4 V, 800 mAh NiMH battery from BatterySpace. However, upon receiving the shipment, we discovered they had shipped us the wrong battery, and did not have enough time to receive the replacement. As a result, we canceled the order, and bought 7 NiMH rechargeable batteries and purchased a 4 and 3 block battery holders, which will give us 8.4 V and 850 mAh, when connected in series, which will give us similar results to what we originally wanted in our design.

Power Budget

References:

1. http://arduino.cc/en/Main/arduinoBoardUno

2. https://www.pololu.com/product/1121/specs

3. https://www.pololu.com/product/1040/specs

4. http://www.seeedstudio.com/wiki/images/4/48/HC-05_datasheet.pdf

5. http://www.batteryspace.com/NiMH-Battery-Pack-8.4V-800mAh-NiMH-HPI-MICRO-1/18-RC-CAR-BATTERIES.aspx

 

Micro Rover Design Manufacturing

By: Ahmed Abanumai (Manufacturing Engineer)

With the project nearly over and only assembly of the parts remaining after their manufacturing, it is time to compare what we designed on paper versus what we actually produced.

When the semester started, our goal was to build a rover that took its inspiration from old World War tanks with three wheels on each side connected with a track. We drew a schematic that we wanted to follow and went from there.

A

After the major design change, I rushed to meet the requirements without compromising the design. I was able to satisfy the requirements of an expandable chassis by adding a key and lock mechanism and a plate and bar mechanism. Later, I added a servo mount to ensure our panning vision system would allow us clear visibility.

B

C

D

With the final demonstration on the horizon, I am confident that our design will satisfy the requirements and be capable of operating as a real Micro Rover.

Micro Rover Final Design and Dimensions

By: Ahmed Abanumai (Manufacturing Engineer)

As a result of the new design, a new issue arose when we needed something to mount the servo for the mirror we were using for our vision system. For that, I designed a mirror base that would allow us to control the mirror via the servo. This would allow us to have some control over the received image. It must be noted that our visions system will only have a panning capability as specified by our requirements (unlike Mini RoSco’s pan and tilt vision system).

Mirror Base Objectives:
1. The base must carry the mirror
2. The mirror angle over the base should be adjusted to give a clear reflection of the outside.
3. Easy to be controlled via the servo.

1

The hole in the middle is where the servo is attached to and allowed to rotate. The angle at which it is tilted is 50° in order to capture an image that can reflect directly into the camera of the Samsung Galaxy S2, allowing us the ability to control the picture we are receiving.

Wheels and Tracks

Our Micro Rover is supposed to be small enough that we can put small motors to run it. We did not want motors that had a high torque. Through our speed trade-off study, we concluded that the bigger the wheels were, the less work was needed to run the rover.

Wheels Requirements:
1. As large as possible (without ruining the integrity of our required base dimensions).
2. Total of six wheels.
3. The wheels’ teeth should have reasonable gaps to maintain the tracks.
4. Easy to assemble.

2

3

With a total of 18 teeth per wheel, our tracks had to be design accordingly. The thickness is 0.45 inches with a nut hole shaped to assemble the wheels and mount them to the motors and/or chassis.

4

5

The track diameter is 5.10 inches with 52 holes designed to hold the teeth of all 6 wheels (3 on each side). The thickness was designed to be less than the wheels with 0.4 inches. I decided to make use of Ecoflex PLA filament to make them. The biggest benefit of Excoflex PLA is that it stretches easily, allowing us to attach the tracks to the wheels without much difficulty.

Micro Rover 3D Printing Filament Trade-Off Study

By: Ahmed Abanumai (Manufacturing Engineer)

When it came to finally producing a physical model of our rover design, there were two types of filaments that could be utilized; ABS and PLA. Below is table showing the advantages and disadvantages of each.

PLA vs. ABS

Eventually, it was decided that PLA should be used for our 3D printing. I discussed with Manufacturing Division Manager Fernando Ayon as to where would be the best place to purchase the PLA. His recommendation was Micro Center in Tustin. The 3D printing would also be done by Fernando as he owned two 3D printers. In addition, Mike Pluma, an associate of Professor Gary Hill has also informed us that he had two 3D printers that he could use to make parts for us and the rest of the class (as long as he was given a minimum of one week’s notice).

Micro Rover PCB Manufacturing and Soldering

By: Eagled’Or Am (Electronics and Control Engineer)

After researching several companies and discussing it with the Electronics and Control Division Manager, Muhammad Farooq, we decided to send our PCB to OSHPark.com for manufacturing. The total cost came out to be $35.20 for a total of three boards. The final dimensions of the board came out to be 2.24” x 3.15” (56.82 mm x 80.01 mm).

 

PCB Final 1Figure 1: Projected PCB Layout viewed from the top

PCB Final 2Figure 2: Projected PCB Layout viewed from the bottom

PCB Final 3Figure 3: PCB with components soldered and mounted

First, the IC mount, female headers for the Arduino Micro and Bluetooth module, 2-port block terminals, male headers for the servo, the capacitors and voltage regulator were soldered onto the board. Next, the Bluetooth module, Arduino Micro, servo, and motor driver were connected at their respective locations. Lastly, the motors and power supply were connected into the block terminals.

We tested for functionality by turning on the power supply and testing if all the components worked as intended. We were able to connect to Arxterra and control the motors. However, the servo was not working which gave us concern that the PCB may have been designed improperly or the voltage regulator was damaged as that would affect the current delivered to the servo. However, after opening up the servo, we found that the issue was just some loose wiring. After re-attaching the servo and reconnecting it to the PCB, the servo began to function correctly. Because of this, we can conclude that the PCB has been designed and manufactured correctly and therefore can be implemented into the Micro Rover. The next step for our project is to place all of the components inside of the rover and run tests to see whether or not the rover will act as intended. Finally, we will make any modifications necessary to complete all of the verification tests to fulfill our customer requirements.

Micro Rover Final PCB Layout

By: Eagled’Or Am (Electronics and Control Engineer)

After completing the final Eagle schematic, the next step is to switch to the board layout in order to design the PCB. Since space within the rover is limited, the size of the PCB had to possess dimensions less than 3.30” x 2.50” x 0.50” (L x W x H). All of the components were determined to be correct when designing the Eagle schematic.

The first step in designing the PCB was making sure that all the components would fit. This was done by first creating the dimensions of the maximum projected size of the PCB and the placing the components inside the area. The next step was figuring out which pins required wider traces due to the need to move higher currents. The wider traces were implemented in areas that were connected to the power supply or voltage regulator and the output pins of the motor driver to the motors. Once these steps were completed, the actual layout of the PCB can begin.

Our plans for the Arduino Micro, Bluetooth module and motor driver were to have them mounted via female headers and an IC mount. This proved to be a concern as this would exceed our desired height. However, by simply relocating the components on different areas of the board, this could be fixed. Once all the components were at our desired locations, a simple routing of the traces was conducted. Below is the top view of the final PCB design.

PCB 1

The final dimensions of the two layer board are 3.15″ x 2.24″. We decided to add a silk screen area for the Bluetooth so we have a sense of whether or not it would fit on the desired location. Also, we thought it would be a good visual to have. As you can see, none of the grounds have traces connected to the ground pins. This is because we created a ground plane which can be viewed by clicking the Ratsnest tab pictured below.

PCB 2

The ground plane exists on both layers – red being the top and blue being the bottom. By utilizing the ground plane, there is no need for traces which would make routing slightly more difficult. A video I found useful in creating the ground plane is listed here.

Once we find a suitable PCB developer, we will send in our design for printing. This process will be posted in a later blog.