A Buck converter is a DC-to-DC power converter which steps down voltage (while stepping up current) from its input to its output. Switching converters such as buck converters provide much greater power efficiency as DC-to-DC converters than linear regulators, which are simpler circuits that lower voltages by dissipating power as heat, but do not step up output current. That is why we considered to use it to step down the output of our main battery to a voltage that can work for our Arduino board. The efficiency of the buck converter is extremely high reach 90% efficiency and higher in some cases. However from my experience with the buck converter the efficiency of the buck converter seems to decrease as the difference between the input and output increases. Fortunately, for the purposes of our build we are stepping from 12v volts to 9v, which puts us at 91% efficiency. The efficiency testing the power of the input vs the power of the output under different step down ratios. The input voltage is 12v, different output voltages that were tested. Starting from 1v to 12v, and each step I measured the power of the input and the power of the output and from there I was able to calculate the efficiency of the buck converter at different step down ratios.
Figure 1: Plot of Buck Converter Efficiency at Various Step-Down Ratios
By: Eduardo De La Cruz (Project Manager & Manufacturing), Raymundo Lopez-Santiago(Mission, Systems, Test), Kris Osuna (Electronics & Controls)
Verified by: Eduardo De La Cruz (Project Manager & Manufacturing Engineer)
Approved by: Miguel Garcia (Quality Assurance)
Table of Contents
Mission Objective
Design and fabricate a remote controlled, competitively priced, toy robot that is capable of memorizing and traversing a path.
The child “teaches” his/her robot by guiding it through a maze. Once the child and robot team solve the maze. The child returns the robot to the entrance of the maze and quizzes the robot to see if it has learned the maze.
Additional robots may be introduced into the maze while the robot is moving through the maze. The robot should avoid collisions with the other robots.
Parents and friends may remotely view the progress of their child’s robot.
Our game testers will be given the robots on the day of the final. The test room is ECS 316. The maze will be located in the front of the room (about 8 ft x 18 ft).
Level 1 & Level 2 Requirements
By: Raymundo Lopez-Santiago
Requirements follow the following numbering conventions:
C-xx is used for all common requirements for all projects under The Robot Company.
L1:xx is used for all Level 1 requirements specific to 3DoT Hexy.
L2:xx is used for all Level 2 System and Subsystem requirements specific to 3DoT Hexy.
3DoT Hexy requirements will be updated as the project is further completed.
Level 1 Requirements
Program Requirements
C-01:
In accordance with the Spring 2018 final schedule, the project shall be completed by May 8th, 2018 and shall be prepared for a demonstration on the linoleum floor of ECS 316 on May 15th between the hours of 10:15 am – 12:15 pm.
C-02:
Documentation for the project shall be completed a week prior to the day of demonstration (May 8, 2018).
C-03:
The robot will be designed to be a toy for people ages 8+.
C-04:
In order to minimize manufacturing cost, and packaging cost the robot shall be able to be constructed from subassemblies within 10 minutes.
C-05:
The robot will be remotely controlled wirelessly via bluetooth using the ArxRobot Android or iPhone application.
C-06:
The robot will need to navigate remotely through a custom-built maze (built by AoSa image), memorize the path it took, start over, and autonomously travel through the path it took.
C-07:
Video support during autonomous navigation will be provided via the Arxterra control panel, as well as a live VR feed.
C-08:
The robot shall avoid collisions if it encounters other robots while navigating through the maze. This involves detecting the robot, retracing steps back, and moving to a room that allows the other robot to have a safe passage.
C-09:
For quick production of the prototype, the preliminary project shall be restricted to six hours of total printing time with a 2 hours limit for each single print.
C-10:
The robot shall use a v6.16 3DoT board.
C-11:
The robot shall demonstrate the capabilities of the 3DoT micro-controller for DIY hobbyists.
C-12:
The robot shall be designed in such a way that there are no dangling or exposed wires and the final fabrication is pleasing to the customer.
C-13:
The robot shall incorporate 3D printed parts to demonstrate the feasibility of the 3DoT board for 3D printed robots.
Project Requirements
L1-1:
The robot shall use sensors to: detect robots disrupting their path, for intersection detection, and for either line following or hedge following.
L1-2:
The robot shall use the same maze to compete in a game of who gets out first. (Defined by both 400-D sections)
L1-3:
To keep cost down, and keep as a toy aspect, the robot shall use only 2 micro motors to drive the movement of the robot.
L1-4:
Spiderbot shall have an allocated budget of $250, however to compete with the existing robot toy market we shall try to minimize the cost of production as much as possible.
L1-5
Spiderbot shall have custom SMD I2C shield as platform to build from and will incorporate peripherals for sensors and motors.
L1-6:
Spiderbot’s dimension shall have a chassis large enough to house a 3×7 cm 3DoT board.
Level 2 Requirements
System Requirements
L2-1:
Communication to the robot will be through the HM-11 bluetooth module.
L2-2:
The robot shall use a single RCR123A 3.7 V, 650mA rechargeable Li-ion battery to power the 3DoT board, which will power the drivetrain and all attached peripherals.
L2-3:
The robot shall use 3 UV sensors connected to a custom PCB.
L2-4:
The robot shall use a HC-SR04 ultrasonic sensor to handle robot avoidance.
L2-5:
The robot shall use 3D printed chassis and legs. This follows from the project level requirement about using 3D printed parts.
L2-6:
The robot will use a cam system identical to that of 3DoT David to drive the movement of the legs while navigating through the maze.
L2-7:
The robot shall use 2 micro guard motors to drive the motion of the robot.
L2-8:
The robot shall use one RGB color sensors to handle intersection detection.
L2:9
The robot shall incorporate 6 legs in the design of the drivetrain to improve stability while moving, to support its own weight and to mimic the behavior of a spider.
L2-10
The Arxterra control panel shall display the current battery level, as well as all sensor data.
Sub-System Requirements
L2-4a:
Ultrasonic sensor shall have a range of 0.5-meter radius to detect and respond accordingly to other robots.
L2-5a:
The robot shall use PLA or ABS filament in the fabrication of the chassis and legs. This will minimize the mass of the robot, while at the same time being strong enough to hold its weight.
L2-6a:
Gears shall have a gear capture system to prevent them from popping (main issue encountered in 3DoT David design). This ensures the cam system will work without fear of popping gears.
L2-9a:
The robot shall operate in a tripod form, having three legs (2 outer in one side and middle leg in the other side) to provide stability while moving.
The system block diagram mimics the interface matrix developed for 3DoT Hexy. The 3DoT Hexy system block diagram below shows the different parts of the robot and how they interact with each other. A total of 9 pins out of the 16 pins available from the 3DoT board will be used for the custom PCB’s. The two custom PCB’s will be designed and built to add an I2C expander which will connect to all sensors, also a boost converter to provide 5V to the motor driver. 3DoT Hexy will be powered from a single 3.6V RCR123A battery. Communication for mobile operation of 3DoT Hexy will be done using the HM-11 bluetooth module. Any changes will be added as needed.
Figure 1: System Block Diagram
Work Breakdown Structure
By Eduardo De La Cruz
Figure 2: Work Break Down Structure, generated using yEd Graph Editor
Product Breakdown Structure
By: Raymundo Lopez-Santiago
The product breakdown structure outlines the major systems of the robot. The 3DoT Hexy Product Breakdown Structure (PBS) below shows the different components (subsystems) of each part of the overall robot.3DoT Hexy is split into five sections (Movement, Software, Sensors, Chassis, Power) for the PBS. Anything related to the movement system which includes motors, joints, gears, and legs are the main parts for mobility of 3DoT Hexy. Communication via Bluetooth from a smartphone and the Arxterra app allow for wireless control of 3DoT Hexy. Sensors such as the color and UV sensors will aid in detecting corners and for the case of the ultrasonic sensor, it will aid in detecting robots. The chassis will be 3D printed in either PLA/ABS plastic. 3DoT Hexy and its peripherals will be powered by a single 3.6V RCR123A battery. Any changes will be added as needed.
Figure 3: Product Break Down Structure
Interface Matrix
By: Raymundo Lopez-Santiago
Three separate interface matrices are created in a table format to show how the available pins for specific systems are going to be allocated in the design. This document helps show how things should be connected together using the corresponding pin names that are provided from the data sheets. For this project, we break up systems into 3 interface matrices which are the 3DoT interface, the Custom Sensor PCB and the Custom Boost PCB. The 3DoT interface matrix shows the pins allocated from the 3DoT board and how they connect to the two custom PCB’s. The Custom sensor PCB interface matrix shows connections used to connect the I2C expander (TCA9548A), Ultrasonic sensor (HC-SR04), and UV sensors (Si1145) to the 3DoT board interface. The Custom Boost PCB interface matrix shows connections used to connect the Boost converter ( TPS61253AYFFT) to the 3DoT board Interface. Since project Biped will be using similar PCB designs, we have decided to split the work and have our team work on the Custom Boost PCB design while the Biped team will work on the Custom Sensor PCB design.
Figure 4: Interface Matrix
Fritzing Diagram
By Kris Osuna
We will have three UV sensors. One sensor follows the line when another sensor is triggered 3DoT Hexy will know that the course has been disrupted and needs to readjust. We are using three UV sensors which requires three separate SDA/SCL pins, because of this we have an I2C expander. We will have two UV LEDs illuminating the front of 3DoT Hexy so the UV marker is detected. We use the ultrasonic sensor to find if other devices are in the way and if 3DoT Hexy needs to react. A dual motor drive is needed to drive both sides of 3DoT Hexy.
Having had decided to go with a cam system design similar to that of Spring 2016’s 3DoT David, we decided to get in contact with the owner of 3DoT David, and ask for permission to borrow the model for use as a reference, we went on to solve design flaws in 3DoT David’s mechanical design, came up with solutions, and rendered our own design fixing these bugs. Below are mechanical sketches of our design followed by brief explanations of why things look the way they are. If interested in more detailed explanation for design changes made based on the 3DoT David model, please read the blog post “Spring 2018 3DoT Hexy: Improving 3DoT David Design”. If interested in more details about how the mechanism works please see “Spring 2018 3DoT Hexy: Decision on Movement Mechanism”, and “Spring 2018 3DoT Hexy: Determining Gear Design” .
3DoT Hexy Mk-1:
Figure 6: Exploded View of 3DoT Hexy Mk-01
An exploded view of our spider can be seen above. In all, we will have: 6 legs, 6 femurs, top and bottom plate, washers, x6 30T gears, x8 10T gears, and gear caps (to prevent popping).
Below are sketches of our design modeled using solidworks. All measurements are in mm.
Bottom Panel:
Figure 7: Bottom Panel Dimensions
For the bottom panel, femur lifting guides will be integrated into the chassis instead of having them stick out like in 3DoT David’s design. This is done to reduce the overall width of the robot. Ten shafts with 4mm diameter will be located at 21.125mm from the center axis. We will extrude cut patterns to reduce 3D print times while at the same time giving our design a unique and appealing view to distinguish it from 3DoT David. The guides for the femurs will be angled. This is done in order to provide a smooth transition from ground to peak heights during the legs extension. For the holes found along the center axis: big holes will be used to run wires from top to bottom panel, and smaller holes will be used for driving motor connections. The design will have more holes upon determination of the position of the custom PCB board, battery, and 3DoT board.
Top Plate:
Figure 8: Top Panel Dimensions
Top view will be flat and showing only the extrusions. The circles along the center axis will be: small holes, gear captures to keep the driving gears from popping and bigger hole will be a round tube extruding from top panel and that will connect to the bottom panel. Providing an isolated passage for wires from top panel to bottom panel without obstructing cam system. We will extrude cut patterns to reduce 3D print times while at the same time giving our design a unique and appealing view to distinguish it from 3DoT David. The design will have more holes upon determination of the position of the custom PCB board, battery, and 3DoT board.
Femurs:
Femurs will be re-designed based on 3DoT David’s design review to incorporate more contact points for femur and tibia joint. Like 3DoT David, the back, middle, and front femurs will have a unique design. The reason for doing this is to provide clearance for when we put the screw mounts in each corner.
The three type of femurs:
Figure 9: Three Types of femurs
Figure 10: Middle femur dimensions
Note: The back leg will have the same measurements with extrude-cut on opposite side.
Figure 11: Femur Dimensions
We decided that integrating the lift mechanism into the femurs of the legs would give us more control over the lift angle (since it will be based on the angle of the contour we define), as well as reduces the width of the robot since we will eliminate the need of the protruding lift mechanism. As an added extra, we also expect to see reduced 3D print times for the femurs.
Our solution involves re-designing the femurs and the base to have a guide that will increment the angle of the femur as the femur rotates outward, providing lift. How it works:
Figure 12: Relation between femur and gear during gear rotation
At point A the femur should be touching the floor and preparing for thrust. At point B, the femur begins ascending. At point C the femur is at its peak lift. At point D, femur is descending.This solution enables us to control the lift of the legs based on the angles of the femurs; eliminating the need of the protruding mechanism from 3DoT David. The guide that the femurs will follow will also have an angle to provide a smooth transition from point A to point C. More details of how this works can be found in “Spring 2018 3DoT Hexy: Improving 3DoT David Design”.
Tibias:
The tibias will have a new joint redesign in order to increase femur-to-tibia contacts for joint strength. Previous design only had a single contact point and was susceptible to loosening.
New design will have 5 contact points.
Figure 13: Tibia Dimensions
The legs will be wider than those of 3DoT David due to the increase width needed to increase contact point of femur-to-tibia joint. The result we can expect from this is increased 3D print times due to larger surface area of tibias. To try to fix this issue we trimmed the width of the tibias by 2mm (from 6mm to 4mm) and decided to shell/hollow out the tibias and cut out excess material by making the opening right down the middle. The legs have a 2mm holes that will align with the 2mm hole of the femur. Thread will be created through this joint and a screw will be placed through femur-to-tibia joint to prevent them from moving.
Additional Components we will use in our design will be:
This section provides all of the information for the three major resources that are being tracked which are Power, Mass, and Cost. Values obtained for 3DoT Hexy are estimates based on previous research. At this moment, not all measurements/testing for all sensors are finished. For the Battery and 3DoT values (mass, power) were estimated based on the final blog post of 3DoT David. For the 3DoT Hexy design, we are building of the design of 3DoT David and further making improvements. After testing several weight values on top on 3DoT David, we determined the total project allocation mass for 3DoT Hexy should be 500g to still be able to move. For the project power allocation, it was determined to be 1.1A from the 3.6V RCR123A battery. Values will be updated as project is progressed.
The schedule we will use will practically mirror the the time frames and due dates priorly established in the task matrix. The goal is to provide a visual reference of how far or close one is from reaching their deadlines for a given task.
Figure 15: Project Planner generated using EXCEL Project Planner
Dark purple represents our progress, light purple represents what needs to be done. If we exceed the due date the bar will turn orange. Orange lets us know how many days it was late after the due date due to time extension request. Task for each division are color coded and their is a legend at the top explaining each color.
Note: Division members may take on task from other divisions if they see that they have the time available in their existing schedules to aid other divisions in getting their task done.
A link to our task matrix and project schedule generated can be found below:
The graph shows how task will be distributed over the course of the semester. The goal is to finish all task before execution of the mission.
Figure 16: Project Burndown
Blue = Current Progress, Orange = Desired Progress
As off week 8, we have completed about half of the task defined in the task matrix. So far, we have submitted most if not all preliminary task documentations, and a few trade studies done by each division engineer showing their progress. For more details on what is due each week based on the above burndown read, “Spring 2018 3DoT Hexy: Project Planning and Scheduling”.
Summary of experiments done/Rapid Prototyping Completed
https://www.arxterra.com/wp-content/uploads/2018/03/image1.jpg144144Eduardo De La Cruz/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngEduardo De La Cruz2018-04-26 16:46:452023-07-27 07:57:13Spring 2018 3DoT Hexy: Preliminary Design Review
By: Samuel K Yoo (Electronics & Control – Software)
Verified By: Intiser Kabit (Project Manager)
Approved By: Miguel Garcia (Quality Assurance)
Table of Contents
Introduction
The objective is to focus on the different methods of turning for the robot. The first method is timing turning which tells the robot to turn for a certain amount of time. The other is an infinite state machine which uses the outer sensors to tell the bot which state it is in. This turning sequence used for the robot has wheels, which the AT-ST does not. The concept of turning can be used for the AT-ST.
Code
CHANGE CODE TO <code> type
Figure 1: Screenshot of code
Figure 2: Continuation of Screenshots of code
Figure 3: Last part of code screenshot
Explanation
The code, in the beginning, initializes certain variables and sets them as inputs and outputs. After this the code contains a line follower code which makes the robot follow the line. There are then the subroutines for the time turning. The subroutine near the end of the code allows the bot to make a left, right and turn around. Time turning is a method of spinning the wheels in the same rotation until it points in another direction. Each turn must be tested to find the desired direction. The values in the code are placeholders until real values are obtained. This code however only works with motors, not servos and needs to be updated at a later date. The finite state machine code is not in the list above, however, I can explain the logic and some pseudocode.
The logic behind the finite state machine is to switch from one state to another state. These states will tell the robot it needs to continue, turn, or not until it reaches another state. If all sensors read black, it is at an intersection and will either start turning left right. Next, it would jump to the next state and see if the sensors outer sensor read the white part of the maze if so it would continue to turn until it sees all black. After that, it would proceed to move forward.
Conclusion
This whole entire blog post is to make the turning code. The time turning is in the code, however, it does not suit the AT-ST because of the difference in components. The finite state machine is not implemented yet. This post will require further updates for both the inclusion of the state machine turning and the servos.
By: Kris Osuna (Electronics & Control Engineer) & Raymundo Lopez-Santiago (Mission, System, and Test)
Verified by: Eduardo De La Cruz (Project Manager & Manufacturing Engineer)
Approved by: Miguel Garcia (Quality Assurance)
Table of Contents
Introduction
This blog post covers two test cases conducted with two different sets of motors. The first set of two unidentifiable model number DC motors were obtained from Professor Hill’s resource cabinets. The second set of motors include two DFRobot FIT0481 micro metal gear motors to be used for our 3DoT Hexy project. For both test cases, current and voltage measurements were obtained using an Arduino Uno and a INA3221 Breakout Board. The current measurements is our power test since we are planning to add up all currents to make sure we do not exceed the 650 mAh battery (1300 mA) allowed from the project. Tests also involved using the EE370L Parallax board to measure RPM of the motors at various voltages. Measurements were taken with a load that is half the weight of 3DoT David (66.3g) and the gears in motion. Apart from conducting test with both sets of motors, an additional test with 3DoT David’s motors (Micro Gearmotor – 900 RPM (6-12V))) was performed. Tests conducted include a no load and mock up under load test. Under the no-load test, the motor spun with no gears attached. Under the load conditions, the motor spun with gears in place and legs attached (half of 3DoT David’s gear system).
Components Needed
Scale
3DoT David
4 micro metal gear motors
INA3221 breakout board
Arduino Uno
Opto-Reflective switch
2 NPN transistors
Resistors: 100Ω, 200Ω, 1kΩ
Process Control Student Guide by Parallax INC
Information on motor tested from 3DoT David’s drive train system: Link
Information on motor purchased for 3Dot Hexy: Link
No datasheet is available for motors obtained from Professor Hill’s resource cabinets.
Related Requirements
The micro metal motor must be able to turn six gears
The motor must be able to work in the 3.6-5V range
The motor must have an RPM of at least 360 with a 66.3g load
Test
The tests involved using the EE370L Parallax board to measure RPM of the motors at various voltages. Activity 6 in the Lab manual (EE370L_Manual) was replicated but instead of a fan, the motor above was used. A half black/half white circle was used for the RPM test (See Fig.2).
A riser was placed on the scale and tared so that we can weigh 3DoT David shown in Fig. 1. 3DoT David weighs a total of 132.6 grams. There are two micro metal motors used so each motor will have a load of 66.3 g. The original motor from the 3DoT David project was removed. The motors were connected to the INA3221 breakout board to measure current with no load. Set up can be seen in Fig. 2. RPM was calculated by using the opto-reflective switch to read the black marked paper on the sheet attached to the motor as the motor spins. The opto-reflective switch has an IR LED and phototransistor which is able to differentiate the black and white part of the paper. Each count means a full rotation was achieved. The motor shaft was marked black and recorded for 10 seconds then played in slow motion to confirm that the opto-reflective switch readings were correct. This test was done to also both sets of motors.
The two sets of motors being tested were replaced inside the 3DoT David gear system. This is done so that the gears moving would be part of the load (See Fig.4). The motors are connected to the INA3221 breakout board to measure the current while dealing with the load. RPM was calculated by using the opto-reflective switch to read the black on the sheet taped to the gear attached to the motor (See Fig. 3). The gear attached to the motor was marked, recorded for 10 seconds and watched in slow motion to confirm the opto-reflective results were accurate. Below are tables with results obtained with each motor at no load and with a load which includes half of 3DoT David’s gear system. Half of 3DoT David’s gear system consists of (3) 30:1 gear ratio gears and (2) 10:1 gear ratio gears. Graphical representation of all measurement results is shown in Fig. 5, 6, and 7.
Figure 1: Measuring 3DoT David’s Weight
Fig. 2: RPM test with no load
Fig. 3: RPM test with load
Fig. 4: Voltage and current measurements with load (half of 3DoT David’s gear system)
Results
Table 1: Measurements of cabinet motors at 3.7 V
Table 2: Measurement of cabinet motors at 5 V
Table 3: Table showing measurements with load and no load from 3 to 5 volts for motors from 3DoT David. (No stall exists with no load. Stall exist with load at 2.3 V)
Table 4: Measurements of our purchased motors (FIT0481) (voltage in Volts, current in (mA))
When a load is attached to a motor, it is expected to see a rise in the current draw since the motor works harder and furthermore increases torque and inversely has less rotational speed. This is what the measurement results show from Fig. 6. We can conclude that since the motor stalls at 2.3V with load, we need to drive the motor at a higher voltage. Based on the results at 5V with load, we get a significant motor speed with a reasonable current draw.
Fig. 5: Graphical representation of motor with no load at voltages between 3 to 5 volts for motors from 3DoT David.
Fig. 6: Graphical representation of motor with load at voltages between 3 to 5 volts for motors from 3DoT David.
The following graph is for table 4 which uses the purchased micro metal motors that will be used on 3DoT Hexy.
Fig 7.: Graphical representation from our purchased motors (FIT0481)
Conclusion
Factors for choosing the best-brushed motor for 3DoT Hexy included cost, size, voltage rating, and speed-torque relationship. Based on tests performed and since we are using a similar gear system from 3DoT David, it was concluded that a motor rated at 6V at no load speed of 530 RPM ( Link) will provide enough torque to drive the 3DoT Hexy’s gear system and legs. We will be using this motor at 5V and expect to have enough torque and rpm with the load. The purchased motors stall at around 3.4 V with a load, because of this it means that we can use can use the 3.7V to our motors provided by the 3DoT board. We are waiting for 3DoT Hexy to be 3D-printed to decide whether we will need 3.7V or 5V power to our motors. Once we find the full weight of 3DoT Hexy with all the sensors attached we should run another power study. The new power study will be more realistic because 3DoT Hexy will be moving and have all the sensors workings. If 3DoT Hexy can take the full load without the motors stalling at 3.7V we would only need one buck booster for the UV LEDs.
Resources
Figure 8: Micro Metal motors obtained from resource cabinets
https://www.arxterra.com/wp-content/uploads/2018/04/rsz_13.png144144Eduardo De La Cruz/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngEduardo De La Cruz2018-04-20 05:55:382023-07-27 07:57:13Spring 2018 3DoT Hexy: Mock-Up Motor Power Under Load and Power Estimate of Micro Metal Motors
The robot that is to be designed shall be done in such a way that it is relatively inexpensive, less than $250, preferably a laser cut model or 3D printable design.
Since robots are to be operating through the maze simultaneously, the design should ensure that collisions are to be avoided in all situations.
When printing 3D models for the project, any prototype print shall obey the 2/2/2 rule and shall take no more than 6 hours in sum. Projects may request a waiver with justification.
Robots shall utilize a version 6 3DoT boards powered by the 3.7V RCR123A battery. Projects may request a waiver with justification.
The robot will be designed in such a way that there are no dangling or exposed wires. Connectors will be used between all electronic and electromechanical components. Jumper wires will not be used, ribbon cables are preferred; the gauge of wires should be consistent with the current.
Good construction techniques: all moving and rotating parts shall use bushing or bearings, hinges shall be interlocking and include a latching mechanism. No gaps shall be greater than 1 millimeter, immediate access shall be provided to all external connectors (USB, switches).
The robot shall record the user’s input and be able to repeat the previous route defined by the user. The software algorithm is defined in 400D E&C lab sequence.
During teaching mode, ArxRobot app via mobile devices shall be used to teach the robot to navigate the maze.
During the playback mode, the ArxRobot app shall transmit live video feed and telemetry to the Arxterra control panel, including battery level.
The Robot disassembly time shall be 10 minutes. Projects may request a waiver with justification. All 3Dot boards will be clear of electronics, motors will be disconnected, all sensors will be disconnected.
Reassembly time shall be 10 minutes. Projects may request a waiver with justification. All teams will be allowed to use a cable tree as well as an assembly diagram as necessary. All robots will be tested after reassembly to confirm its functionality.
Goliath Level 1 Requirements
Project:
L1 – 1 The Goliath will drive on flat surfaces, such as cloth, paper, linoleum.
L1 – 2 The Goliath shall be operational for 1-hour duration.
L1 – 3 The robot shall be a scale replica of a Goliath 302 Tank. The scale factor will be 1:11.5 with a mean
square error (MSD) over all three axis (x, y, z) of no greater than 10%.
L1 – 4 The total cost of the goliath shall be no greater than $200.
L1 – 5 The Goliath shall have easy access to charging and programming hookup.
L1 – 6 Goliath shall house a custom PCB and use control telemetry shall to navigate the maze.
Program:
L1 – 7 The Goliath should make tank noises.
L1 – 8 Goliath shall detect and avoid other robots in the maze.
Goliath Level 2 Requirements
System:
L2 – 1 The mass of the Goliath shall not exceed 400 grams. Goliath L1-3
L2 – 2 The Goliath shall be smaller than 5x4x3 inches. Goliath L1-3
L2 – 3 Goliath shall use IR range finder to detect objects. Goliath L1-7
L2 – 4 Goliath’s final version shall be printed with ABS plastic. General 3
L2 – 5 The Goliath shall be power by a single 3.7v RCR123A battery. General 6
Subsystem:
L2 – 6 Main PCB shall have two UV sensors, UV LED, Gyro, and connectors to range-finder. Goliath L1-6
L2 – 7 Arx-robot App will have different operating control modes and direction pad to control Goliath’s
movement. Goliath L1-6
L2 – 8 Goliath shall have 4 x 10 mm cut out on back of Goliath to provide access to charging and
programming hookup. Goliath L1-5
L2 – 9 The Goliath will not have any electrical parts mounted outside. General Level 1-7
L2 – 10 The Goliath should have a latched lid. Interlocking mechanism. General Level 1-8
L2 – 11 The Goliath shall detect objects 10 inches in front. Goliath L1-8
L2 – 12 Goliath will have all-terrain tracks. Goliath L1-1
L2 – 13 The Goliath shall have 10 gears. Goliath L1-1
L2 – 14 The Goliath shall have 2 motor(s), located in the back of the chassis. Goliath L1-1
By: Jorge Hernandez (Electronics & Control Engineer)
Verified By: Miguel Gonzalez (Project Manager)
Approved By: Miguel Garcia (Quality Assurance)
Table of Contents
Power Estimates
For power estimates I calculated power and current on two types of servos; the Tower Pro SG90 and metal geared MG90s. To read the power and current from the servos on different loads, I used the INA219 current sensor. A 3-D pully was made and connected on top of the servos as Professor Hill suggested.
Fig.1 Testing Environment
Coding
I combined the Sweep Arduino code with an Arduino code to read the current and power from the INA219 current sensor. I used a function ‘read values’ to act as the INA219 sensor and embedded it within the for loop which had the servo turn back and forth 180 degrees which are known as the sweep code for servos. Here it will read the values every 5 degrees to get an accurate reading.
/* Sweep by BARRAGAN <http://barraganstudio.com> This example code is in the public domain. modified 8 Nov 2013 by Scott Fitzgerald http://www.arduino.cc/en/Tutorial/Sweep*/#include <Servo.h>#include <Wire.h>#include <Adafruit_INA219.h> // You will need to download this libraryAdafruit_INA219 sensor219; // Declare and instance of INA219Servo myservo; // create servo object to control a servo// twelve servo objects can be created on most boardsint pos = 0; // variable to store the servo positionvoid setup() { myservo.attach(9); // attaches the servo on pin 9 to the servo object Serial.begin(9600); sensor219.begin();}void ReadValues (){ float busVoltage = 0; float current = 0; // Measure in milli amps float power = 0; busVoltage = sensor219.getBusVoltage_V(); current = sensor219.getCurrent_mA(); power = busVoltage * (current/1000); // Calculate the Power// Serial.print("Bus Voltage: "); // Serial.print(busVoltage); // Serial.println(" V"); Serial.print("Current: "); Serial.print(current); Serial.println(" mA"); Serial.print("Power: "); Serial.print(power); Serial.println(" W"); Serial.println(""); }void loop() { for (pos = 0; pos <= 180; pos += 1) { // goes from 0 degrees to 180 degrees // in steps of 1 degree if (pos%10==0) { ReadValues (); } myservo.write(pos); // tell servo to go to position in variable 'pos' delay(15); // waits 15ms for the servo to reach the position } for (pos = 180; pos >= 0; pos -= 1) { // goes from 180 degrees to 0 degrees if (pos%10==0) { ReadValues (); } myservo.write(pos); // tell servo to go to position in variable 'pos' delay(15); // waits 15ms for the servo to reach the position }}
Results
Table 1: SG90(plastic Micro-servo) @ 3.3 V
Table 2: MG90 (metal Micro-servo) @ 3.3 V
Table 3: SG90(plastic Micro-servo) @ 5V
Table 4: MG90(metal Micro-servo) @ 5 V
Conclusion
SG90 Plastic Geared will be used for Micro Fobo as it satisfies more requirements than the MG90 metal geared micro servo. The SG90 also pulls less current at different loads. Both micro servos operate at 3.3V (L2-7: Micro FOBO shall use a battery that outputs 3.7V) but as can be seen, the MG90 stalls with a load of 200 grams. Satisfies customer requirement as it is toy based and will have a cleaner look as they are small and fit well on the chassis.
By: Jeffrey De La Cruz (Mission, Systems, and Test Engineer)
Verified By: Miguel Gonzalez (Project Manager)
Approved by: Miguel Garcia (Quality Assurance)
Fig.1 Interface Matrix
The current interface matrix for the prototype Micro FOBO uses the Arduino UNO. A CD4017BE IC was used in order to control the eight servos. The output of the CD4017BE IC was then connected to the Arduino UNO which will the Robot Poser control the movement of the servos so that the Micro FOBO can walk. The interface matrix will be updated once the 3DoT board or the Sparkfun Pro Micro 3.3V/MHz is acquired. This is currently for the prototype of the Micro FOBO.
The excel file containing the interface matrix for the prototype Micro FOBO can be found
By: Jorge Hernandez (Electronics & Control Engineer)
Verified By: Miguel Gonzalez (Project Manager)
Approved by: Miguel Garcia (Quality Assurance)
New and improved System Block Diagram for Micro Fobo which shows in a general diagram how many pins will be needed for each component and how they connect to each other. As seen we are using a total of 5 sensors, a custom PCB, Bluetooth module, external battery and of course a Pro Micro. This helps a lot for our E&C engineer when it comes to PCB designing as they need to plan accordingly.
Fig.1 Micro FOBO System Block Diagram
Wiring Management
No Exposed Wires;
Wiring for sensors, Pro Micro, and PCB will not be exposed and will all be within the head of Micro Fobo.
Exposed Wires:
1/8 Inch PET Expandable Braided Sleeving with quarter inch heat shrink tubing will be used on the wires that connect the micro servos to the header
Used to cover the wires of the SG90 micro servo
Ensures complete coverage and protection of wires
Clean design
The cables for the servos are routed out of the head encasement and directly to the servos through the back of Micro Fobo. Below is a photo of how clean Micro Fobo will look.
https://www.arxterra.com/wp-content/uploads/2018/04/858717-256.jpg144144Miguel Gonzalez/wp-content/uploads/2013/04/Arxterra-Logo-340x156.pngMiguel Gonzalez2018-04-19 17:00:482018-05-14 00:44:57Spring 2018: Interface and Cable Tree Blog Post
