Spring 2017-Arxterra Control Panel Update!!!!

/in , /by

Written By Jefferson Fuentes

Table of Contents

Introduction:

The Arxterra mission control panel is to work in conjunction with the Arxterra phone app, transmitting and receiving information to and from the robot.   It serves an extended/secondary means of control with more capability than the Arxterra app.  The control panels main purpose is to increase the capable range for controlling the robot, theoretically to anywhere in the world, as opposed to the limit of the Bluetooth range.  It is also capable of providing more telemetry to user than the app, i.e. video feed, pitch, roll, speed, robot location, and any other as needed information.  

 

Requirements:

The 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 of the end-of-the-semester game to other participating robots.  The video feed will be accomplished by SpiderBot’s ability to hoist itself up in the air through use of a grappling system.

 

Set Up:

To utilize the Arxterra mission control panel a quick setup is required.  The following is a walkthrough of the process.  

 

Part 1:  Arxterra App Initialization

The first step is to attain permission from the administrator to access and download Arxterra app.  The Arxterra app uses a Bluetooth link to connect to SpiderBot to facilitate movement control. 

Fig 1. Arxterra App initial launch screen

 

On boot up, the Arxterra app begins in the remote control function(fig 1) by default.  This function allows us to control the robot with a phone via a Bluetooth connection.  To control the robot using the control panel, the next step is to switch over to community mode.  This can be achieved by pressing the function icon on the app (fig 2), which allows us to toggle between robot and community mode.   

Fig 2. Toggle Function

 

Toggling community mode launches a sign in window (fig 3), with two required fields Robot name and Pilot name or names.  These two fields are used to define which robot is to be used, and who has access to controlling it through the Arxterra mission control panel.  Confirmation of success is given by a message at the bottom left corner of screen, “Live cast published” (fig 4)

At this point, all necessary steps have been achieved concerning the Arxterra app.  As an added method of determining whether the Arxterra app and arxterra control panel are working properly.  A simply check on the app will verify functionality.  Clicking the camera icon after the login procedure will display basic camera feed status as well as a display window showing what the phone is streaming(fig 5).

                       

Fig 3.  Arxterra login window     Fig 4. Login Success

 

Fig 5. Connection Test

 

Part 2: Arxterra Mission Control Panel Initialization

 

Procedure:

Next is the Arxterra Mission Control Panel interface setup.  The control panel is used as an extended/secondary mode of control over the robot.  Its main function is an increased range for controlling the robot, as well as providing more telemetry of the robot.  In the case of SpiderBot, it will serve as a method of providing video feed in the end of semester games.  

 

To access the control panel, the following link is provided: Arxterra Mission Conrol Panel.  Accessing the control panel brings up the window seen in fig 5.  This is the main window where login is accessible.

Fig 6. Main Arxterra Control Panel Window

To login, simply click on the Guest# icon, which opens a drop-down login widget (fig 7).  Currently the control panel is in the alpha stage.  The control panel itself is fully functional, but other functions, such as username and password, are not.  At this time, no password is necessary.  To login, the name parameter will simply be the pilot name from the Arxterra App (fig 3).

Fig 7. Control Panel Login

Successful login is verified by a marker on the map.  When the marker is selected (fig 8), the robot to be commandeered pops up.  Displaying the name of the robot to be controlled, the status of the robot as the user, and an icon which once selected teleports user to control panel.

 

Fig 8. Commandeering of robot

 

Taking command of the robot shows the GUI of the control panel (fig 9).  The control panel is capable of displaying several telemetry options. For SpiderBot, the video feed component is an important factor, as well as the movement control segment.  Arxterra is capable of more telemetry options such as phone readings, and any custom commands defined by user.  The Arxterra mission control panel could optimize SpiderBot’s aerial video feed by implementing a full screen mode. 

Fig 9.  Arxterra mission control panel

 

Conclusion:

The Arxterra phone applet and Arxterra mission control panel are seamlessly interfaced.  The ability to control a robot from one or the other is a nice feature to have.  In the case of the Spring 2017 SpiderBot, the requirements are to provide live streaming video for the end of semester games.  This is easily achieved using both the app and control panel.  The Arxterra control panel has the added features of multiple pilots capable of being onboard the robot, as well as a chat feature which will allow for trash talking amongst the robots during the game.

 

Resources:

  1. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/_3DoTTrainingDocumentation.pdf

 

 

 

 

Spring 2017 – ArxRobot Custom Commands Update!!

/in , /by

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

Spring 2017 SpiderBot Material Trade Off Study

/in , /by

Table of Contents

Material Trade of Study

