SpiderBot’s Cost of Learning



By Nicholas Jacobs – Project Manager


As the Preliminary Design Review approached, Daniel, our Manufacturing Engineer, diligently modeled all of SpiderBot’s pieces in SolidWorks. SpiderBot’s design, originally found at Instructables. com, came with .dwg CAD files that had to be converted into .dfx files, which act as the industry standard for laser printing.  This conversion unknowingly created a very expensive problem I’ll talk about shortly. When it came time to print, we erred on the side of caution choosing to construct SpiderBot using a mix of 1/4 inch and 1/8 inch acrylic thicknesses. Excited for being one for being one of the first groups to have a design ready for print, I enthusiastically coordinated a meet-up with the Shop Foreman at CSULB’s Design Center and sent Daniel on his way to print. Not knowing what to expect, Daniel meets up with Foreman and learns that printing consists of $5 upfront and $1 per minute thereafter. Agreeing to this, Daniel begins to print. Remember that expensive problem I mention above? Well 45 minutes later, our parts are still printing-long story short, we spent $89 dollars on our first print for SpiderBot version 1. After talking to Daniel, we had no idea as to what caused this or how to fix it. On the bright side, all our parts were ready to be assembled, but at that point 45% of our $200 budget had been consumed.


Daniel began to scour for answers, not finding anything explicit, he did notice after the conversion process, any part that had a curve or bend was altered- now consisting of what he called ‘infinitesimal’ line segments instead of one smooth curve to make its shape. So when it came time to cut, the laser cutter was literally cutting each ‘infinitesimal’ line segment, hence the super long cut time.


Infinitesimal lines that increase print time.

Leg design with regular curves – faster print time.



We never found a quick fix for a smoother file conversion, Daniel decided to remake each part by hand ( in SolidWorks) to ensure that there were no more ‘infinitesimal’ to hamper our cut time. When talking about this problem during one of our weekly meetings, Daniel did suggest that follow-on semesters take a screenshot of the desired part, import into SolidWorks, and suggests using the ‘Trace tool’ in SolidWorks .


Accepting our losses, we moved ahead assembling SpiderBot while also conducting trade-off studies to determine what DC motors should drive our walking mechanism. At the time, I had two GM3 DC motors laying around from a previous project, and we decided to use in the meantime. Once assembly was complete, we tested our new design, by applying a 9 volt battery to both of the leg motors…it walked-just not consistently. This was mainly due to SpiderBot’s plus size weight of 842 grams, which is including two 31g GM3 DC motors. Hats off to the mail room located within the shipping and receiving building across the street from ECS building for weighing both builds of SpiderBot.  After presenting our preliminary design to the class, the customer stated that our design is too big and that we need to downsize.


build_1 – look at nuts and bolts for size comparison.


Reducing the size of SpiderBot isn’t as tedious as you may think. Daniel again found a ‘scale’  tool (mold tools> scale OR insert>features> scale)  within SolidWorks that allows you to expediently reduce/enlarge the size of each part by a certain factor. With the infinitesimal lines gone, the creation of a smaller more streamlined design, and all parts planned be recut using 1/8 inch acrylic, we rush to print build 2 eager to see our reduction in weight and size.


$25. That is all our 2nd cut cost to complete. That included $5 upfront cost and then 11 minutes ($11) to cut, plus $9 for a sheet of 1/8 inch acrylic. The cost breakdown is as follows:

$89 + $20 ( materials) = $109 for build_1

$11 + $5 + $9 = $25 for build_2

The corrections made from build_1 to build_2 led to a 77% reduction in price. However, the best is yet to come- our desired mass. After all pieces were cut Daniel quickly assembled SpiderBot build_2, he used a Parallax proto-board from EE 370 Lab to act as a power source to drive both motors.

build_2 – notice how much larger the nuts and bolts appear


With GM3 motors attached, we took build_2 and returned to the post office to check the new weight.

much better…for build_2!!


A breakdown of our mass:

780g + 31g(2) = 842 g build_1

385g (includes GM3s) build_2

Build_2 was a 54% reduction in mass!!

With this significant weight reduction, SpiderBot walks consistently, smoothly and appears to have little to no friction points.

