3DoT v4.54 ModWheels Implementation

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

ModWheels was given a 3DoT v4.54 board and we have attempted to do testing on this board to begin developing software and custom commands for the robot. When attempting to upload the 3DoT basic example from my computer and interface to the 3DoT v4.54 board through the Arxterra app to move the motors there appeared to be no functionality.

Methodology

After meeting with Chris to troubleshoot the issues I was able to upload code that moves the motors without interfacing through the Arxterra app. I still have not been able to upload software to the 3DoT board that will interface through the Arxterra app to move the motors.

I will now be going through the 3DoT training document section 12 ‐ Arxterra Bluetooth Wireless Communication and running tests following through this document to diagnose the current issues. Once I have determined the leading issue and I am able to interface the 3DoT board through the Arxterra app I will upload an updated blog post explaining the process and the problems solve/encountered.

How To Record & What To Record

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Introduction

To navigate the maze autonomously we will have to store data about the path traveled while in RC mode (direction, row, & column). This data then be used when switching to RC mode to replicate the actions that were taken in RC mode.

Methodology

When navigating the maze in RC mode the robot should store the direction when it detects that it has entered a new room with an intersection and executes a turn. It should store the new direction that the robot is facing after executing the turn. This direction should be stored in a two dimensional array where the intersection number is in one row and the direction traveled for that intersection is stored in the next row. The robot should store the row and column in variables that are constantly being updated to allow for the robot to know where it is at any time. In addition when it completes the maze those variable can be used to verify it truly completed the maze. A subroutine can be executed when the maze was finished and the user exits (or stops) RC mode to store the final row and column value and check that the maze was completed.

Turns should be predefined by each project as a command that executes a right or left turn and then stores the new direction in the two dimensional array. This allows for turns to be executed in a single button push and makes determining when a turn was executed relatively straight forward.

Source Material

Featured Image: https://forums.xilinx.com/t5/Spartan-Family-FPGAs/S6-Multiboot-Golden-Image-Header-Redux/td-p/243836

Fall 2017: ModWheels Print Time

By: Natalie Arevalo (Design & Manufacturing Engineer)

Approved by: Lucas Gutierrez (Project Manager)

Table of Contents

Introduction

As set by the customer, there is a limit on the time allotted for the parts that will be 3D printed for the robots. The rule for 3D printing is that total print time must not exceed six hours, with no single part taking more than two hours to print. To ensure that ModWheels would not violate this print time rule, an estimation of the print time was initially made. This estimation was based on a preliminary test print of one part, provided by another project’s Design & Manufacturing Engineer, to estimate the print time for the total parts.  This front axle took 45 minutes to be printed, which became a gauge to which to make a rough estimate on the total parts. Afterwards, calculated estimation for print time for all parts were made using the Cura software. Once the 3D models were finalized and sent to be printed, a full rundown of labor, time, and cost were provided, which gives ModWheels final print time results.

Print Times

Estimated Print Times

Table 1: Estimated Print Times

Calculated Print Times

Figure 1: Axle Part 1 (Calculated time = 15 minutes; Time per part x 2 parts = 30 minutes total)

Figure 2: Axle Part 2 (Calculated Time = 5 minutes; Time per part x 2 parts = 10 minutes total)

Figure 3: Servo Holder (Calculated Time = 1 hour & 47 minutes)

Figure 4: Proximity Sensor Holder (Calculated Time = 21 minutes)

Final Print Times

Figure 5: Final Print Time

Conclusion

As part of the preliminary print time, it was estimated that the parts for our project would be around four hours. However, the print times for each part were still calculated using the Cura software which yielded a total print time of about two hours and forty-eight minutes. These calculations were made by the program when the printer was set as the Ultimaker 3D Printer, the materials as ABS plastic, and the material fill as second to most fine. Now, when the pieces were actually printed, they were printed on a Prusa 3D printer using PLA plastic. These changes adjusted the time it would take the parts to print. Additionally, time was also added in which the preprocessing and postprocessing of the parts took place. This added more time to the print time of the parts which gave a total of three and a half hours for all the parts to be 3D printed for the ModWheels project.   

 

Source Material

Featured Photo: https://embed-ssl.wistia.com/deliveries/6ab5496ae3a346c9a1a6a4911a59e2fc605008c8.jpg?image_crop_resized=1280×720

ModWheels Mock-up with Motor Specific Testing

By: Matt Shellhammer (Electronics & Control Engineer)

Approved by: Lucas Gutierrez (Project Manager)

 

Table of Contents

Introduction

When working with a 3DoT board we need to know the amount of current and power that all peripheral devices will be drawing. This is something that is very important for mission success and if we do not have enough power to complete the mission we will have to come up with alternate solutions to developing a successful power budget.