By Daniel Matias – Manufacturing Engineer

 

Requirements:

A level 1 requirement states that SpiderBot shall lift itself off the ground. To achieve this, and still maintain a stable, mobile robotic platform, SpiderBot will be made of an inexpensive, lightweight material with a high tensile strength.

 

Introduction

Traditionally walking robots have proven to be a challenge. Proper walking mechanism selection can either means success or failure. Walking robots experience large amounts of shock and vibration that can cause stress fractures and material deformations. The study aims to present all materials considered for SpiderBot’s use.

Materials:

The materials considered in this trade-off are aluminum, acrylic, and plywood. A fixed volume of 1/8’’ thickness, 6’’ wide, and 12’’ long sheets are being used when comparing the materials. Also considered is the strength of the material to ensure our robot will not break under the weight of the components.

Calculations:

 

The following table shows the cost and mass of the set volume

Material

Cost

Mass

Aluminum

$17.14

398 g

Acrylic

$5.07

174.5 g

Plywood

$2.50

98.8 g

The following is a table of the tensile and compressive strength of the three materials.

Material Tensile Strength Compression Strength
Aluminum 310 MPa 20 GPa
Acrylic 69 MPa 124 MPa
Plywood 31 Mpa 36 MPa

Conclusion:

Although plywood is the cheapest and the lightest, acrylic is more suited for our robot due to the inexpensive, toy requirement. Aluminum could be reduced in size since it is stronger, but the material and machine shop costs would exceed our budget when all the qualities of acrylic can satisfy requirements.

Resources:

 

https://www.mcmaster.com/#acrylic-sheets/=16uqxrr

https://www.mcmaster.com/#standard-aluminum-sheets/=16uqxy0

http://www.woodworkerssource.com/shop/product/18balpack3.html

http://www2.glemco.com/pdf/NEW_MARTERIAL_LIST/Alumina%206061-T6.pdf

http://www.engineeringtoolbox.com/wood-density-d_40.html

https://www.metalsdepot.com/catalog_search.php?search=s318T6

http://edge.rit.edu/edge/P14418/public/4-Subsystems%20Design/Plywood%20Materials.pdf

http://www.builditsolar.com/References/Glazing/physicalpropertiesAcrylic.pdf

Spring 2017 SpiderBot – DC Motor Trade Off Study

/in , /by

Table of Contents

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:

 

Motor: Rated Voltage Speed @Rated Voltage Free-run Current   @Rated Voltage Stall Current @Rated Voltage Stall Torque @Rated Voltage Weight: Size  (mm)
Pololu 298:1 Micro Metal Gearmotor MP 6V 75 RPM 40 mA 700 mA 125 oz-in 10.5 g 10x12x26
SparkFun Micro Gearmotor 6V 45 RPM 30 mA 360 mA 40 oz-in 17 g 26x12x10
Solarbotics GM3 224:1 Gear Motor 90 deg. Output 3V-6V 46 RPM 50 mA 733 mA 57 oz-in 31 g 69.4×22.2×18.6
Hobby Motor 3V 6600 RPM 110 mA 800 mA Not Specified 26 g 27x27x33

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

Spring 2017 SpiderBot : Preliminary Project Plan

/in , /by

Nicholas Jacobs – Project Manager

Jeff Fuentes – Systems Engineer

Shaun Pasoz – Electronic and Control Engineer

Daniel Matias – Manufacturing Engineer

Table of Contents

Work Breakdown Structure

By Nicholas Jacobs – Project Manager

 

The following is SpiderBot’s Work Breakdown Structure. It gives a glimpse of the responsibilites of each team member as the semester progresses. This document will be updated weekly to reflect new and completed tasks.

 

 

 

Project Schedule

Top Level Schedule

By Nicholas Jacobs – Project Manager

The above chart describes high-level tasks that need to be completed. This breaks down tasks by engineer. As tasks arise they will be added and updated in follow on blog posts.

System/Subsystem Level Tasks

By Nicholas Jacobs – Project Manager

 

Above is a brief description of our system and subsystem level task. These will changes as the semester progresses.

Burn Down and Project Percent Completion

By Nicholas Jacobs – Project Manager

 

 

The above Burndown is a visual aid to represent reamaining tasks to complete SpiderBot. This Burndown will be updated weekly as tasks are completed.

System Resource Reports

By Jeff Fuetes – System Engineer

Power Allocation

Mass Allocation

Project Cost Estimate

 

The above chart reflects estimated cost of parts, CNC machine time, and material.  This is a chart that will change with the customer demands. Costs do not include shipping costs.

