Sciborg, Day 3
We began by implementing bang-bang control in conjunction
with the ultrasonic sensor. Our task was to use the ultrasonic sensor to judge
distance from an object directly impeding its path.
Our first step was to revisit the ultrasonic sensor code
from before break. By running the program and watching the serial print
monitor, we were able to determine a range of values given by the sensor for a
given distance. We found that for 5 and 10 cm distance between the sensor and
the object, the reading was 11. For a 20cm distance, it was 15; 30cm showed 20;
and 40cm yielded 30. As the distance from the sensor’s position on the sciborg
to the front edge of the sciborg was ~5cm, we believed that a good limiting
value for the sensor would be 15 – that gave the sciborg ample space to stop
moving and still have a small gap between it and the object (averaging 5-7cm).
As this was a form of bang-bang control, we powered the
motors either on fully or completely off, as in the previous bang-bang example.
Next, we implemented proportional control using encoders.
Our task was to attain a distance of 10 ft as precisely as possible using
proportional control. This meant that we had to gradually had to slow down the
power outputs of the motors at a constant rate determined by the distance the
motors had traveled (calculated by the encoders).
We added a delay in the loop so we could get into position
on the course.
We reevaluated the number of rotations (in terms of motor 1)
it takes to reach 10 feet on the course to be 16000.
We introduced three additional variables: d1, d2, and d3.
We designated d1 to be the distance remaining between the
current and target positions. This number will always be negative, since we
defined it as the number of axle rotations (positive) minus 16000.
We then defined d2 and d3. These were specific to each
motor. D2 corresponded to motor 1 and d3 to motor 2. These were specific because
we had discovered that the motors must be at different power levels to go
straight(er).
This difference in power outputs manifested itself in
determining the gains associated with each motor. The gain is important for
proportional control, it is the constant by which the changing value is
modified by.
To calculate the gains, we divided the maximum power output
(235 for motor 1 and 255 for motor 2) by the total number of axle rotations
(16000). This yielded 0.0147 and 0.0159 as the constants by which d1 was
modified into d2 and d3, respectively.
As the distance remaining grows smaller (more distance
traveled – 16000), d1 gets smaller. D1 is then either multiplied by gains of
0.0147 or 0.0159, which further reduces d2 and d3, the power outputs of the motors.
This is how the sciborg slows down proportionally.
We added a 10ms delay in between loops, which has the
sciborg reevaluating every 0.01 seconds.
Next, we tested this out on a different surface to evaluate
the results. We used the rug outside the classroom.
The sciborg didn’t make it to the 10 foot line. We
hypothesized that it was because of the rug’s increased friction relative to
the smoother surface in the lab. As the sciborg’s speeds decreased, the rise in
friction required greater power output to continue moving forward. This caused
the sciborg to stop before it would have in the lab. Even though the sciborg
still “wanted” to move forward and attain the 16000 rotations, it was unable to
due to the friction of the rug.
We then tried to code a “nudge” loop to move the sciborg
forward in small increments to attain the desired number of axle rotations.
We set up the encoder and chose 17000 rotations as the
desired amount in an attempt to compensate for the increased resistance. We set
a while loop and defined d1 similarly to the proportional control above. We
calculated the gains of each motor with the same method, and set the motors to
correspond. For the nudge loop, we added an “if” statement (See comments in the
code for complete explanation).
It worked pretty well!
~~~
CONGA LINE
Next up was the Conga Line assignment. We understood this
assignment to be one where our sciborg would follow something traveling in a
straight path in front of it. We applied this program as if all the sciborgs
would run perfectly straight. Naturally, applying this program in real life
would result in the sciborgs veering to the left/right and losing the object it
was following due to the complications of the sciborg’s build rarely allowing it
to run straight.
So, under this hypothetically perfect situation, we thought
to use the ultrasonic sensor readings to determine the speed of the motor
outputs. We began with three power outputs – let’s call them slow, medium, and
fast. If a reading fell within a designated range, it would determine if the
motor outputs were slow, medium, or fast.
We specified that if a reading was relatively larger (the
object was further away), then the sciborg would increase its motor output.
This would enable the sciborg to “catch up” with the object it was following.
If the reading was small (the object was close), the sciborg would reduce its
motor output, giving time for the object to gain some distance.
Based upon our previous ultrasonic sensor range that we
experimented (5-10 cm = ~11; 40 cm = ~30), we chose our restrictions. For the
first, we targeted the middle range. We picked 15 and 20 as the boundaries. If
the ultrasonic readings were in between, the sciborg would travel at the
“medium” pace. As soon as the readings became larger than 20, the sciborg would
increase its speed to “catch up.” When the readings were smaller than 15, the
sciborg would be close and slow down.
This video shows how the speed of the motors decreased as an
object moved closer. There are 3 speeds, starting with the highest (readings
> 20). The sciborg rechecked every 3 seconds, and we had 1 reading in each
of the x > 20; 15 < x < 20; and x <15 ranges (in that order).
The method we used was neither bang-bang nor proportional
control. However, the feedback and control loop more closely resembled the
bang-bang control in that there was not a proportional scale relating the
readings and the motor outputs. Instead, a reading fell into one of three
categories and resulted in a specified output.
We tested this program out on the floor, and it worked!
However, when we began to videotape its progress, we encountered mechanical
problems with our ultrasonic sensor (see section below).
With our sensor not functioning and no one to consult at the
time, we thought we would try to play around with our code to make it better.
Our code completed the assigned task, but we thought we could modify it as an
extra challenge. We added a range of sensor readings which would cause the
sciborg to back up.
Although we already had a range in which the sciborg would
slow down to let the preceding object gain some distance, we thought that there
might be a case where a sciborg gets too close/or if the one before it somehow
malfunctions and goes in an unexpected direction. To avoid collision, we added
a section where if the readings get very small, the sciborg would reverse its
motors to back off and maintain distance between the two objects. We chose the
value of 13 to be the outer boundary for this restriction. For all readings
< 13, the sciborg would reverse its motors at a lower-medium rate.
Due to the problems with the ultrasonic sensor, we were
unable to run our program.
~~~
Ultrasonic sensor malfunction!
Just as we were about to videotape our conga line program,
we noticed that one of the leads from the sensor (the ground cable) had been
disconnected. This caused any reading to be consistent at the value 1023 and therefore invalidated our program.
The severed cable (shown on another sciborg with the same
problem):
We decided to try to fix this problem on our own. We got out
the solder and soldering iron.
We soldered the ground cable back on. The sensor returned
back to normal.
But only for a little while. The adjacent cord disconnected
as well.
We soldered it back on.
Our soldering jobs
However, after this adjustment, the ultrasonic sensor fluctuated in its readings and was inconsistent.
We hope to address this problem with someone more familiar
with the mechanics and get the sensor back to fully functional. Then we’ll run
our tests and watch the results!
No comments:
Post a Comment