Methodology

In this motor specific test I will be testing the current draw of the two GM6 motors for the ModWheels car. The way this test was performed was using an Arduino Uno as a power supply for the two GM6 motors as well as a device for recording the voltage drop across a parallel combination of resistors. To measure the current drawn by the two GM6 motors I used the configuration shown in Figure 1 with two GM6 motors in parallel and then four 15 Ω resistors in parallel to create a small resistance (3.75 Ω) to measure the voltage across. To record the voltage across the resistors an analog pin on the Arduino Uno was used to read the voltage and then print that voltage into the Arduino serial monitor. Once the samples were recorded in the serial monitor I then copied those samples into a MATLAB matrix to plot the results. I ran this test for two cases; the first case was with no load (rear wheels removed) shown in Figure 2, and the second case was the full ModWheels load shown in Figure 3. The second case with the full load was performed with the help of another person to assist holding the breadboard while the car is driving straight.

Figure 1. ModWheels motor current draw test setup

Figure 2. ModWheels motor current draw test setup for no load

 

Figure 3. ModWheels motor current draw test setup for full load

 

Results

Both tests were ran for thirty seconds recording approximately 6500 samples each. The results were plotted in MATLAB shown in Figures 4 & 5. The average current in case one with no load was 182.43 mA and the average current in case two with full load was 190.74 mA.

Figure 4. ModWheels unloaded current draw MATLAB plot

 

Figure 5. ModWheels loaded current draw MATLAB plot

 

Software

To convert the digital input from a quantized value to an analog value the following equation was used:

The reference voltage was 3.3 volts using the AREF external reference voltage pin on the Arduino Uno. The samples were then divided by the parallel resistance to obtain the current drawn by the two GM6 motors and plotted in MATLAB.

Arduino:

////////////////////////////////////////////////////////////////
//  Name     : Motor Test using Arduino Uno                   //
//  Author   : Matt Shellhammer                               //
//  Date     : 28 November, 2017                              //
//  Version  : 1.0                                            //
////////////////////////////////////////////////////////////////

void setup(){
  Serial.begin(9600);
  // Set the PIN Mode
  pinMode(A0, INPUT);
  // Set Analog reference to AREF
  analogReference(EXTERNAL);
  delay(5000);
}

void loop(){
  float V = 3.3*analogRead(A0)/1023;
  Serial.print(V);Serial.print("\t");
}

MATLAB:

%% Motor Test Plots
clear,clc,close all
%%% Resistance: Four 15 Ohms resistors in parallel = 3.75 Ohms (Measured:
%%% 4.7 Ohms)
R = 4.7;
load('motortestdata.mat')
% Unloaded current (recoreded over 30 second interval)
unloaded_I = (unloaded_V./R)*1000; % Result is in mA
AvgUnloaded_I = smooth(unloaded_I, 0.1,'loess')';
avg_unloadedI = mean(unloaded_I);
figure(1)
plot(unloaded_I,'o','MarkerSize',5)
grid on;hold on
plot(AvgUnloaded_I,'r','linewidth',4)
title('ModWheels unloaded current draw')
ylabel('Current (mA)')
xlabel('Sample')
axis([1 6353 0 300])

loaded_I = (loaded_V./R)*1000; % Result is in mA
AvgLoaded_I = smooth(loaded_I, 0.1,'loess')';
avg_loadedI = mean(loaded_I);
figure(2)
plot(loaded_I,'o','MarkerSize',5)
grid on;hold on
plot(AvgLoaded_I,'r','linewidth',4)
title('ModWheels loaded current draw')
ylabel('Current (mA)')
xlabel('Sample')
axis([1 6543 0 300])

References

https://cdn.solarbotics.com/products/photos/a845e1c2e8a762bd5ef059938ba799aa/gm6-front-img_3140.JPG?w=800

ModWheels Servo Test

By: Andrew Yi (Mission, Systems, & Test Engineer)

Approved by: Lucas Gutierrez (Project Manager)

 

Table of Contents

Introduction

Servos are notorious for drawing large amounts of current and needs to be taken into account when using the v5.03 3DoT Board.  The servo pulls its power directly from the battery via the servo headers on the 3DoT Board.  This test will measure the current draw of the servo in different settings:

  1. -45 degrees to +45 degrees constant turning (worst case scenario)
  2. -10 degrees to +10 degrees constant turning (average case scenario)
  3. Idle current

During its navigation within the maze, ModWheels will be performing small adjustments to keep itself within the confines of the maze hallways.  This is the justification for test #2.  This test should pull the most current because of how servos work.  Servos encase a small DC motor that provides high RPM and low torque.  The mini gears allow the servo arm to swing at a lower speed, but provide a higher amount of torque.  

 