Spring 2017 SpiderBot: Preliminary Design Document

/in , /by
edit+xClone Element

Table of Contents

SpiderBot Team:

Project Manager – Nicholas Jacobs

Missions, Systems and Test Engieer – Jeff Funetes

Electronics and Control Engineer – Shaun Pasoz

Design and Manufacturing Engineer – Daniel Matias

 

 

Program Objectives

By Nicholas Jacobs – Project Manager

The Spring 2017 SpiderBot is the 2nd generation SpiderBot. The customer has requested that SpiderBot utilize a 3DOT microcontroller board with a custom SMD I2C board. The customer also specified that SpiderBot be controlled from the Arxterra App via a Bluetooth communication link or by the Arxterra’s web interface.  Lastly, the customer expects iterations of the engineering method, a neat and orderly cable tree, and an aesthetically appealing design.

 

Mission Profile

By Nicholas Jacobs – Project Manager

The Spring 2017 SpiderBot will be an 8-legged that is built upon the Terra Spider design concept. The SpiderBot will be validated to the customer during an end of the semester Pac-Man style game. SpiderBot’s role in the game is to provide live aerial video footage to enable participants to navigate a maze and reach a target square of the maze. Moving from outside the maze to the grappling launch point, then raising from the floor to an elevated position, and then providing a live video feed will demonstrate all SpiderBot’s design specifications stated in the Project Objectives.

 

Requirements

Program Level 1 Objectives:

By Project Manager Nicholas Jacobs

  1.  The SpiderBot project shall be completed by 10 May 2017. One week before Finals week (10 May 2017) http://web.csulb.edu/depts/enrollment/registration/final_exam/spring_chart.html
  1.  Total production cost must not exceed $250.00 US.
  2.  Spiderbot shall participate in the end of the semester Pac-Man style game. http://web.csulb.edu/~hill/ee400d/S’17%20Project%20Objectives%20and%20Mission%20Profile.pdf

Project Level 1 Requirements

By Project Manager Nicholas Jacobs

  1. SpiderBot will incorporate the 3Dot controller, SMD I2C boards.
  2. SpiderBot will be controlled by the Arxterra App using bluetooth.
  3. SpiderBot shall incorporate a smartphone or NTSC camera to provide real-time battlefield conditions to bi-ped and velociraptor remotely.
  4. SpiderBot should climb a wall by means of a rope/harness mechanism.
  5. SpiderBot shall be able to move forward, backwards and turn both left and right through use of DC motors.
  6. SpideBot shall compact size.
  7.  Will play in end of semester games
  8. Should provide video feed

Project Level 2 Requirements

By Mission, System, and Test Engineer Jeff Fuentes

  1. Spiderbot shall utilize the integrated 3.7v Li-ion battery to power the SpiderBot for 20 minutes.
    1. SpiderBor shall incorporate 2 seperate batteries to supply DC motors and servos and another 3DOT board, and motor driver.
  2. Spiderbot shall receive commands from the arxterra app via the HM-10 Bluetooth module on the the 3DoT board.
    1. SpiderBot shall establish a reliable comunication link up to 10 meters. 3DOT board will serve as the peripheal device and the smartphone will serve the central device. HM-10
  3. SpiderBot shall implement an Android smartphone or TTL Serial JPEG (capable of NTSC) camera to provide battlefield footage.
    1. NTSC camera will be an Adafruit NTSC Camera.
  4. Spiderbot shall utilize an Ultra-Micro Servo to drive the  rope/harness mechanism.
  5. Spiderbot shall utilize the TB6612FNG Dual DC Motor Driver to walk on 8 legs, through sets of 4, each driven by one motor.
  6. Spiderbot shall incorporate 3d printed parts that take no longer than two hours to print. 
    1. SpiderBot shall weight 3lbs or less. 

Design Innovation

Creative Solution

By Project Manager Nicholas Jacobs

From our Creative Design solutions, the SpiderBot team has decided to implement a unique idea into the Spring 2017 design. The end-user has specifed the need for a real-time video feed that will be provided to the control interface of two contending robots. SpiderBot will deliever an aerial view of the battle arena. The idea for an aerial view was the product of our Duncker Diagram which presented the issue of how our SpiderBot will climb a wall. Intially a suction cup system was proposed to adhere the SpiderBot to the wall. During the Attributes Listing design appraoch and after further consideration of the suction cup approach, the decision was made to scrap the suction cup idea. Our unique idea to provide the aerial video feed is to implement a grappling hook that would shoot and secure onto an anchor that will support the weight of SpiderBot allowing it to retract itself into an elevated position in order to provide aerial coverage.

 

