AT-ST Generation 2 Summary Blog Post
Author/s:
Brian Ababat (Software/Controls Engineer)
Patrick Nguyen (Electronics Engineer)
Wendy Guerra (Project Manager/Manufacturing & Design Engineer)
Verification:
Approval:
Table of Contents
Executive Summary
By: Wendy Guerra
Program and Project Objectives
Program Objectives
The Robot Company (TRC) will be debuting its 2019 line-up of toy robots and associated games at the Toy-Invasion 2019 convention in Burbank CA on January 6, 2019. Your team’s assignment is to make the 3D printed and/or laser-cut prototypes to be showcased at the convention, prior to production starting in the second quarter of 2019. The robots will feature our new ArxRobot smart phone application and the Arxterra internet applications allowing children to interact and play games around the world. In addition, the robots should be able operate autonomously in game mode. See game(s) (i.e, mission objectives) assigned to your robot by the Game Division. To decrease electronics cost, interoperability between all TRC robots will be maintained by incorporation of the 3DoT board, developed by our Electronics R&D Section. Modification of downloadable content is limited to software switch setting and robot unique graphics of the smart phone and Arxterra applications. Modifications of electronics is limited to custom 3DoT shields as required by the unique project objectives of your robot. The Marketing Division has set our target demographic as children between the ages of 7 and 13, with a median (target) age of 11. To decrease production costs, please keep robots as small as possible, consistent with our other objectives. As with all our products, all safety, environmental, and other applicable standards shall be met. Remember, all children, including the disabled are our most important stakeholders. Our Manufacturing Division has also asked me to remind you that Manufacturability and Repairability best practices must be followed.
Project Objectives
The AT-ST team was assigned the task of designing a 2nd generation bipedal toy robot in the style of an AT-ST Walker from the Star Wars IP utilizing a 3Dot board. The robot was to use two D.C. motors as the main driver for walking motion instead of the more frequently used servo based motion. Project AT-ST was to be able to demonstrate static walking and should be able to demonstrate the ability to dynamic walk and turn.
Mission Profile
Fall 2018 AT-ST was inspired by previous generations of AT-ST and BiPed. These models used the Theo Jansen leg design to allow for a smooth walking motion. AT-ST should be able to complete the Mission Objectives that are stated in the document.
Project Features
Theo Jansen Leg
The method we are using for walking was inspired by the Dutch artist Theo Jansen. He made robots powered by wind as it walks around. We use his method to create our legs to get the same method.
Micro Motor
To control the leg movement we decided to use 2 Micro Motors since it consumes less current and is compatible with the Shaft Encoders
Shaft Encoders
As a way of controlling the motors moving at different speed as well as helping our AT-ST robot to walk and turn. The Shaft Encoder is used to help see our motor’s movement as our AT-ST walks forward.
Ultrasonic Sensor
As a way of avoidance control, the Ultrasonic Sensor is used to help the AT-ST avoid getting into any sort of collision when navigating through the maze.
Requirements
Engineering Standards and Constraints
Review and show compliance with constraints on the project imposed by The Robot Company (i.e., CSULB) and Project Stakeholders. Specifically include University and applicable environmental, health, and safety standards and those safety standards specifically associated with the product (e.g., Children’s Toys).
Applicable Engineering Standards
- IEEE 29148-2018 – ISO/IEC/IEEE Approved Draft International Standard – Systems and Software Engineering — Life Cycle Processes –Requirements Engineering.
- NASA/SP-2007-6105 Rev1 – Systems Engineering Handbook
- Bluetooth Special Interest Group (SIG) Standard (supersedes IEEE 802.15.1)
- C++ standard (ISO/IEC 14882:1998)
- Federal Communications Commission (FCC) Relevant standards for a product implementing a 2.4GHz radio, FCC Intentional Radiators (Radio) Part 15C, and Unintentional Radiators FCC Part 15B for CPU, memories etc.
- NXP Semiconductor, UM10204, I2C-bus specification and user manual.
- ATmega16U4/ATmega32U4, 8-bit Microcontroller with 16/32K bytes of ISP Flash and USB Controller datasheet section datasheet, Section 18, USART.
- USB 2.0 Specification released on April 27, 2000, usb_20_20180904.zip
- Motorola’s SPI Block Guide V03.06
Environmental, Health, and Safety (EH&S) Standards
CSULB College of Engineering (COE) Safety Resources. Start your search for applicable CSULB COE Safety Standards and Procedures here. Please review and acknowledge if any safety issues as defined by the COE applicable to your project. For example, the closest safety constraint for a linear actuator is for use of the Hydraulic Press located in the Engineering Technology (ET) Building Lab. Here is a link to the Hydraulic Press Safety document.
CSULB Environmental Health & Safety (EH&S)
IEEE National Electrical Safety Code (NESC)
NCEES Fundamental Handbook (FE) Reference Handbook
ASTM F963-17, The Standard Consumer Safety Specification for Toy Safety, is a comprehensive standard addressing numerous hazards that have been identified with toys. In 2008, the Consumer Product Safety Improvement Act of 2008 (CPSIA) mandated that the voluntary toy safety standard in effect at that time become a nationwide mandatory children’s product safety rule.
Disposal of Hazardous Waste including Electronic and Solar Cells
CSULB Physical Planning & Facilities Management (PPFM) Environmental Compliance Electronic Waste Handling and Disposal Procedures. These procedures shall be followed for the disposal of all batteries.
Program Level 1 Requirements
Project/Economic
Subcategories: Cost, Extensibility, Interoperability, Maintainability, Quality, Marketability, and Schedule
All 3DoT robots shall be constrained to a not to be exceed Cost of $250.
All project Schedules shall be constrained to a completion date of Tuesday December 18, 2018. Project completion includes documentation and materials purchased by or loaned to the project.
One of the Economic Factors affecting our robots are return rates. To demonstrate the durability and child friendliness of our robot a simple drop test from 1.4 meter should be performed. The height is defined by the average height of an average 11 year old girl.
Extensibility is designed into the 3DoT board by way of one 8-pin 100 mil connector located on the front of the board and two 8-pin 100 mil connectors located on the top of the board. By plugging shields into these connectors, the 3DoT board can support a diverse set of robots. All robots shall contain one or more custom designed 3DoT shields. The 3DoT shield(s) incorporating interface electronics between the 3DoT board and sensors and/or actuators unique to the robot. Surface Mount Technology (SMT) will be employed unless a waiver for through-hole parts is granted.
Maintainability: Disassemble and Reassemble of the robot shall be constrained to less than 20 minutes (10 + 10 minutes). Disassembly: The 3Dot board is clear of all other electronic and mechanical subassemblies. All electronic and mechanical subassemblies and associated connectors, sensors, and actuators including motors are disconnected. A functional test of the robot is conducted after reassembly to confirm its functionality. All project may reference a cable tree as well as an assembly diagram as necessary. This requirement is demonstrated/verified on the last day of the schedule. Projects may request a waiver with justification.
Social and Ethical
Subcategories: Accessibility, Aesthetics, and Usability
Accessibility by the blind and Marketability of the robots shall be implemented/enhanced by a speaker. The speaker shall generate sound effect consistent with the type of the robot. For example, the Goliath tank would make “track” sounds, the AT-ST sound effects would mimic their Star Wars antecedent.
Wiring Aesthetics shall be nice and clean with the usage of terminal blocks, 100 mil contact pins and headers, 2.0mm PH series JST connectors, and barrel connectors. Handling Precaution for Terminal and Connector will be in compliance with JST documentation.
To enhance Aesthetics, the robot shall be designed in such a way that there are no dangling or exposed wires. Connectors will used between all electronic and electromechanical components. Jumper wires will not be used, ribbon cables are preferred.
To enhance Aesthetics, the form factor of a robot modeled on a real or fictitious robot shall be constrained by the original. For example, Goliath should be a scale model of the real Goliath 302 tank. Projects may request a waiver with justification.
Usability of the robots shall be enhanced by adding autonomous functions and/or by use of the Arxterra phone application as dictated by the assigned mission.
Manufacturability
Subcategories: Constructability, Size, Weight, and Power (SWAP)
Constructability of 3DoT robots shall be documented at the CDR and approved by the president of the TRC robot company. Constraints imposed by this requirement include the use of bushing or bearings in all moving and rotating parts. Interlocking Hinges with latching mechanism. No gaps greater than 1 millimeter, and immediate access to all external connectors (USB, switches).
Manufacturability of 3D printed robots shall be demonstrated by compliance with the 3/3/3 rule. Specifically, total print of a robot is constrained to 9 hours, with no single print taking longer than 3 hours. Projects may request a waiver with justification.
The Size of the electronics enclosure, shall be constrained to be no greater than the 3DoT board, 3DoT shield(s), and associated mounting hardware.
Power to all 3D robots shall be provided by the 3.7V RCR123A battery included with the 3DoT board or use of the external battery 2.0mm PH series JST connector located on the 3DoT board. The RCR123A is a Lithium Polymer LiPo battery. All Safety regulations as defined in Section 4.3 Hazards and Failure Analysis of this document shall apply to the shipping, handling, storage, and disposal of LiPo batteries.
Back of the envelope calculations and experiments shall be conducted to set the diameter of Power carrying wires. Follow the American Wire Gauge (AWG) standard when defining the diameter of power carrying wires. This work to be completed and documented by the CDR.
Environmental Health and Safety (EH&S) Standards
Subcategories: Environmental Standards, Sustainability, Toxic waste (Solar panels), Health and Safety, Ergonomics
All standards, codes, and regulations as defined in the “Engineering Standards and Constraints” Section of this document shall apply.
Functional
All 3DoT robots shall incorporate the 3DoT v7 series of boards.
Software shall be written in the Arduino De facto Standard scripting language and/or using the GCC C++ programming language, which is implements the ISO C++ standard (ISO/IEC 14882:1998) published in 1998, and the 2011 and 2014 revisions. Required exceptions to this standard can be found here.
All 3DoT robots shall be in compliance with the 3DoT Command and Telemetry Packet specification.
All 3DoT robots shall be controlled via Bluetooth 4.0 in compliance with the Bluetooth Special Interest Group (SIG) Standard (supersedes IEEE 802.15.1).
Project Level 1 Functional Requirements
L 1-1: The AT-ST shall drive/walk on paper, cloth, and baltic birch surfaces.
L 1-2: The AT-ST shall be able to operate over 1 hour with a safety margin of 2x.
L 1-3: The mission should be completed when the robot exits the maze and stops in play-back mode.
L 1-4: Once the AT-ST exits the maze, it should do a celebratory dance.
L 1-5: The AT-ST shall detect other robots within 0.3 meter radius and stop.
L 1-6: The AT-ST should take corrective action as defined in the rules of the game once bots are detected
L 1-7: The AT-ST should successfully make left, right, and U turns within the time and radius as defined in robot specific requirements.
L 1-8: The AT-ST shall not walk through walls.
L 1-9: The AT-ST should recognize the maze
L 1-10: The AT-ST will not exceed required definitions as defined in robot specifics
L 1-11: The AT-ST will support its own weight
L 1-12: The AT-ST should walk the shortest path of the maze if mission cannot be completed as defined in the rules of the game
System/Subsystem/Specifications Level 2 Requirements
Mission Requirements
L2-1 The 3DoT Board should receive commands from the Arxterra app via Bluetooth Transceiver. It will decode and transmit data to servos, PCB and other components of the robot.
L2-2 The AT-ST power source shall be able to fit inside AT-ST and must be integrated such that it does not conflict with the functionality of the robot.
Electronic Requirements
L2-3 AT-ST shall use 2 DC Motor to move the legs (1 per leg).
L2-4 AT-ST shall use a Servo Motor to adjust the center of gravity of the robot so it can turn
L2-5 AT-ST Battery’s duration shall last up to an hour.
L2-5 AT-ST shall use 2 shaft encoder to keep track of the leg motion
L2-6 AT-ST shall utilize 2 Lithium Ion Battery – 2Ah for its power supply.
L2-7 AT-ST shall use an ultrasonic sensor to sense other robots within a 0.5-meter radius
L2-8 AT-ST shall use UV sensor to navigate through the maze.
Manufacturing Requirements
L2-9 AT-ST shall have a total weight of 800 g and weight will be properly distributed to the body and legs to support its own weight while walking.
L2-10 AT-ST shall not exceed dimensions of 6” x 6” in order to fit in the maze and walk and properly turn without hitting the walls in the maze.
L2-11 AT-ST shall have its body 3D printed (ABS) or laser cut.
L2-12 AT-ST shall have legs 3D printed (ABS) or laser cut.
L2-13 AT-ST will appear as AT-ST from Star Wars.
Allocated Requirements / System Resource Reports
The System block diagram above for AT-ST help visualize the system of the AT-ST. The 3DoT board uses ATmega32U4 as the microcontroller. The 3DoT board consists of a microcontroller, Bluetooth transceiver, servo header and dual motor driver. The 3DoT board (v6) will also be connected to the servos, motors and main custom PCB. PCB1 will be the master PCB that routes all input and output for the sensors. PCB 2 and PCB 3 are used for UV sensors which will be connected to the I2C expander on PCB 1. Bluetooth transceiver will connect to a mobile device using the Arxterra app via Bluetooth.
To read about it,
Blog post: https://www.arxterra.com/at-st-system-block-diagram/
Source: Spring 2018 AT-ST Final Blog post
By: Wendy Guerra
| Mass Report | |||||
| Resource | Expected weight(g) | Measured weight(g) | Uncertainty % | Margin | Source Link |
| 3Dot Board | 15.0 | 0.0 | 10.0 | 1.5 | AT-ST Gen#1 Blog Post |
| RCR123A | 15.0 | 0.0 | 10.0 | 1.5 | AT-ST Gen#1 Blog Post |
| Servo | 9.0 | 9.0 | 10.0 | 0.9 | AT-ST Gen#1 Blog Post |
| Legs | 120.0 | 100.0 | 10.0 | 12.0 | Mass reference |
| Body | 180.0 | 160.0 | 10.0 | 18.0 | Mass reference |
| Ultrasonic Sensor | 8.5 | 8.0 | 10.0 | 0.9 | AT-ST Gen#1 Blog Post |
| Optical Sensor | 0.7 | 0.7 | 10.0 | 0.1 | Datasheet |
| DC motor w/ shaft encoder | 36.0 | 18.0 | 10.0 | 3.6 | Motor |
| Screws/Bolts/Washer | 200.0 | 15.0 | 10.0 | 20.0 | Mass reference |
| PCB | 10.0 | 4.0 | 10.0 | 1.0 | AT-ST Gen#1 Blog Post |
| Unit (g) | |||||
| Project Allocation | 800.0 | ||||
| Total Margin | 59.4 | ||||
| Total Weight | 859.4 | ||||
| Maximum Expected | 729.2 | ||||
| Contingency | 70.8 | ||||
| Total Measured | 498.4 | ||||
Power report referenced from AT-ST Generation #1.
Project Report
By: Brian Ababat
Project WBS and PBS
Project Task Matrix: https://docs.google.com/spreadsheets/d/1tRwaMMoftwmn_mTPSmE4tkiAcbTXb15QuQ_Iaq3tRSA/edit?usp=sharing
Project Gnatt Chart: https://docs.google.com/spreadsheets/d/1qJi5Dn5vKa3LCvSwmjcABUZHhiHcZaAdZUwo20mh_dQ/edit?usp=sharing
Work Breakdown Structure: https://drive.google.com/file/d/1kZrGJFDMnC0kTgMegdcvJuCHic7w2qYE/view?usp=sharing
Source: Spring 2018 AT-ST Final Blog
Cost
By: Wendy Guerra
| Cost Report | ||||||
| Resource | Expected cost ($) | Actual cost ($) | Shipping | Uncertainty(%) | Margin | Source Link |
| 3Dot Board | 0.00 | 0.00 | 0.00 | 10.00 | 0.00 | AT-ST Gen#1 |
| RCR123A | 0.00 | 0.00 | 0.00 | 10.00 | 0.00 | AT-ST Gen#1 |
| Servo | 5.00 | 0.00 | 0.00 | 10.00 | 0.50 | AT-ST Gen#1 |
| Legs | 10.00 | 5.00 | 0.00 | 50.00 | 5.00 | CSULB Library |
| Body | 30.00 | 5.00 | 0.00 | 50.00 | 15.00 | CSULB Library |
| Ultrasonic Sensor | 2.50 | 0.00 | 0.00 | 10.00 | 0.25 | AT-ST Gen#1 |
| Optical Sensor | 0.50 | 0.00 | 0.00 | 10.00 | 0.05 | Datasheet |
| DC motor w/ shaft encoder | 10.00 | 11.50 | 12.00 | 20.00 | 2.00 | Motor |
| Screws/Bolts/Washer | 10.00 | 23.95 | 0.00 | 50.00 | 5.00 | AT-ST Gen#1 |
| PCB | 20.00 | 10.40 | 6.70 | 20.00 | 4.00 | AT-ST Gen#1 |
| Cost($) | Cost($) | |||||
| Project Allocation | 250.00 | Total Shipping | 18.7 | |||
| Total Margin | 36.80 | Total Actual Cost | 55.85 | |||
| Total Expected | 88.00 | Total Cost w/Shipping | 74.55 | |||
| Maximum Expected | 124.80 | |||||
| Contingency | 125.20 | |||||
Schedule
Project Gnatt Chart: https://docs.google.com/spreadsheets/d/1qJi5Dn5vKa3LCvSwmjcABUZHhiHcZaAdZUwo20mh_dQ/edit?usp=sharing
Source: Spring 2018 AT-ST Final Blog Post
Concept and Preliminary Design
By: Brian Ababat
Literature Review
- The Theo Jansen leg design was an integral design component for AT-ST movement. This leg design translates circular motion into a walking motion.
- PID controllers to control motor speed. Details can be found in the C/C++ ARDUINO ROBOTS Lecture 6 post.
- The custom PCB must be designed with the 3Dot boards dimensions and pin outs in mind.
Design Innovation
- PID control to maintain a 180° phase difference between motors 1 and 2.
- Build and play mechanism for assembling robot to utilize quick turnout of laser cut components.
- Optical sensor triggers to reset internal estimation of motor phase to prevent drift.
- 3DoT shield for integration with the 3DoT board for simplifying motor connections.
Conceptual Design / Proposed Solution
With the provided 3Dot board in mind, it comes with dual motor drivers, a servo header, a battery placement, a bluetooth transceiver, and a peripheral interface. We need some sort of software to assign to the robot to make it walk and turn and also avoid collisions. To control robot and the software, A mobile device will have the Arxterra App which will communicate with the microcontroller through the bluetooth transceiver. The servo header will connect to one servo that will have a balancing weight on it to make sure the robot does not tip over when one of the legs is lifted for walking. The dual motor drives will connect to the two DC motors with shaft encoders. The shaft encoders will connect to the custom PCB where the absolute encoders and ultrasonic sensor will also connect to. The ultrasonic sensor will connect to the peripheral interface on the microcontroller to ensure the robot will stop moving if it sees an object in front of it.
System Design / Final Design and Results
By: Brian Ababat
System Block Diagram
Due to limitations on time, we use the Spring 2018 – System Block Diagram as an example for our block diagram. Changes to be made are that the inclusion of PID controllers between the microcontroller unit and the Dual motor drive component, the removal of the gyro, and the replacement of the UV light sensors with infrared optical sensors. Features of our design are included here.
- Each DC motor uses two pins which are connected the the Adafruit Motorshield v2 motor drivers.
- Each motor shaft encoder uses four pins. Two pins are connected to +3.3V and GND to power the encoders. The two remaining pins are used for encoding the shaft’s rotation. The remaining pins are connected to the Arduino’s peripheral interface. One of these pins must be connected to the interrupt pins (INT0 or INT1) of the Arduino for good accuracy. The other pin may be connected to any of the remaining Arduino pins.
- The ultrasonic sensor uses four pins. Like the shaft encoders, two pins are used for power while the remaining two pins are connected to any of the remaining Arduino pins.
Interface Definition
By: Patrick Nguyen
This section is an updated version of the Interface Matrix presented at the PDR and CDR. An additional section should discuss the Cable Tree (i.e. wire harness, wiring diagram, etc.) developed in concert with the E&C and MFG showing how the wires, cables, and connectors were integrated into the final product.
If your project has includes and Interface Control Document (ICD), it would go here: top level explanation of MST communication, E&C connections, MFG mating and fastening → to be covered in detail later in the presentation during respective sections.
Interface Matrix:
| Pinout of Component | ATMega32U4 |
| Motor 1 + | Motor driver 1 + |
| Motor 1 – | Motor driver 1 – |
| Motor 2 + | Motor driver 2 + |
| Motor 2 – | Motor driver 2 – |
| Encoder 1 + | 3.3 V |
| Encoder 1 – | GND |
| Encoder 2 + | 3.3 V |
| Encoder 2 – | GND |
| Encoder 1 Phase A | (RX / INT1 / PD2) |
| Encoder 1 Phase B | (MISO / PDO / PCINT3 / PB3) |
| Encoder 2 Phase A | (TXD1 / INT3 / PD3) |
| Encoder 2 Phase B | (MOSI / PDI / PCINT2 / PB2) |
| Optical Sensor 1 Pin 1 | 100 K Resistor |
| Optical Sensor 1 Pin 3 | (SCL / PD0 / INT0 / OC0B) |
| Optical Sensor 1 Pin 2 | 330 Resistor |
| Optical Sensor 1 Pin 4 | GND |
| Optical Sensor 2 Pin 1 | 100 K Resistor |
| Optical Sensor 2 Pin 3 | (SDA / INT1 / PD1) |
| Optical Sensor 2 Pin 2 | 330 Resistor |
| Optical Sensor 2 Pin 4 | GND |
| Ultra-Sonic Trigger | (SCK / PCINT1 PB1) |
| Ultra-Sonic Echo | (A4 / ADC1 / PF1) |
The custom PCB designed for the AT-ST project is based around being implemented with the version 7 3 dot board designed by Arxterra. With this in mind, the two motors need in the design can connect to the two motor drivers on the 3 dot board along with the servo. Based off theoretical breadboard through frizting and our rapid prototyping, the optical sensors are placed to act as interrupts and the ultrasonic will connect to an analog pin that will be acting as a digital.
Modeling/Experimental Results
The figure below demonstrates that the PIDs controlling motor speed keeps the motors at a constant and desired RPM and at a 180° phase difference after an initial discontinuity caused by the optical sensors triggering.
Figure 1: Excel plot of the motor phases and speeds
Electronic Design
By: Patrick Nguyen
Figure 2: Fritzing Layout
One assumption that is not visualized on the image above is that the motor drive will lay on top of the Arduino. The 2 dc motors have shaft encoders already on them and they each contain the following pin outs: 1. Motor + 2. Encoder + 3. Encoder Phase A 4. Encoder Phase B 5. Encoder GND 6. Motor -. The red wire is pin out 1 and the white wire is pin out 6. The motor shield will be powered by the 5 volts coming from the Arduino. The 2 motor pins will connect to M1 and M2 on the motor shield respectively. The shaft encoder will also be powered by the 5 volt of the Arduino, so to have multiple pins receive the voltage, we will back tie wires with solder to have the respective pins act as 5V and ground. The phases of the encoders will go into pin 2 and 3 of the Arduino for PID control.
Figure 3: Implemented the use of the motors, ultrasonic sensor, optical sensors and custom PCB
The photo above show the implementation of all of the electronic components with the custom PCB and Arduino. The two motors, ultrasonic sensor, and optical sensors connect to the custom PCB through its female headers. The custom PCB will then connect to the Arduino through its other female headers.
PCB Design
Figure 4: PCB Schematic Layout using EagleCAD
The PCB designed requires multiple headers that will allow the components to connect to the custom 3 dot board. The 2 six pin headers are to connect the DC motors with shaft encoders to the 3 dot board. The motor +/- will go to its own headers which will then connect to the motor drives on the 3 dot board. The headers title absolute are optical sensors that act as absolute encoders. These absolute encoders will send an interrupt signal so the machine knows when the motors have gone a full 360 rotation. The 330 resistor is to make sure that the LED diode in the optical sensors are operational and not burn out. The 100 Kohm resistor is used to replace the previous npn transistor that was used in the previous version of the schematic layout. Instead of having a transistor there to make the optical sensor act as a digital switch to send the interrupt signal, the 100 Kohm resistor does the same while also saving space for the design. Lastly the ultra sonic sensor are connected through the PCB for the AT-ST’s maneuvering.
Figure 5: The Layout of the PCB for AT-ST using EagleCAD
All components on the PCB will be through hole headers with 2 330 ohm and 2 100 kohm resistor. Both of the top and bottom layers are labeled ground so there is no need to connect all the ground pins together. The 3.3 V pins are all connected together where the trace lines are wider than the others (16 mm for 3.3 V compared to the 9 mm of the rest).
Figure 6: Custom PCB with female headers
After sending the custom PCB to OSHpark, a 3rd party fabrication party, the design PCB came in. As all connections on the PCB are through holes, rows of females headers were soldered onto the board to connect to the Ardunio. The 4 resistors are also soldered to keep the optical sensors from short circuiting.
Firmware
By: Brian Ababat
The DC motors are monitored using shaft encoders. The Teensyduino Encoder library is used to read the motors angular velocity and angular position. Encoder objects are defined which store a count of the number of pulses sent by the shaft encoders. This pulse count can be used to calculate the RPM of the motor by seeing how much the count has changed since the last check. The pulse count can also be used to calculate the phase by comparing the current count to the number of counts after one full rotation. Further reading into FLOW CHART FOR MOTOR PHASE LINK.
Each DC motor is controlled by a PID controller. The first DC motor’s PID controller monitors the RPM, while the second DC motor’s PID controller monitors how far the second motor’s phase is from being 180° out of phase with the first motor. Figure 7 shows the block diagram representation of this PID control system.
Figure 7: PID Control -Block Diagram
Phase unwrapping is necessary due to the discontinuous jump from 360° to 0°. This jump is relevant for the PID control of the second DC motor. To circumvent this issue, the phase error is restricted from -180° to +179°. If the phase error is positive, motor 2 is ahead of its desired position and should slow down. If the phase error is negative, motor 2 is behind its desired position and should speed up.
void computePID()
{
motor1Count = encoder1.read();
motor2Count = encoder2.read();
// Calculates motor 1's RPM
calculateRPM();
// Reset count when we go 5% over the expected count for motors 1 or 2
if(motor1Count > maxCount + (maxCount * 0.05) ){ encoder1.write(0); }
if(motor2Count > maxCount + (maxCount * 0.05) ){ encoder2.write(0); }
// Calculate the setpoint for pidMotor2Speed
motor2PhaseError = motor1Count + maxCount / 2 - motor2Count;
if (motor2PhaseError > maxCount / 2) {
motor2PhaseError -= maxCount;
}
pidMotor1Speed.Compute();
motor1->setSpeed((int) (motor1Speed));
pidMotor2Speed.Compute();
motor2->setSpeed((int) (motor2Speed));
}
void calculateRPM()
{
// Calculate RPM when we reach polling for motor 1 and 2
if (timeElapsed > samplingTime) {
if (lastCount1 > motor1Count) {
motor1RPM = (motor1Count + maxCount - lastCount1) * ((conversionFactor / timeElapsed));
} else {
motor1RPM = (motor1Count - lastCount1) * ((conversionFactor / timeElapsed));
}
if (lastCount2 > motor2Count) {
motor2RPM = (motor2Count + maxCount - lastCount2) * ((conversionFactor / timeElapsed));
} else {
motor2RPM = (motor2Count - lastCount2) * ((conversionFactor / timeElapsed));
}
lastCount1 = motor1Count;
lastCount2 = motor2Count;
timeElapsed = 0;
}
}
Phase drift is an error that occurs due to the inaccuracies of the shaft encoders. A drift error is the deviation of a measurement after initial calibration. In this case, the Arduino could think the phase of the motor is at 0° when the motor is in fact several degrees off. This issue is dealt with by using an optical sensor as a switch that triggers whenever the motor completes one full rotation. Whenever this switch is triggered, the encoder count is reset to 0. This is handled by using two pin change interrupts in the following snippet of code. In the unusual case of the optical sensor failing to trigger, the encoder count is reset to 0 whenever the current count exceeds 5% of the defined maximum count.
void setup()
{
... Other setup code ...
////////////////////////////////////////
// Setup for the Pin Change Interrupt //
////////////////////////////////////////
pinMode(opticalSensor1, INPUT);
digitalWrite(opticalSensor1, HIGH);
pciSetup(opticalSensor1);
pinMode(opticalSensor2, INPUT);
digitalWrite(opticalSensor2, HIGH);
pciSetup(opticalSensor2);
}
void pciSetup(byte pin)
{
*digitalPinToPCMSK(pin) |= bit (digitalPinToPCMSKbit(pin)); // enable pin
PCIFR |= bit (digitalPinToPCICRbit(pin)); // clear any outstanding interrupt
PCICR |= bit (digitalPinToPCICRbit(pin)); // enable interrupt for the group
}
ISR(PCINT0_vect) // Pin change interrupt for D8 to D13
{
// Change when pin opticalSensor1 goes LOW
os1State = !os1State;
if (os1State) {
encoder1.write(0);
//Serial.println(motor2Count);
}
}
ISR(PCINT1_vect) // Pin change interrupt for A0 to A5
{
// Change when pin opticalSensor2 goes LOW
os2State = !os2State;
if (os2State) {
encoder2.write(0);
//Serial.println(motor1Count);
}
}
An ultrasonic sensor is used to determine whether an object is in front of the bot. In the case that there is an object, the desired RPM of motor 1 is set to 0. Otherwise, the bot is free to continue moving forwards. This is a weak method of control but can be improved in multiple different ways. Possible improvements could be to slow or even reverse the direction of the motors until both legs are at a stable standing position with both motors at the same phase.
bool isClearToMove()
{
// Determines if the bot is free to move forward
bool _isFree = true;
if (sonar.ping_cm() < 30.0) {
_isFree = false;
}
return _isFree;
}
There is currently no integration with the 3DOT board library, but a preliminary method called moveHandler has been used as a general guideline for further development. The ultrasonic is polled to determine whether an object is in front of the bot. If there is no object in front of the bot, the bot can continue to move. However, if there is an object in front of the bot, the desired RPM is set to 0. The PID is then computed to determine the PWM values for motor 1 and motor 2 speed.
void moveHandler()
{
if (isClearToMove())
{
motor1DesiredRPM = BASE_RPM;
} else {
motor1DesiredRPM = 0.0;
}
computePID();
//////////////////////////
// Running the motors //
//////////////////////////
motor1->run(FORWARD);
motor2->run(FORWARD);
}
The control flow is diagrammed by the flow chart found in Figure 8. For a more indepth analysis about the libraries used and how to obtain plots, read the AT-ST/Fall/2018 - Flow chart – Shaft Encoders and Motor Phase PID blog post.
Figure 8: Flowchart. Setup (Yellow),
Ultrasonic (Green), PID (Purple)
Mechanical/Hardware Design
By: Wendy Guerra
This section includes all SolidWorks generated 3D Models of the design. Annotation is recommended. If available the Manufacturing Engineer include photos of the Prototype/Production Parts.
The robot was to incorporate the Theo Jansen Leg design for the legs of the robot to create a swift walking motion with the use of a motor to each leg. The requirements involved having the robot weigh less than 800 g, dimensions be between 6"x6" in order to fit into the maze, utilize either 3-D printing or laser cutting (or both), be able to support its own weight when walking, and these are to name a few that are listed under the requirements. In order to accomplish these requirements, previous generation models were analyzed in order to synthesize a product.
BiPed generation #1, Micro-fobo generation #1, and AT-ST generation #1 were the main sources to the design. Each generation seemed to have certain features to it that could possibly turn into a good product.
In communication with the customer, it was acceptable to create a mixture of previous designs and combine them into one.
Going from the top down, the head that was going to be used would have held all the electronic components was the Micro-fobo head of Spring 2018 3-D printed in ABS shown in Figure 9.
Figure 9: MicroFobo Head
Considering it held everything in place so well for the previous semester, we wanted to incorporate this into our design. The ultrasonic sensor would have taken place as the robot’s eyes. The mouth, and the overall look of the face is aesthetically appealing for a child's toy.
Following the head will be the neck and body to hold the MicroFobo head up as well. It will have placeholders for the motors, and also where each leg will be connected to on each side.
Figure 10: Neck/Body/Motorcase
This design was from AT-ST Spring 2018 shown in Figure 10, but for this design the motors will be closer together and the frame will be directly under the head instead of connecting to the sides of the head to optimize space and have the center of gravity closer to the center. This would have been 3-D printed in ABS.
The Theo Jansen BiPed featured a single crank shaft to rotate the gears and had ball weights to shift weight while walking shown in Figure 11.
Figure 11: Theo Jansen BiPed
By splitting the shaft down the middle to create 2 shafts, each one could be controlled by a motor. In place of the metal ball weights shifting would be a servo placed in the head portion, along with the other electronics, to account for the weight shifting mechanism to have an active walk. Considering the robot will be top-heavy, it is important to have the legs placed close together. The leg design that is incorporated into our design is from BiPed Fall 2016 shown in Figure 12.
Figure 12: Leg Design
Each joint will be connected with screws and bolts, and legs will be laser cut in acrylic. This way, the leg will not have any deformities with the trouble of 3-D printing, especially when it comes to the error with holes that the previous semester had.
Lastly, the feet would have been the Theo Jansen BiPed feet design that AT-ST Spring 2018 utilized shown in Figure 13.
Figure 13: Feet
Considering manufacturing time was going to take too long to even create one iteration of this design, last minute adjustments were made to the design to create all laser-cut parts. The above model was not fully implemented as planned. I communicated this with the team, and we agreed, due to time, we would result in an all laser cut model.
BiPed generation #1 had the most stable robot compared to the other generations, which is where we obtained the head shown in figure 14 that appeared as the AT-ST from Star Wars (i.e. where the name comes from). The head was too big, so I reduced the size of the head to 3/4th of the length in order to meet size requirements, as well as weight requirements considering electronics were going to be a large portion of the total weight.
Figure 14: BiPed Head
Since everything was going to be laser cut, I redesigned neck/body/motor case on AutoCAD since it is a design software that allows you to make 2-D drawings as shown in Figure 15. The motor cases were formed into puzzle like pieces in order to have a better fit and were to be glue with epoxy, as well and the pieces for the feet.
Figure 15: Neck, feet, motor cases, bottom of head
Lastly, the original design of the legs were already formed in a way to be laser cut, so that design stayed the same. The legs were to be held together with nuts, bolts and washers as shown in Figure 16.
Figure 16 Leg with bolts, nuts and washers
Verification & Validation Test Plan
By: Wendy Guerra
Concluding Thoughts and Future Work
The next generation could highly improve on this project. Recommendations before starting anything would be to review as much of the mechanical designs, electrical schematics, and software of previous generations to become familiar with what the project entails. Understanding what is expected is extremely important considering any changes to the project could happen throughout the process, so it is crucial to have a clear goal. Communication with the customer is a must in order to not result in confusion on what the objective of the project is. It is recommended to assign positions (i.e. software, electronics, etc) as soon as possible so each teammate can focus on their individual jobs, but also communicate with each other as well on any updates or changes that may affect the other teammate’s portion.
For students who are in charge of the mechanical aspect of this project, it would be useful to consult with faculty or other individuals for advice. It is important to assess previous generations, see what worked, what did not work, and grow from there. In the case for this project, aside from looking at previous generation, it is important to learn and understand gears, weight distribution, center of gravity, different mechanisms for walking and turning, torque, etc. Looking back, this is several classes all in one project, which is where time management comes into play. Do consider manufacturing time because vendors that manufacture could take anywhere from a few days to even a couple of weeks to return a 3-D printed part (the actual manufacturing of the product is actually a few hours, but there are other customers with parts that need to be printed as well). Bolts and nuts should not be used for the legs since the motors will most likely not be able to drive the legs, but consider bushings and bearings for the next model. Also, when laser cutting, acrylic can easily break if you make any holes a few mm from the edges, and the laser cutter does not always cut the same way each print. A few iterations could work to counter for this error to get the right measurements. Electronics could change certain components used, so it is good to make sure to have weekly updates in case it changes the design (example, placing a servo in the head of the robot or feet). This project should not be taken lightly. Previous generations have yet to meet a good design to have the robot walk.
On the electrical side there will be PCB designing which involves learning Eagle, and software, which in this case Arduino was utilized. All these programs take time and if there are questions they should always be directed to our sources for help. Software came up with motors to be 180 degrees out of phase with a PID controller to incorporate a walking motion, and the PCB design was approved by the supervisor. These accomplishments could always be improved and grown upon. PCB design is a difficult process and as such looking through the tutorial on Arxterra will help. When trying to submit a PCB design, be sure to email it to the customer first as the PCB design process requires many revisions and trying to set up a face to face meeting to discuss it wastes a lot of time that could be used to improve the design.
Overall, time management and communication are crucial when making projects. In any company the company does not grow if we do not communicate and utilize our sources for help when needed. An accumulation of little goals can lead to a great final product, so take one step at a time and work from there.
References/Resources
These are the starting resource files for the next generation of robots. All documentation shall be uploaded, linked to, and archived in to the Arxterra Google Drive. The “Resource” section includes links to the following material.
- Project Video
- Verification and Validation Plan
- Solidworks File (zip folder) Linked to in Mechanical Design Post
- Fritzing Files Linked to in Electronics Design Blog Post
- 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
- Data gathered from PID tuning in CSV form