By Shaun Pasoz – Electronics & Control Engineer

Introduction

While waiting for the breakout boards to come in the mail, to make the best use of time the E&C division manager tasked us with coding quizzes. One of the quiz questions involved controlling the TB6612FNG motor driver using a microcontroller such as the Arduino UNO. Below is the snippet of code submitted for that quiz question along with the comments:

In order to allow easy calling of the functions for the MST engineer the moveIt() function was itemized into corresponding functions as follows: a forward move, backward move, left turn, and right turn. An example of the forward() function is demonstrated below:

This code displayed above allows for control of two motors by utilizing four digital pins and two PWM pins from the microcontroller all from the same function. From here the next step was to include the code to control the third motor that will be controlling the winch.

Since the 3DoT only has pins available for two motors, it was necessary that the third motor be controlled via I2C. After doing some research it became evident that the Adafruit Motor Shield V2 used the same primary ICs as our PCB. To avoid writing code to manually control the I2C protocol the Adafruit Motor Shield library was used. The following snippets of code demonstrates our implementation of the Adafruit Motor Shield library:

Conclusion

To summarize, the motor shield object is instantiated using the Adafruit library with an address of 0x60. Motor 1 is then instantiated (since our project only needed one motor to be controlled only one instance of the object is instantiated), where the logic pins AIN1, AIN2 and PWMA from the TB6612FNG IC is connected to PWM pins 0, 1, and 2 on the PCA9685 chip. In order to allow for this the Adafruit library .cpp file was changed such that AFMS.getMotor(1) corresponds to PWM pins 0, 1, and 2.

The object is then began in the setup function and STBY pin on the TB6612FNG IC is brought HIGH by setting PWM pin 15 to a 100% duty cycle. Furthermore, the winch motor is set to full speed since the system utilizes 3.3V to power the motor, full speed is adequate for all instances of the winch motor control. Lastly, the equivalent move function of the winch motor is itemized in a function, called goUp(), to easily be called by the MST engineer when programming Bluetooth communication.

Project Overview

Executive Summary

By Nicholas Jacobs – PM

The purpose of SpiderBot is to make an inexpensive, fun toy that can walk, turn, launch a grappling hook, and raise/lower itself to/from a predetermined height. While anchored, SpiderBot will provide a live video feed to the Arxterra Control Panel.

System Design

By Jefferson Fuentes – MST

SpiderBot consists of the 3DOT controller board based around Atmel’s 32U4. 3DOT also incorporates the TB6612F Dual Motor driver that drive two DC motors that enable SpiderBot to walk. SpiderBot also has a custom built grappling  hook that is launched under rubber-band tension. Once the grappling hook anchors to a fixed position the custom made winch motor assembly hoists SpiderBot to an elevated position. The 3DOT board can only drive the motors meant for walking, the custom PCB incorporates another TB6612F to drive the winch motor, and a PCA9685 PWM Expander that enables the custom PCB to communicate with the 3DOT board via I2C. To see our System Block Diagram go here.

Subsystem Design

Experimental Results

By Nicholas Jacobs – PM

At the onset of our design,  multiple trade off studies to determine what parts are required to complete our requirements. Our material trade-off study explored SpiderBot’s possible composition, while the motor trade-off study  looked at possible DC motors that could best meet the customer requirements. Once the proper DC motors was picked and ordered, we conducted a motor torque test to verify that the chosen motors were up to the task. We also conducted an experiment that determined the most effective way to suppress DC motor noise generated by the commutators switching polarities.   Lastly, since SpiderBot’s purpose was to provide a live video feed to the Arxterra Control Panel from an elevated position, we had to determine what reliable size maze could be covered with the phone being used. The experimental steps can be found here.

Interface Definition

By Jefferson Fuentes -MST

Interface definitions are used to determine the connections within the project.  The most crucial component, the ATmega32u, is the the brains of the project and process all commands.  Interface definitions for the the custom PCB are also included, showing how to connect it all to allow for proper function.The final, most updated description that explains the the inner workings and connections for the 3DOT controller, and the custom PCB  can be found here.

Mission Command and Control

By Jefferson Fuentes -MST

One requirement stated that SpiderBot is to be controlled by the Axterra App via a bluetooth connection. The Missions System and test Engineer’s job was to configure any custom command and telemetry decoding and encoding schemes that were necessary for SpideBot’s mission. Instructions, software block diagram, Arduino code, and  a detailed description the Arxterra Control Panel set-up can be found  here.

Electronics Design

By Shaun Pasoz – E&C

The motors that drive SpiderBot’s legs were initially GM3 DC motors. However the way they were mounted and the weight they had posed problems. Instead we settled on SparkFun’s MicroGear motors for they’re size, weight, low stall current, and very high torque output.  Pololu’s Microgear Motors.

