By: Jefferson Fuentes

Requirements:

The Spring 2017 3DoT Spiderbot, S-17 Spider, is required to utilize the program assigned 3DoT board for processing and control.  In addition, S-17 Spider must utilize a custom PCB design for mission objectives.

Introduction:

S-17 Spider utilizes the program assigned 3DoT Board (Fig. 1), featuring an ATmega32U4 Microcontroller.  The 3DoT is prefabricated and designed to provide connections and control to two 5V DC motors, two 3.3V Servos, and an I2C port for expansion capabilities.  S-17 Spider will be using the two available motor connections, one servo connection, and the I2C pins for an external custom PCB.  The external PCB will be powered via 3.3V supplied by I2C and will be used to control a third DC motor.  The following will provide insight into S-17 Spider’s wiring layout, or “Cable Tree”.

S-17 Spider can be summed up in a system block diagram (fig. 3 & 4), demonstrating the projects functions and how connections are implemented.  From SBD, a total of 13 wires, 11 from 3DoT and 2 from PCB, will be used in the project.  Each of the three motors will incorporate a twisted pair technique to minimize noise and keep the keep wires traceable, connected to JST terminals.  The servo is hardwired and connected to JST terminals.  The I2C connection between the 3DoT and external PCB, consisting of 4 wires, will remain consistent in the color choice of the wiring to allow easier traceability, and will use.

Figure 1 – 3DOT board.

Figure 2 – System Block Diagram

Figure 3 – PCB System Block Diagram

Process:

“Cable Tree” planning first begins with a sketch (fig. 3), which follows the system block diagrams for the S-17 Spider project.  The sketch represents a rough draft of a propose cabling system to serve as a reference for a 3D rendering (fig. 4) as well as reference table for cable colors (table 1).  These are the building blocks for the final S-17 Spider Project build.

Figure 4 – Wiring Color Diagram

Figure 5 – Wiring Sketch

Figure 6 – SolidWorks 3D Rendering

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.

By Nicholas Jacobs – PM

By Jefferson Fuentes – MST

Requirements:

Spring 2017 SpiderBot is required to provide live aerial video feed capable of covering the entire arena, as defined by end-of-semester-game, to other participating robots.  

Introduction:

The ArxRobot phone app works in conjunction with the Arxterra mission control panel.  The app utilizes the phone’s built-in camera, and transmits data wirelessly via internet connection to the control panel.  From the control panel the user is able to see what the phone sees.  For the specific purpose of the Spiderbot, it is required to provide a live video feed of the game arena to the other participating robots.  The camera test is used to determine the minimum distance the phone camera must be to provide coverage of the entire arena.

Procedure:

The camera test was conducted using the Arxterra control panel, the Arxrobot app, an android phone, a wall, a tape measure, and tape to mark off varying lengths along the wall.  The android phone used is a Huawei Nexus 6P.  On the wall, a square of known length and width is marked off, setting up a mock arena.  Once set up, the phone is incrementally set further away from wall, until the entire mock arena is encompassed on the ArxRobot and Arxterra Screen shown in figures below.

Phone Camera Specifications:

Model: Huawei Nexus 6P

Megapixels: 12.3
Pixel size: 1.55 μm pixels
Aperature size: F2.0
Hardware: IR laser-assisted autofocus
Video(max): 4K resolution
Flash: Broad-spectrum CRI-90 dual flash

Features: 240fps slow motion video capture

Results:

3×3 Square Arena

Fig 1. Arxterra Visualation(3×3)

Fig 2.  Arxrobot Visualization (3×3)

Fig 3.  Arxterra Visualization (5×5)

Fig 4. ArxRobot Visualization (5×5)

Tables

Conclusion:

The Nexus 6P, in conjunction with the ArxRobot app and Arxterra mission control panel are more than capable of delivering live video feed.  The field of view delivered is dependent on the distance the phone camera is from the arena, at least 53 inches for a 3×3 arena.  Looking at figures 1 and 2, an important observation can be concluded.  The onboard camera is not optimized for a square arena, instead a rectangular arena, would much more effectively use the camera’s full field of view. My recommendation would be to implement a 3’X5′ game arena, this will require less materials to construct a suitable anchor point and provide the best possible view of the arena for game participants. SpiderBot out….  

Resources:

1. http://www.androidcentral.com/nexus-6p-specs
2. http://www.gsmarena.com/huawei_nexus_6p-7588.php

Written By Jefferson Fuentes

Introduction:

The Arxterra app has the option of creating custom commands.  These custom commands allow for a user defined function, to control the robot, not already preloaded onto the app by default. These commands consists of functions such as a simple switch to incremental sliders.  

Requirements:

Spring ’17 SpiderBot is required utilize the Arxterra phone app to control the robot remotely via bluetooth.  SpiderBot is also required to provide aerial live video feed capable of covering the entire arena, as defined by end of semester games to other participating robots.  The video feed will be accomplished by the bots ability to hoist itself up in the air through use of a grappling system.

Procedure:

Creating custom commands on the Arxterra phone app consists of a few finger taps, navigating through the menus, and selecting the appropriate options.  Upon launch of the Arxterra app, the familiar control screen will appear (fig 1).  From here, developer mode must be turned on to create the custom commands required.  By selecting the menu option, on the top right corner, we come to the toggle option for “Developer Mode” (fig 2).

