Table of Contents

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

Power report should ideally be three separate reports denoting all power allocations on the project, Battery, 3DoT, and custom PCB. Each power report must include the max, min, and average power consumptions. This data will ensure proper power allocation to project, as well as expose any over/under power supplied.

Mass Allocation

By Jefferson Fuentes -MST

Spiderbots resource reports consist of cost, mass, and power allocations. Mass is the sum of all components on project minus the phone. The total mass is what the DC motors, movements and winch, must be able to provide power and torque to in order to move.

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.