Another capability that SpiderBot had was to launch our a grappling hook remotely via the Arxterra App. This was done by controlling a 3.3 volt servo from the 3Dot board. Since the grappling system is rubber-band actuated the servo unlatches a sear-style catch that allows the grappling hook to launch. Additional information can be found here click on 3.3volt_servo.

Firmware

By Shaun Pasoz – E&C

Firmware for controlling the 3DOT, custom PCB, and 3 DC motors, along can be found here.

PCB Schematic

By Shaun Pazos – E&C

Our custom PCB incorporated an additional TB6612F motor driver to drive our winch motor that allowed for SpiderBot to climb. Also on our custom PCB is a PCA9685 PWM Expander and its main purpose was to relay data packets from the 3DOT controller to our custom PCB via I2C. Additional information can be found here click on Custom_PCB_Chips.

PCB Layout

By Daniel Matias – MFG

More information can be found on our Custom PCB blog post after it had been built and tested. Unfortunately, only briefly did the custom PCB work. It will forever remain a mystery as to why. Additional pictures and other resources can be found here.

Hardware Design

By Daniel Matias – MFG

SpiderBot was based off the TerrSpider Instructable. The first build of SPiderBot consisted entirely of 1/4 inch acrylic. This caused SpiderBot to have a naked weight of 800 grams. The customer rejected this design and required that SpiderBot’s size be reduced. The first build was a costly one too, you can read all about it in our lessons learned blog post.

After the Critical Design Review SpiderBot was reduced by 25%. This resulted in a more streamlined design, and drastically reduced SpiderBot’s weight. All SolidWorks files and animations can be found here.

It’s amazing the ideas one can find on Youtube.  Our winch design is slight modification of a Westimation Miniature Winch . This design is desireable because of its size and torque.

Verification & Validation Test Overview

By Jefferson Fuentes -MST

Spiderbot was only tasked with doing a verification matrix this semester.  It consists of all requirements, testing procedures, and outcomes.  The detailed plan explaining how all tests were conducted can be found here.

Project Status

Power Allocation

By Jefferson Fuentes -MST

Cost Report

By Nicholas Jacobs – PM

As we mentioned in our lessons learned blog post,  the first build of SpiderBot was a costly one. The laser cutting for Build 1 consumed ~42% of ur initial budget. To look at our cost breakdown click here. 

Updated Schedule

By – Nicholas Jacobs – PM

Keeping and adhering to a strict schedule is very important, especially in the first 6 weeks of the class. Once a design has been chosen and approved by the customer task your manufacturing engineer to start laser cutting or printing. The project manager and systems engineer should begin developing level 1 and level 2 requirements based on the Program Objective and Mission Profile.

If your laptop or desktop screen has a 3200 X 1800 resolution then ProjectLibre is NOT the scheduling software for you. I would suggest using Microsoft Scheduler instead.

Here is our top level and subsystems semester schedule. The top level schedule covers the tasks that, if not completed, will result in an incomplete or failed project. The subsystems schedule is a specific breakdown of tasks by division. Keeping track of this and updating is critical for mission accomplishment.

Final Thoughts

By Nicholas Jacobs – PM

During the last 4-5 weeks of the semester problems were discovered that could be solved with the remaining time of the semester. The walking mechanism never 100% worked all the time. During a revolution of the leg linkage is a point where the drive gear pinches one of the driven gears making the motor stall.   Luckily the motors run at 5 volts. Most of the time this was enough to power through friction points and offset hand drilled shaft holes. As the crow flies looking down at SpiderBot from above, you’ll see that the SparkFun MicroGear motors aren’t normal to the side panels they engage with. I believe that if this were fixed, this would correctly align the drive gear to the two driven gears.

One misfortune was the custom PCB. It not working was a surprise because of the number of revisions we had along with the number of eyes who reviewed it- I was sure it would be plug and play. Looking back at the PCB layout, I would have added a power and ground plane. This will cut down on noise by eliminating the number of open loop antennas created by traces.

One bigger regret I have for SpiderBot is not taking the time to research the parameters of the Simulink Winch Model. Calculating the parameters necessary for this model could have influenced our winch motor selection or helped us better design a better gear ratio to increase speed. At a bare minimum we would have been the only group to have any kind of Simulink model for any subsystem of our project.The winch built for SpiderBot didn’t have a brake and was deleted from the model.

This semester’s SpiderBot was successful for two reasons. The first being that we decided to go with an Instructables Project that PROVIDES DESIGN FILES!!!!!!!!!!! ( Be Careful ) Once we decided on the TerraSpider concept, already having the .dxf files allowed us to print and produce our strawman design the following week. Remember our jobs as engineers is to be more effective rather than original, in this case starting off with something already done saved countless hours of unnecessary design time. Strawman design is another name for a proof of concept or first draft, but is ultimately something that undergoes the iterative process-which undergoes continual improvements and modifications which slowly morphs into a robust, well made end product.  The second reason is that we kept our self in a small box, otherwise know and KISS- Keep it simple, stupid. We set very REALISTIC and SIMPLE goals that, we as a team felt were actually realizable – walk, turn, turn a servo and climb.

