Вы находитесь на странице: 1из 10

STONY POINT HS -- ROUND ROCK ISD

Machine Control Design


Project 3.1.7 VEX and RobotC

David Helbling
3/17/2014






TABLE OF CONTENTS
Introduction
Design Brief
Design Process
Pictures
RobotC Code
Discussion Questions
Recommendations Page



INTRODUCTION
Every machine that is controlled by a computer bases every
operation on data and instructions that were designed by an
engineer, technician, or end user. Designers must think through
every contingency and all that can go wrong. In addition safeguards
must be in place so that people and equipment are not damaged.


Problem 4: Cable Winding Mechanism (Hardware Level 3 Software Level 3)
A telecommunications contractor needs your team to design a device that can accurately
wind up a specific length of cable. The device must be able to wind a specific length
consistently. The device must also be able to be started and stopped (emergency) by using
a switch.




DESIGN BRIEF
Client Company:
Joes Telecommunications Contractors
Target Consumer:
Telecommunications Company
Problem Statement:
A telecommunications company has a length of cable that
needs to be wound consistently and safely.





Design Statement:
They need a winch mechanism that can be controlled by an
operator, and has a built-in kill-switch functionality.






Constraints:
Device must be able to stopped and started multiple times
without reinitializing the program, device must wind the
cable vertically from the edge of a table.








DESIGN PROCESS




PICTURES

ROBOTC CODE
task main()
{
bool direction; //Defines direction variable
int distance; //Defines distance variable
bool on; //Defines on variable
stopMotor(winchMotor); //stops any current motion
while(true) //forever loop
{
SensorValue(quad) = 0; //resets encoder value to 0
turnLEDOn(red); //turns on idle light
while (SensorValue(bumpSwitch) == 0) //while the button has not been pressed
{
if(SensorValue(potentiometer) > 2048) //if potentiometer is past half-way point
{
turnLEDOn(green); //turn on green directional light
turnLEDOff(yellow); //turn off yellow directional light
direction = false; //sets direction to "down"
}
else
{
turnLEDOn(yellow); //turn on yellow directional light
turnLEDOff(green); //turn off green directional light
direction = true; //sets direction to "up"
}
}
on = true;
untilRelease(bumpSwitch); //wait until button is released before starting
wait(.2); //brief pause for debugging purposes
turnLEDOff(red); //turn off idle light
distance = SensorValue(potentiometer); //saves the potentiometer value to prevent bugs when
raising or lowering
while(on) //while button has not been pressed or loop broken
{
if (SensorValue(limitSwitch) == 1) //when limit switch is activated
{
if(direction) //if going up
{
startMotor(winchMotor,50); //go down
wait(.5); //for half a second
stopMotor(winchMotor); //stop the winch
on = false; //break loop
}
else //if going down
{
startMotor(winchMotor,-50); //go up
wait(.5); //for half a second
stopMotor(winchMotor); //stop the winch
on = false; //break loop
}
}
if (SensorValue(bumpSwitch) == 1) //if button pressed
{
stopMotor(winchMotor); //stop the motor
on = false; //break the loop
}
else //if button is NOT pressed
{
if(direction) //if yellow
{
if(SensorValue(quad) > (distance-4096)/4) //if the encoder value is more than the set distance
{
startMotor(winchMotor,-100); //rotate motor counter-clockwise
}
else
{
stopMotor(winchMotor); //stop the motor
on = false;
}
}
else //if green
{
if(SensorValue(quad) < (distance)/4) //while the encoder value is more than the set distance and button
has not been pressed
{
startMotor(winchMotor,100); //rotate motor clockwise
}
else
{
stopMotor(winchMotor); //stop the motor
on = false;
}
}
}
}
stopMotor(winchMotor); //stops motor once the above conditions have been broken
while(SensorValue(bumpSwitch) == 1) //while holding down the kill switch
{
wait(.01); //brief pause for debugging purposes
}
wait(.2); //another pause for debugging purposes
}
}



DISCUSSION QUESTIONS
1. What was the most difficult part of the problem?


The most difficult part of the problem was programming and troubleshooting the kill-switches. There
were so many unwanted quirks that would have rendered the kill-switch ineffective that it took almost
twice as many lines of code than we originally planned. Our original code did stop the winch while the
button was pressed, but when it was released, the winch would start again. We had to add a lot more
while loops in order to circumvent the issue, but the extra code did eventually give us a functioning
device.

2. List and describe two features that were not part of the design problem that could be
added to improve your design.


Two things that could be added to improve our design could be a display to show the current
length being wound, as well as a knob to control the speed of the winch, instead of just the
length. Currently, our design only displays which direction the cable is being wound, and the
operator only knows the general length the cable will be unwound by fiddling with the knob.
Also, being able to vary the speed could prove useful in lifting lighter or heavier loads in order
to prevent damages.


RECOMMENDATIONS PAGE
This project, in my opinion, was equal parts fun, challenging, and frustrating, and could benefit from some
changes in the future. A change that teachers could make regarding this project could be to make the
constraints of the problem more apparent. Students taking this project could also benefit from knowing
how to reactivate the ROBOTC Natural Language functionality, because sometimes it gets shut off, which
renders the program ineffective until, by trial and error, the student manages to turn it back on. This could
take hours to fix without proper knowledge; hours that could be spent refining and programming the robot.
All in all, however, this is a well-rounded project, and one that does not need very much improvement.

Вам также может понравиться