Fig 1. Arxterra initial launch screen           Fig 2. Developer Mode Toggle

After toggling, under the same menu, selecting the gear icon will open another menu.   Selecting the “Custom Command &  Telemetry Configuration” will navigate to the appropriate window to create the custom commands (fig 3). Once selected, a new window appears (fig 4).  This window allows us to add, change order, or edit any custom commands created.

Fig. 3 Custom Command & Telemetry Navigation

Fig 4. Command & Telemetry Options

To create a new command, clicking on the “+” icon will open a menu (fig 5).  Here the required type of command can be selected.  For SpiderBot, one of the custom commands required is the ability to release a grappling hook upon command.  This function would be incorporated using the Boolean command option, single input dual outcome output. When selected,  the app automatically generates a default command (fig 6).

  Fig 5.  Command Selection        Fig 6. Default Custom Command

This default command serves no purpose to the robot and must be edited for proper function.  To edit, the function to be modified is selected, then the pen icon is clicked, prompting a new window (fig 7), where all parameters will be defined.  In this case, SpiderBot requires a command to enable release/launching of a grappling hook, this can be accomplished by implementing a simple switch. The first set of parameters, or properties, consists of the Entity ID is the command ID in HEX, the label, is the name associated with the function, and the default value serves to determine the state of the command upon startup of control panel.  The second set determine where the custom command appears/operates in.  Both are on as this function is needed on both the app and control panel.  

Fig 7.  Command Parameters

The app and control panel determine successful custom command implementation.  The app will show a new icon, the custom command with all defined parameters (fig 8), and a message “Custom command config valid”.  On the control panel, the custom commands will appear in a designated “Custom Controls” box (fig 9).

Fig 8. Arxterra Custom Command         Fig 9. Arxterra Mission Control Panel

Resources:

1. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/19%20Arxterra%20Custom%20Commands.pptx
2. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/20%20Arxterra%20Videos.pdf
3. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/_3DoTTrainingDocumentation.pdf

Motor Trade Off Study

By Shaun Pasoz – Electronics & Control Engineer

Requirements:

Based on the level 1 requirement that all power shall be supplied via the 3DoT board, the motor choices have certain limitations including: must draw 450mA or less, and have an operating voltage of 5V or less.  

UPDATE

Following the Preliminary Design Review the customer requests that SpiderBot’s overall size needs to be reduced. Our initial build had a mass of 858 grams. The SpiderBot team has decided to reduce the overall mass to 500 grams or less. Since our mass has changed, so has the motor torque requirement to make SpiderBot walk. In a future post we will present a systematic process used to determine the torque requirement.

Introduction:

Due to the delicate nature of servos, SpiderBot’s walking mechanism will be driven by two DC motors. DC motors are basic electromechanical devices. They consist of two wires, one for V+ and one for V–. The speed, or power level, of the motor is controlled via pulse width modulation (PWM). PWM controls the motor by allowing, for example, full voltage for 50% of a duty cycle to create 50% of the rated RPM. Since the DC motor only has two wires, it provides no feedback. When compared to a servo motor, the servo has: a DC motor, a position sensing unit, and feedback control. However, servos are prone to gear degradation under heavy loads, and size is proportional to cost. This post attempts to deliberate the factors in choosing the correct dc motor for SpiderBot. 

Types of DC Motors:

• Stepper Motor: A type of DC motors that moves in a predefined step size. They are much more precise, and allow for more control than say a brushless motor. This will not be used in the robot as they are much too bulky for our desired size and weight.

• Brushless Motor: A motor that utilizes electronic communication to control the current flow through the motor. This will not be used in our robot as it is more complicated to control.

• Brushed Motor: These are the most common motors and are useful for many applications. They can be used in geared motors which will provide more torque. The increased torque and price are what makes the brushed motor ideal for our robot.

Discussion:

The three main factors in choosing the correct motor comes down to: cost, size, and operating parameters. Out of the three types of DC motors, brushed motors became the immediate choice for the reasons listed under types of DC motors. After the PDR review, it became evident that we needed to shrink the robot and cut as much weight as possible, therefore we will be trying to choose motors that weigh less than 20g. However, smaller motors tend to have less power. Our operating parameters require that the motor operate at 6V or less and have an operating current of under 450mA as this is what the 3DoT can power. After conducting research this is the list of motors that most closely suit what we are looking for:

Table 1: Motor Trade Off Study Data

Conclusion:

In conclusion, the most suitable type of DC motor for our robot is the brushed DC motors. From there the guiding factors for deciding which motors to look at were decided from the limitations of the 3DoT board. For the time being, the motors that are going to be the most viable are the SparkFun Micro Gearmotor, or the Pololu 298:1 Micro Metal Gearmotor. To conduct our initial testing of the miniaturized SpiderBot we will be using the SparkFun Micro Gearmotors as it meets the correct parameters even with a load large enough to stall. Some of the testing will include average current draw under load, and max power test.

Motor 1: https://www.pololu.com/product/2371

Motor 2: https://www.sparkfun.com/products/12285

Motor 3: https://solarbotics.com/product/gm3/

Motor 4: https://www.sparkfun.com/products/11696