As of 19 April 2017, with the 3Dot board, camera (smart phone – 178g), prototype grappling system, we’re approaching 750 grams. If we would have stuck with Build_1 we would have approached and most likely exceeded 1Kg. During our verification and validation stages over the next two weeks, the SpiderBot team will continue to look for ways to reduce our weight to ensure the best most efficient design.

















Wheel Forces Calculations

By Anthony Dunigan

Back of the envelope calculations for wheels and electronic slip differential

In order for the project to move forward in our Level 2 requirements numbers 8 and 9. We need to gather calculations based on our 6 in (0.0762m)  wheel diamater.


Names of constants and variables


r = radius (m), m = mass (kg), g = acceleration of gravity (m/s2), u = dynamic friction coefficient, uo = static coefficient, F = normal force(N), Fpw = normal force per wheel(N), FNet = net force or tangential force(N), Fstatic = static friction force(N), Fdynamic = dynamic friction force or when the wheel slips(N), T = torque(N*m), M = motor torque(N*m), Ff = friction force(N), I = current (Amps), V = voltage (Volts), Pout = Output power of motor (W), Pin = input power of motor;

m = 22kg; g = 9.8 m/s2 ; u = 0.725 (rubber on concrete); uo = 1 to 4 or 2 (rubber on concrete); M = 0.339 N*m, I = 1.96 A, Pout = 9.3 W ,  at max efficiency; M = 1.13 when stalled.

F = m*g = 22kg *9.8 m/s2 = 215.6 Newtons (N), Fpw = F/6 = 35.93 N;

For the wheels to be balanced, static friction force must fulfill this inequations:

Fstatic  ≤ uo * Fpw =  (2) *35.933 N = 71.866 N;

If the static friction is unable to balance the system, then the static friction becomes dynamic friction and that’s when the wheel slips. The dynamic friction equation is:


Fdynamic  = u * Fpw = 0.725 * 35.933 = 26.05 N;

For the wheel to avoid any slip, the friction force which is dependent upon the motor torque (M) should satisfy the equation below:


Ff = M/R  ≤ uo * Fpw

Ff = 0.339 (N*m)/0.0762(m) = 4.45 N


So the  force acting on the wheels must not be greater or equal to the friction force of the motor.









Solar Current Sensor Experiment

(Written By: Edgardo Villalobos – Manufacturing/Solar Panel)

This project requires current sensors in order to measure the current running through the solar cells. We are having 36 solar cells on the solar panel. We are using 12 INA3221 current sensor breakout boards to do this because they each contain 3-channels, support high-side current and bus voltage monitors with an I2C interface. These sensors are able to connect to the Arduino we will be using.


This project requires current sensors in order to measure the current running through the solar cells. We are having 36 solar cells on the solar panel. We are using 12 INA3221 current sensor breakout boards to do this because they each contain 3-channels, support high-side current and bus voltage monitors with an I2C interface. These sensors are able to connect to the Arduino we will be using.

In the photo below, there is only one channel being used. The voltage is only measured because to measure the current, the circuit requires a load.

The Arduino code for the current sensors is shown below for one channel. It defines the channels and names, sets all values to zero, reads the input values, and finally gives out the outputs for each of the channels being used.

For practice, a battery and a resistor were used to find the voltage and current. The battery is the voltage source and the resistor acts as the load. The current sensor was able to record both current and voltage.

Pick and Place – Camera Test

By: Kevin Ruelas (Electronics)

Using the interface definitions defined in the camera document. I was able to test the camera to make sure it worked and was taking a photo correctly. The microSD board was a big part of this test as it was required to test the image before figuring out how to send it to Processing and if it was receiving the correct data. In terms of edge detection, I used an open source library called OpenCV. Upon looking at all their libraries I found the Canny edge detection to be the best for defining an edge. The photo is sent 64 bytes at a time and it may take up to 10 seconds for it to completely transfer the photo. From here, calibration code can be written to analyze the photo taken pixel by pixel and reference it to a calibrated photo in order to determine how much the X and Y axis needs to move so it can be at the origin.


Pick and Place – Z-Axis and Nozzle Test

By: Tiler Jones (Manufacturing) and Chastin Realubit (MST)