Resources

SpiderBot Video

CDR 

PDR

Project Libre (with Excel Burndown file)

Verification and Validation documents

Solidworks File

Fritzing Files 

EagleCAD files (zip folder) Linked to in Electronics Design Blog Post

Arduino and/or C++ Code (zip folder) Linked to in Software Design Blog Post

Complete Bill of Materials (BOM)

By Jefferson Fuentes – MST

Requirements:

The Spring 2017 Spiderbot project, S-17 Spider, shall provide a live aerial video footage for end of semester game.  In addition, S-17 Spider, shall incorporate a grappling mechanism to elevate itself from the ground level.

Introduction:

The S-17 Spider features the ability to elevate itself off the ground through use of a grapple and winch system.  The purpose of this post is to provide an explanation of the Spring 2017 Spiderbot project, S-17 Spider, custom commands utilized in controlling project functions via the ArxRobot App.  The software block diagram (fig. 1) shows a layout of all functions used for control of project.

Figure 1 – Software Block Diagram

Commands:

The MOVE command is utilized to control the projects directional functions.  By sending individual commands to the two connected DC motors, each motor can spin clockwise or counterclockwise, allowing for desired direction.  

The LATCH command serves to control the single servo connected to 3DoT.  The servo is sent a signal to spin its full 180 degrees and release the grapple, hence the function name.

The WINCH command serves to control a single DC motor connected to the custom PCB via I2C.  Similar to the move command, a signal is sent to the DC motor to spin it clockwise or counterclockwise.   The motor serves to power a winch, which allows the project to elevate itself higher or lower.

The code for the custom commands is shown below.  The first step is initialization of the code (fig. 2), which includes all necessary files to run all functions denoted by #include <>.  The custom commands are then defined, #define, and given their address, 0xXX.  In S-17 Spider, we are using 3 custom commands which also needs to be declared in the following line.  The last few lines are the handlers.  Their purpose is to direct the incoming command to the appropriate function (custom command).  

Figure 2- Code Initialization

The parameter for all functions is 0 to 255, a byte.  This works wells with the MOVE command, which moves clockwise and counterclockwise.   The LATCH command controls the servo, which can only rotate 180 degrees.  To accommodate, 0-255 must be converted to 0-180.

ArxRobot Control:

The s-17 Spider uses the provided ArxRobot app for wireless control, via Bluetooth, of the project.  The three main function of the project are included (fig. 3) in the app layout.  For the S-17 Spider project all functions are in Boolean, meaning that either function is either on or off.  The winch function uses two Booleans to control the direction the motor spins.  The latch function controls the servo which turns the full 180 degrees one way or the other.  

Figure 3 – ArxRobot Layout

Torque Testing

By: Shaun Pasoz

Electronics & Control Engineer

Torque testing allows the designer to see if a desired motor can output enough force to physically move a robot. To perform the test, a rig was designed in which the motor was clamped down with a fixed radius on the output shaft. Varying weights were then hung from the fixture using a very thin fishing line. This setup allowed for the force pulling the weight down from gravity to always be tangential to the fixed radius, allowing for simpler calculations of torque using the following formula:

τ=rFsin(θ)

The variables used to find torque are:

• F = Magnitude of the force applied to the lever arm
• r = Radius from axis to the point of applied force
• θ = angle between r and F

Since the designed rig allows the force to always be tangential to the radius, the equation is simplified to τ=rF. To control the amount of force on the radius, the weights are used to continually increase the force. Therefore, the final equation for calculating the torque is:

τ=r*mg

The following tables show the data measured during the torque testing:

Table 1: Sparkfun Torque Testing Data

Table 2: Pololu Torque Testing Data

Figure 2: Torque vs Mass Graph

Since both the radius, and the angle between the force applied and radius, the relationship between torque and mass is going to be the same for both motors. Where they begin to differ is when the other parameters of the motor are observed. For example, the current draw of the Pololu motor was over double with a 700 gram load on it. This is because the motor has been chosen to run at 3.3V instead of 5V to accommodate the customer’s needs.

The SpiderBot’s expected mass is 700g. The required torque to move 700g was calculated to be 1.46 ounce-inch. Both motors have a stall torque well above that, and therefore should be able to safely move the SpiderBot.  

With the expected load, the Pololu motor RPM was calculated at 44 RPM. This was found by putting a piece of tape on the radius and counting the revolutions for 30 seconds three times and taking the average. Repeating the process for the Sparkfun motor; it’s RPM was calculated as 33.3 RPM. Some possible deviations may occur as possible sources of error include: neglecting the weight of the weight of the fishing line that pulled the weights, and not including the various friction points in the calculations. Overall, the motors should be able to move SpiderBot without damaging the 3DoT or our PCB.