Download SD Project Plan Presentation

Balance Bot
DT04
Stephan Baranoff
Nicole Beck
Chris Hamrock
Stephanie Kosec
Dr. Sastry
Introduction
The Statement of Need
RoboGames holds an annual competition called the Balancing
Robot Race. This competition challenges participants to design a
one or two wheeled robot that can maintain its balance without
any external support, and be the quickest to complete a timed,
predetermined obstacle course. This is a Remote Controlled
robot. The Balancing must be autonomous, but the driving can be
controlled by an R/C unit.
Introduction
The Design Problem Definition
The Design Goal
A two or one wheeled remote controlled robot that can maintain its
balance without any external support.
Objectives
To complete the predetermined obstacle course in the shortest
amount of time, while maintaining balance.
Constraints
The robot must be designed in such a way that its weight does not
exceed 50lbs, its size does not exceed 3’x 3’x 3’. It cannot use an
internal or external combustion engine and cannot harm the
environment or any other robots in the competition.
Design Requirements Specification
Mechanical
•
With zero inputs (no velocity or turning request, no external applied force) in steady state the robot shall:
– S1: Not vary more than 3 degrees from vertical
– S2: Not drift more than 6 inches from the the original position
•
From an initial condition of zero linear speed on a level surface, the robot shall:
– S3: Be able to recover to 0 degrees, measured from vertical, starting at an angle of no more than 30 degrees,
measured from vertical.
•
On a smooth level surface, the robot shall:
– S4: Have a linear velocity of no less than 48 inches/s
•
From a lateral velocity of 48 inches/s, on a smooth level surface, given a step input request to zero speed, the robot
shall:
– S5: Stop within 6 inches of the step input
– S6: Not vary more than 5 degrees from vertical during the transient stopping period
– S7: Not move in the opposite direction of the original forward motion by more than 6 inches from the location
where the zero input was received.
•
From a constant velocity state the robot shall:
– S8: Be able to climb and descend ramps having no more than a 20 degree incline with less than a 6 inch/s
change in velocity.
•
When transitioning between surfaces (coefficient of friction having a step change) at a constant velocity the robot
shall:
– S9: Not exhibit a change in velocity of more than 6 inch/s.
Control
•
C1: The control systems for the robot will be implemented as discrete time-domain equations on a digital
computing and logic system.
Design Requirements Specification
Electrical
•
EL1: The angular position sensor will be able to detect the angle of tilt of the robot within 1 degree of the actual
angle.
•
EL2: The angular rate sensor will be able to detect the angular velocity of the robot relative to vertical within 0.1
degrees/s.
•
EL3: The processors and digital logic subsystems will be capable of executing the required control algorithms and
digital filter calculations at no less than 50 times the maximum bandwidth of the input to the filter.
Power
•
P1: The motor driver will be capable of operating at a supply voltage of no less than 24 volts DC and no more than
48 volts DC.
•
P2: The motor driver will be capable of supplying no less than 30 amps DC of peak current.
•
P3: The motor driver will be capable of supplying no less than 15 amps DC of continuous current.
•
P4: The motor will be able to supply maximum peak stall torque with an input current of no more than 30 amps DC.
•
P5: The motor will be able to supply maximum continuous power with an input current of no more than 15 amps
DC.
•
P6: The motor and motor driver will be capable of handling transient loads of full peak current and produce the
rated peak stall torque of the motor in less than 100 ms.
•
P7: The energy storage system supplying the motors and drivers will be capable of operating at 1 CA of current
load for 1 hour.
•
P8: The energy storage system will be able to be recharged from 30% charge to 70% charge in under 4 hours.
Ergonomic
•
ER1: There will be 2 emergency stop buttons, one on the Balance Bot and one on the Remote Control
•
ER2: The Balance Bot will safely stop all operation in no more than 2 s of either of the emergency stop buttons
being pressed.
Economic
•
EC: The parts required to build a prototype of the Balance Bot will cost less than $625.00.
Engineering Calculations
Electrical
Engineering Calculations
Power
Engineering Calculations
Control
Engineering Calculations
Mechanical
Engineering Calculations
Ergonomic
Engineering Calculations
Economic:
•
•
•
SD $100/person
Honors Program $75/person
– 3 members in Honors Program
Total Budget: $625
Accepted Technical Design
Hardware Theory of Operation
-describe how the major hardware design blocks go together
Hardware Block Diagram
Wireless
Transceiver
Non-volatile
Memory
Driver
Inputs
ESTOP
Input
Gyroscope
Accelerometer
μController
IR
Sensor
IR Sensor
Current
Sense
Amplifier
Current
Sense
Resistor
MOSFET
Driver
Circuit
MOSFET
Driver
Circuit
DC/DC
Converte
r
H-BRIDGE
Encoder
H-BRIDGE
Current
Sense
Amplifier
Current
Sense
Resistor
Encoder
Battery
Battery
Left PM DC
Gear Motor
Right PM DC
Gear Motor
Left
Wheel
Right
Wheel
Battery
Accepted Technical Design
Discuss the progression of the design from level 0 to level n+1
•
•
•
•
•
The hardware block diagram began with an microprocessor, a battery, a motor, wheels and a
transceiver. From there it was decided that two motors were needed to independently control the
wheels. In order to control the motor, a motor control circuit would need to be designed for each
motor. Part of the motor control includes an H-bridge which will allow the robot to move both
forward and backward. The H-bridge will supply the current to the motor and in order to control the
amount of current going to the motor, the current sense amplifiers and current sensor resistors
were added to the design. Also, since the H-bridge is controlled by a PWM signal, the MOSFET
driver circuits were added to amplify the signal. PMDC gear motors with a 10:1 gear ratio were
chosen in order to develop enough torque to move the Balance Bot.
Once the method of movement of the robot was determined, the control of the movement needed to
be determined. It was decided that sensors would be added to accomplish this task. An
accelerometer, gyroscope, and infrared sensors were specifically chosen to send the Balance Bot’s
position signals back to the microprocessor.
In order to power the robot, separate batteries would be needed for the motors and the
microprocessor. To ensure that the microprocessor receives the correct input voltage, a DC/DC
converter was added to the output of the battery to regulate it.
From the transceiver we added the signals that would be sent to the microprocessor. These
signals include the driver inputs and the ESTOP.
For debugging and error logging purposes, a non volatile memory was added. Lastly, in order to
meet competition guidelines as well as for safety, we added an additional ESTOP to the Balance
Bot.
Accepted Technical Design
Software Theory of Operation
-describe how the major software design blocks go together
Accepted Technical Design
Discuss the progression of the design from level 0 to level n+1
•
•
•
•
The first software block diagram developed included inputs from sensors, processing, and outputs
to actuators. This generic system expanded as the hardware system components and requirements
were addressed. The first piece of software added was a simple motor control interface that would
transform a torque number within the software into a useful output readable by a motor controller.
Once the motor controller design was added to the parts to be designed, that block was changed to
include the motor control algorithms and digital logic.
Sensors were the next logical piece of hardware added to the system. The sensors needed to
measure a variety of physical parameters identified as important for the Balance Bot, but the output
format from the sensors was not yet known. Multiple sensors were deemed necessary so a fusion
of sensors became necessary. This block is a discrete time filter of some kind that was added to the
system to support multiple sensors.
The output of each sensor is not yet known, which inspired the addition of a device driver block to
the software. The output of sensors usually needs to be calibrated and adjusted in some format to
calculate a physical value, velocity for example, from a sensor output, such as ADC counts. A
calculation of physical value from raw value software block was added for each component after
the device drivers.
Between the input sensors and the output actuators is the compensator that calculates the next
output based on current inputs. Feedback from motors was added to the system and signals were
routed between blocks to improve data flow accuracy. Safety and watchdog functionality was
added in order to support debugging of the software system. This allows for both data logging for
anomalous event root cause analysis as well as model parameter fitting. At this point, the software
block diagrams were deemed complete for this level of design.