Z-Axis Motor: We did an experiment to see the load that the Z-Axis can handle and we found that it will still carry up to 2000 g. This experiment was done so that we can see if the motor can still move up and down even with more load. This was needed because we are adding a camera on the Z-Axis and we needed the system to still function with extra weight.

As seen on the pictures below, the Nozzle was completely removed due to its instability, the rods were replaced, and wires routed differently to reconnect and replace the nozzle to be stable so it does not move while the Pick and Place is running.


Spring 2017 Velociraptor: First SolidWorks Model


By: Andrea Lamore (Manufacturing)
Approved By: Jesus Enriquez (Project Manager)


During the early stages of the design process, leading up to PDR, the Velociraptor’s frame was similar to what was presented at CDR but had a few distinct differences in terms of specific part modification and part sizes. The purpose of this post is to present one of the first iterative designs for the Spring 2017 Velociraptor.

3D Modeling on SolidWorks

When first designing the hardware model for the Velociraptor, a design change was made so the Velociraptor could be made to walk with 2 DC motors. The Theo Jansen Linkage allows for walking with continuous rotation around a jingle joint, making it an ideal choice for the Velociraptor leg design.

The Velociraptor requires a turning mechanism. This could be done most obviously by having one leg take steps while pivoting around the other leg (much like how an RC car turns), or my adding an axis of rotation around one of the joints in the leg (either the hip or the ankle in our cases). Two universal joints at the hip was chosen to provide rotation at the top of the leg mechanism. This allows the continuos rotation of the leg  while the hip is at an angle.


The DC motor will be placed on the outside of the leg as to help with balance of the robot by moving mass away from the center axis so that shifting the center of mass (done by shifting the head and the tail) may be accomplished more easily. This also allows the motors to stay in parallel with the leg when the hip rotates.

When the velociraptor turns, the center of mass will move away from over the fulcrum point, for that reason two servos will control the head and tail independently. This was decided so that when the velociraptor turns, the head can be adjusted separate from the tail so that the center of mass stays over the fulcrum pint (over the standing foot). The following figure demonstrated how the center of mass changes with rotation of the hip.


As the iterative design process was pushed forward, through prototyping and trial & error, it led to further design changes leading up to our CDR design model. Realizing as oppose to modeling on SolidWorks is much more difficult and that was discovered through experience in assembly the physically manufactured parts for the Velociraptor.

Pick and Place – Solenoid Valve Design and Control

By: Tyler Jones (Manufacturing) and Kevin Ruelas (Electronics)

The above Figure 1 and Figure 2 schematics show the solenoid circuit simulated in LTSpice. The circuit on the left shows that when the arduino pin is set to high the circuit turns on allowing the current to flow through drain and source to the solenoid valve. The circuit on the right shows that when the arduino is set to low, there is no current flowing through the drain and source to the solenoid.

This creates an electronically controlled switch, and can be programmed to turn the pump on when picking a part, and off when placing a part. This is vital to the pick and place control system because it needs to be able to switch on using power from the Me Adapter board of +5V, to control a larger voltage of +11.7V from the Me Uno header pins. The IRF 530 MOSFET switches the gate voltage of +4.7V to the source drain voltage of +11.7V This voltage can is now large enough to drive a current to the solenoid and turn it on and off. The +4.7V control voltage from the arduino is programmed to correspond to the following values.


The solenoid was tested using an ammeter in series with the Drain of the MOSFET and wire of the solenoid. The current draw shown in Figure 3 through the MOSFET into the load was about 410mA. The turn on current needed to excite the coil in the solenoid was found to be about 310mA. This means that the solenoids resistance value can be modeled most accurately as an inductive coil load in series with a resistive load. The total resistance of the solenoid based on current draw was an operating range of about 24-35 ohms. The circuit works as designed and tested.

The tested circuit shown above was translated into a custom soldered PCB, in order to have the wires and components secured to a fixed location within the electronics housing. The PCB board will be mounted on standoffs inside the electronics housing.

Spring 2017 Velociraptor: DC Motor Selection


By: Mohammar Mairena (Electronics & Control)
Approved By: Jesus Enriquez (Project Manager)