Test Setup

A handheld digital multi-meter (DMM) was connected in series with the ground wire to test the current draw during these tests.  These tests give an overview of the current being drawn and allow us to have an idea of the amount of current being drawn.  More in depth tests will follow.

Figure 1: Test Setup


Test Values

The following values are for each test with the DMML:

Test 1:

The servo was programmed to constantly shift from -45 degrees to +45 degrees.  This test is to check that our power isn’t adversely affected if the ModWheels toy car were to find itself in this situation (constant turning).  Wide turns should not pull as much current because of the rate of change being less frequent (compared to test #2).

Figure 2: Test 1

Test 2:

This is the test for the ModWheels’ “worst-case” current draw.  Since ModWheels will spend most of its time within hallways, the servo will be making small adjustments to make sure the parameters (distance from hedges) are met.  Since the servo arm will be going from -10 to +10 degrees at a rapid rate, the highest amount of current draw should be from this scenario.  

Figure 3: Test 2

Test 3:

The idle current is tested to see how much current is drawn when there are no commands being sent to the servo. This test is to ensure that the servo does not have issues during idle mode.  What we don’t want to see are sudden spikes in current draw when the servo isn’t receiving any commands.

Figure 4: Test 3

Conclusion:

Judging from the worst case scenario (Test #2), ModWheels should not have power issues with the servo, as it draws directly from the battery.  The current draw from the servo was set at 250mA because of the addition of load in the final toy robot.  

Electronic Component BOM and order: Generic Color Sensor Shield

Approved By: Muhannad Al Mohamed E&C DM, Charles Banuelos MFG DM

Designing The Color Sensor Shield

Charles Banuelos (MFG DM) and I have worked together to design the Color Sensor shield that would be used by the projects of the Robot Company. I was responsible for designing the schematic part and he was responsible for designing the layout part of the shield. The Shield is using two Color Sensing ICs (BH1745NUC) presented by Thomas Forman. This IC can be adjusted to have two different addresses, which makes I2C communication protocol usable while using two Color sensors.

Color Sensor Shield – Schematic

Color Sensor Shield – PCB layout

Written By: Muhannad Al Mohamed E&C DM

Updated: 11/20/2017

 

Color Sensor Shield Parts list

The parts used in making the Color Sensor Shield are listed below. They were ordered from digikey.com and has arrived. The parts will be used to fabricate and test the color sensor shield on Monday 11/27/2017.

Color Sensor Shield parts

Ordered parts’ Invoice

 

Written By: Muhannad Al Mohamed E&C DM

Muse Laser Cutter Parts Verification & Additional Purchase of Materials

Written By: Charles Banuelos (Design & Manufacturing Division Manager) & Lucas Gutierrez (Project Manager for ModWheels)

Worked on by: Charles Banuelos (Design & Manufacturing Division Manager), Lucas Gutierrez (Project Manager for ModWheels), & Vanessa Enriquez (Design & Manufacturing Engineer for Goliath)

 

Before the setup of the laser cutter, initial confirmation of all components need to be verified and made sure there were no shipping damage.  To verify this, a packing list should be included in the box.  To start the verification process, remove and document all components in an orderly fashion, ensuring no loss of components.

 

For the Muse Laser Cutter, components included:

  • Laser cutter (with power cable)
  • Instruction manual (Laser cutter manual & software operation manual)
  • Product registration
  • Warranty registration
  • Water cooler (with water hose & pump adapter)
  • Exhaust fan (with ducting)
  • Air pump (with air hose & air nozzle adapter)
  • Burn plate
  • Focus billet
  • Allen wrench
  • Thermal paper
  • Ethernet cable

 

Once parts have been verified and checked for damage, additional parts may need to be purchase in order to ensure proper performance.

 

For the Muse Laser Cutter, separately purchased parts included:

  • Water cooler
  • Air filter (with ducting)
  • 1/2″ Hose clamps
  • 3 Gallons of distilled water

 

There is a helpful un-boxing video for the Muse laser cutter.

YouTube setup link

 

Fall 2017:

An initial unpacking was completed by Prof. Hill. There was a meeting, occurring on Thursday(11/2/2017) at 3pm that verified that all parts of the laser were received. There was extra hose clamps purchased in order to secure all water hoses to the input and output of the coolant system. There was also distilled water purchased in order to run the coolant system properly.

 

 

Color Sensor Trade off Study

Written By

Charles Banuelos MFG DM

Muhannad Al Mohamed E&C DM

Table of Contents

Previous tests

The color sensor placement in relation to the PCB is very important. The distance testing that will be occurring will tell what is the best distance to place the color sensors on the PCB. The sensor placement will determine whether the robot will run smoothly along the hedges and not stop every couple of centimeters. These tests will also determine how big the PCB will be since the tests will show whether an I2C multiplexer is needed.

Matt Shellhammer conducted tests in relation to the the adafruit color sensor and forwarded me the results. The data states the distances to detect three different colors(Brown, White and Green). The code also tests the horizontal distances for the same three colors. The study states that the optimal distance vertically for all three colors is between 1mm and 2cm. The horizontal for all three colors should be between 3mm and 1.4cm. The second color sensor(BH1745NUC) will be tested in the same manner as this test.

Written By Charles Banuelos MFG DM

 

Testing Color Sensors

 

The adafruit TCS34725 color sensor had only one fixed address. This resulted a problem for the projects of the Robot Company since most of them are planning to use two color sensors. The problem with communicating with a specific device using I2C (Inter Integrated Circuit) protocol is that I2C have to address a device with a unique address and since using two adafruit TCS34725 color sensors have the same address, it would result a conflict of data being sent by those sensors when the micro-controller is trying to talk to one of them. Therefore, another solution was presented by Pr. Hill, which was to use the color sensor Thomas Forman is using. Thomas’ BH1745NUC  color sensor can be adjusted to have two different addresses. By connecting the “ADDR” pin in one of the BH1745NUC ICs to VCC and the other BH1745NUC “ADDR” pin to ground would result having two color sensors with two different addresses.

Written By Muhannad Al Mohamed E&C DM

Planned Testing

The color sensor shield that has two BH1745NUC Color sensing ICs needs to be tested. The connections of the pins should be tested using inputs preferably by a 3DoT board. If a 3DoT board were not available an Arduino Uno would be used with taking caution to the voltage to be 3.3V. Implementing Address checking codes should check the addresses of the two BH1745NUC Color sensing ICs. Data should be read and values of colors should be detected. Thomas Forman has ordered parts for his color sensor shield and since he is using the same BH1745NUC Color sensing IC, we would be able to test the parts.

After checking that the color sensor shield is working correctly, sensing colors from the maze should be tested.

Update: 11/29/2017

Parts, stencils, and solder have been ordered and received during the Fall Break. Charles Banuelos, Muhannad Al Mohamed, and Melwin pakpahan are currently fabricating the Color Sensor Shield. After fabrication is completed Charles Banuelos and Muhannad Al Mohamed will test the Color Sensor Shield. Soldered parts will be visually checked if they were placed correctly without any bridges or misplacement. Connecting the Color Sensor Shield to the 3DoT board should be tested by visually verifying that the pins of the shield are actually connected to the front header of the 3DoT board. Also, by applying an Arduino code to find specific I2C addresses using the 3DoT board, the two different I2C addresses should be checked. The Color Sensor Shield would be tested on how it can actually measure colors (intensity of different colors).

Written By Muhannad Al Mohamed E&C DM

 

 

 

Pete-Bot – Measuring Power Consumption

Written by Melwin Pakpahan (Mission, System, Test)

Description:

The power consumption of the 3DoT board will be measured as follows. A RCR123A battery will be connected in series with a test resistor and the 3DoT board. Two versions of the 3DoT board will be tested and compared. The test resistor is chosen to be 1 ohm, and the current draw is to be determined. When the power source is switched on, the voltage across the resistor is used to calculate the current going through the circuit using Ohm’s law.

Equation 1 – Ohm’s Law

Equation 2 – Variation of Ohm’s Law

 

Considerations

  • The battery is fully charged before any test is conducted.
  • A test code (“Motor_Operation_Test”) has been verified and uploaded to the 3DoT Board.
  • The motors continulously run during the test.

Cases

There are three cases of testing for the power consumption.

  1. Case One – Testing power consumption with no motors
  2. Case Two – Testing power consumption with one motor running
  3. Case Three – Testing power consumption with two motors running

Case One

Figure One  shows the circuit diagram for this first test:

Figure One – Circuit diagram for testing power consumption (general)

Case Two

A GM6 motor is connected and running as shown in Figure Two.

Figure Two – Circuit diagram for testing power consumption with one GM6 motor attached

Case Three

Two GM6 motors are connected and running as shown in Figure Three.

Figure Three  – Circuit diagram for testing power consumption with two GM6 motors attached

Constraint

Up until this point, Bluetooth communication has not been established yet. The procedures above will be repeated once communication is established.

Results

Figure Four shows a measurement of the resistor. Although, the specified value is 1 ohm, the actual value is 1.1 ohm. This measured value is desired since it provides a more accurate measurement of the current values. Figure Five shows the test run of the 3DoT board Rev 4.46 without actuators and without Bluetooth pairing. Table 1 shows the results of each test case.

Figure Four

Figure Five

Table of Results

Table One – Table summarizing results

References:

[1] Featured Image