Systems/Subsystem Design

 

Product Breakdown Structure

 

Electronic System Design

By Electronic and Control Engineer Shaun Pasoz

Last semester’s SpiderBot ran into several areas of difficulty; the worst of which was dynamic walking. They used servo motors to control the actions of the robot. While servos are excellent devices as they provide feedback from the motor, their pitfall is they cannot sustain a large amount of weight.  Therefore, this semester we have been tasked to implement a SpiderBot featuring DC motors.

Since the 3DoT board can only supply a current of 450mA, it is highly probably that we will need to implement an external power supply. In order to get the greatest motor efficiency, the first step is to decide on what configuration we would like to choose for our power supply. The following table shows a simple trade-off study between different batteries.

Battery: Weight: Rated Voltage: Capacity: Cost: Size: Discharge:
Ultrafire 18350 1200mAh 3.7V Unprotected Lithium Ion (Li-ion) Button Top Battery 20.9g 3.7V 1200mAh 4.95 35×18.5 mm N/A
6V Tenergy 1600mAh NiMH Side by Side Battery Pack with Hitec Connector 130g 6V 1600mAh 10.99 84x17x30.  mm 10C (10.6A Calculated)
Efest 18650 3000mAh Flat Top Battery – Purple Series 46g 3.7V 3000mAh 8 18.23×65.02mm 20A Continuous

System Block Diagram

By Mission, System, and Test Engineer Jeff Fuentes

The system block diagram displays how Spiderbot’s proposed inputs and outputs will function.  The 3DoT board can supply its own power, but it is not enough for all the peripherals we will be using.  Communication and telemetry will be handled by the 3DoT board consisting of the HM-10 Bluetooth LE module, an android phone, and the Arxterra app.  The motor outputs on the 3DOT board will drive two DC motors which will supply mechanical engery to a set of four legs each.  As dictated by the mission objective, Spiderbot will make use of a camera and harness/grappling mechanism via servo control. An external PCB will allow for further function if the 3DoT board cannot fully deliver.

3DoT Board Schematic

  1. http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/3DoT/3DoT%20Datasheets/Block%20Diagram.pdf
  2. https://www.arxterra.com/3dot/

Fritzing Diagram

Mechanical Design

By Maunfacturing Engineer Daniel Matias

Our spiderbot will be based off the terrabot model and be built using 3D printed ABS plastic parts for our first rapid prototype. I will design the parts myself using solid works to have them 3D printer ready.

The body of the spiderbot will be large enough to house the 3Dot Board and two motors with gears to run the Theo Jansen walking mechanism for the legs.

Design and Unique Task Description

By Mission, System, and Test Engineer Jeff Fuentes

 

Nicholas Jacobs

  1. Research prospective sources for material/services

 

Jefferson Fuentes (Missions, Systems, and Test Engineer)

  1. Design potential schematic to begin fritzing diagrams
  2. Work in conjunction with E&C (P, Shaun) to analyze power requirements needed for motors and peripherals
  3. Begin decoding and designing Arxterra app.
  4. Conduct trade off studies concerning DC Motors alongside E&C
  5. Conduct trade off studies concerning our harness/grappling mechanism

 

Shaun Pasoz (Electronics & Control Engineer)

  1. Consult fellow Electronics and Control engineers to discuss parameters to implement a game to demonstrate 3DoT Board capabilities.
  2. Examine trade-off studies for various batteries and motors.
  3. Work on simulations for motor control through the Arduino Uno board to help limit decisions between motor choices.
  4. After choosing motor, stress tests on motor gear systems need to be conducted to detail the max current draw based on the weight of the robot.
  5. After deciding on proper motors, batteries, and control systems, conduct tests to analyze how long the battery can run on a single charge.
  6. Create a Fritzing diagram using parts from interface matrix
  7. After finalizing electronic layout, create a PCB layout using CAD software.
  8. Consult Systems Engineer to develop software subroutines to make the SpiderBot perform its tasks.

Daniel Matias (Manufacturing Engineer)

  1. Conduct trade-off study to determine which material will best suit our needs
  2. Begin designing and implementing 3D models to be potentially built
  3. Begin preliminary EagleCAD files to gain an idea of layout

 

Resources:

http://arxterra.com/preliminary-design-document-4/#h.pit64qv19iz

http://web.csulb.edu/~hill/ee400d/Documentation%20Lecture%20Series/04%20Preliminary%20Design%20Document.pdf

http://web.csulb.edu/~hill/ee400d/Lectures/Week%2004%20Modeling/c_Design%20Process%20and%20Modeling.pptx