Through research on DC Motors, I came across gear motors. Gear motors add mechanical gears (gearbox) to reduce speed/increase torque and vice-versa. The increase in torque is inversely proportional to the reduction in speed. Each gearmotor has a different gear ratio that alters the torque/speed calculations. Through the E&C division manager and Professor Hill, I borrowed what were said to be two GM 7’s and a GM17.

Selecting the DC Motors

After testing what was supposed to be two GM 7’s, I realized the current values did not match up to those on the GM 7 datasheet. Upon further research, one of the GM 7’s turned out to be the pololu 200:1 plastic gearmotor with a 90° Output. The other motor was also not a GM 7 as it drew much more current than a GM 7. For both motors, I measured two things: stall current and the free running current at no-load. The stall current is the current at which the shaft of the motor is no longer rotating (under max torque conditions).
Comparing both motors, it is clear that the Pololu is much more ideal for our robot due to the low current draw it will have in comparison to the other yellow motor. In addition, it is important to note that the current draw from the Servo motors has not been taken into account. The Pololu gear motor is a great alternative to the GM 7 for 2 reasons: low current draw and high torque output.

Table 1: Pololu 200 Results

Table 2: Yellow Gear Motor Results


1) https://www.pololu.com/product/1120/specs
2) http://www.robotshop.com/en/solarbotics-gm7-gear-motor-7.html


Spring 2017 Velociraptor: Fritzing Diagram


By: Mohammar Mairena (Electronics & Control Engineer)
Approved By: Jesus Enriquez (Project Manager)


Before one can create a custom printed circuit board (PCB), one has to create a Fritzing diagram. A Fritzing diagram is a virtual electronic circuit that is modeled after a circuit tested on the breadboard. Fritzing is used to provide the layout of the breadboard given the tools needed for a future PCB design.

Fritzing Diagram

The diagram shown is the Fritzing diagram our group used for the Preliminary Design Review (PDR). The diagram is a very rough idea of the parts we are using for the final schematic. This diagram is meant to provide a general idea of the parts needed for the final PCB design. Each part shown serves a purpose.

The breadboard consists of the 3Dot board, three servo motors, two DC motors, an external battery, an A/D converter with rotary/shaft encoders, an additional low-dropout voltage regulator for the extra servo motor and a GPIO expander. Two DC motors are used to control the legs of the raptor, one servo motor to control the head and another to control the tail. The extra servo motor will be used to control the turning motion of the Velociraptor. Since the 3Dot board is only capable of utilizing two servo motors and two DC motors, a PWM expander is necessary for our additional servo motor. The PWM/Servo driver is not shown and should replace the GPIO expander in the design. The PWM/ Servo driver with i2C interface has the capacity to add extra servos through two pins, SDA & SCL (Data and Clock).


Note: The 3Dot board was taken from Fall 2016 Velociraptor’s fritzing diagram.


  1. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/07%20FritzingDocumentation.pdf        
  2. http://www.arxterra.com/fall-2016-velociraptor-w-fritzing-diagram/ 

Spring 2017 Velociraptor: RGB Color Sensor


By: Mohammar Mairena
Approved By: Jesus Enriquez


The Velociraptor will compete in a game similar to Pacman. One of the requirements is that the Velociraptor shall attempt to collect as many red dots as possible while navigating the maze utilizing either a static or dynamic walk. As a result, we will be using an IR sensor to detect the dots in the maze. My choice for the color sensor is the Sparkfun RGB Color Sensor. The reason I chose this specific sensor (APDS-9960) is because of the detection range and the operating voltage at 3.3 volts. In comparison to other sensors, this one has a lengthy detection range of 4-8 inches.


The SparkFun sensor includes examples of Arduino library code for color sensing and proximity detection. I tested the color sensor and proximity sensor with the library code. After hooking up the sensor to the breadboard and uploading the code, I placed different colors up to the sensor. I had a hard time distinguishing colors using the serial monitor on the Arduino interface.


In retrospect, the SparkFun RGB Color Sensor is an ideal infrared sensor for the Pacman game however, detecting the different colors (red, blue, green) proved to be very difficult. Another disadvantage of this sensor is that it is very miniscule and would only detect the red dots if they were large in size. Completing this experiment helped me realize how minute the sensor was and how important it is going to be to correctly place the sensor on the robot.


  1. https://www.sparkfun.com/products/12787