Team Thirteen/Journal
From Maslab 2007
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Monday, 8th January
received basic instructions and assembled Kit today. The soldering took a while and the small resistors were especially tricky. Thanks to Adam and his multitool keychain, we were able to put everything together. Running the robot turned out to be easier than we thought since most of the relevant coding was provided.
Tuesday, 9th January
we started work on our design. After some brainstorming, we decided on a circular base which is capable of pivoting about its center. We also decided to mount the camera on a mast and angle it downwards such that it sees part of the robot at all times. This is meant to help with visually finding distance. We also came up with an idea for capturing balls. A motorized revolving door type contraption captures the balls into a tube and release them when rotated the other way. We also calibrated the IR sensor and completed the assignment for today which involves stopping the robot within 6 inches of an obstacle. One issue we encountered was that the base of our robot is angled so that the IR sensor beam is not parallel to the floor. This might cause problems with accurately assessing distance. Tomorrow, we will fix the robot so that the base is parallel to the floor. Upcoming tasks include calibrating other sensors and dimensioning our design.
Wednesday, 10th January
a lot of coding work was done today. The bot now recognizes red balls individually and turns towards the closest one and approaches it. We have decided to lower the height of the camera as its field of vision is only 20° in all directions. If mounted high up, it will miss balls that are close by. Physically, the robot was taken apart and put back together. The wheels are now centered so that the robot pivots about its CG. The robot is also parallel to the floor. The fourth member of our team is also now in town and we are developing ideas for search algorithms. We plan to test out our capture method tomorrow to see if the concept works. Now I'm off to write up a summary of our design for tomorrow's checkpoint.
Thursday, 11th January
retested algorithms for checkpoint. Had to calibrate ball distance from robot. Details of our checkpoint proposal including drawings can be found here: Media:Maslab_checkpoint_one.pdf. Also started work on putting together a demo of the capture mechanism. Decided to use a servo motor for this and wrote the appropriate control program. Adam is working on the gearbox for this.
Checkpoint done.
Algorithm-related plans: we'll test sensors, gyros, and try to get capture mechanism working soon, since some aspects of the algorithm will depend on that (e.g. if we can get good dead reckoning, we'll probably go with mapping-type algorithm. Without good dead reckoning it would be more complicated and possibly not worth it). Once we know how sensors work, we'll be able to write out details of algorithm to try. (meanwhile we're developing aspects of the algorithm that don't depends as much on dead reckoning and ball capture mode).
Gyro tested - eventual accuracy after we compensate for a couple of things, it looks like we'll be able to get very good accuracy (within a few degrees at worst).
Long-range IR tested - good accuracy as well, so we will likely mount one or a few on a robot to help with mapping out walls (camera can be used for that too).
Friday, 12th January
more work on the capture mechanism today especially the gearbox. Also working on algorithms for searching for an approaching balls.
Adam built a capture mechanism out of Lego for testing.
Saturday, 13th January
No meeting.
Sunday, 14th January
No meeting.
Monday, 15th January
MLK Jr. Day.
Tuesday, 16th January
the soldering on our gyros wires came off. The gyros had to be rewired which delayed its testing. We attempted standing turns by using the gyros for the angles. We had some trouble with this and then discovered the problem with the gyros.
Also the orientation of the battery in the robot was changed because of weight issues and the camera was mounted in such a way that it just saw them the edge of the robot.
Wednesday, 17th January
discovered that the gyros feedback is too slow to do long turns accurately. Therefore, we decided to do short turns based on the time it took to turn. We calibrated the gyros do get the angle turned in a certain time. A code was then written to perform short turns. The straight driving algorithm was also revised.
We decided to add four long-range IR sensors to the robot: two for aligning with the goal and two for avoiding wall collision. These were wired up.
Thursday, 18th January
Adam added "Lego-built ball capture mechanism" (beta) to robot undercarriage. The DC motor used to actuate the mechanism is mounted on the top side of the robot platform. A gear train interfaces the motor with the turnstyle mechanism ensuring that adequate torque is available as well as providing synchronous rotation of the left and right halves. The motor will be supplied with a PWM signal from the orcBoard allowing the speed of rotation (and thus the speed of capture) to be varied as to match the robot's forward speed.
Checkpoint complete.
Early concept design elements.
Friday, 19th January
Interfaced and tested ball capture mechanism drive with orcBoard. Remounted battery, camera, and computer with hot glue (upgraded from zip ties). Roughly positioned and mounted long range IR sensors on robot using shims and hot glue. The sensors are mounted 6" back from the front edge of the robot. Two sensors are on the extremed right and left edges of the base platform and face directly forward. Another two sensors are angled 15 degrees outward from either side of the centerline as to cover the periphery of the camera's view angle.
Saturday, 20th January
No meeting.
Sunday, 21st January
No meeting.
Monday, 22nd January
Pictures of Pegbot (the prototype robot) in its current form.
Front view.
Overhead view.
Right side view.
Undercarriage view.
Sponsor Diner.
Modeled parts for final design in ProEngineer. The final base will have a 14" diameter and place most of the weight in the rear. The front half of the circular base will be for the ball capture mechanism.
Tuesday, 23rd January
Made full scale template of circular base platform using cardboard. The potential positions for the computer, battery, wheels and ball mechanism were measured and indicated.
Wednesday, 24th January
Made circular wooden base out of plywood. Layout was transfered from cardboard template to plywood and cuts were made using a saber saw (water jet CNCs aren't as fun).
All components were transferred from the pegboard to the plywood base. The computer, battery, camera, orcBoard, and orcPad were rearrange so as to shift the center of gravity down and towards the center of the circular chassis. While most of the weight is still at the rear of the chassis, this isn't a concern structurally or performance-wise. With regards to the former the (.25" thin) plywood is supported by a spherical caster at the rear and the drive motors at the middle. With respect to the handling, the robot doesn't seem to have issues fish-tailing (even at full speed) due to the "junk in its trunk".
Checkpoint complete.
The ball storage needs to be addressed as well as the installation of the long-range IR sensors.
Thursday, 25th January
The quad-phase encoders were acting up. Upon inspection it was determined that some misaligned phototransistors were to be blamed. After straightening out the culprits we were back in business...for now...
The encoder patterns were upgraded to the high-res versions.
It later became apparent that the left and right encoders weren't in agreement when the robot was commanded to drive straight. After some experimentation, it was found that the straightened phototransistors did not align properly with the wedges on the encoder pattern.
A temporary metal "fence" was installed in lieu of our final storage design to keep balls from rolling out from underneath the robot once they were captured.
Two forward-facing long-range IR sensors to be used for aligning the robot with the goal were also installed at the far left and right tips of the robot's platform.
Friday, 26th January
Encountered further problems with the encoders. They seem to be working intermittently. Plan to use new encoders to eliminate this problem.
Sheet metal was obtained to construct a chamber for holding collected balls.
New encoders were assembled, installed, and tested. The left wheel continued to give erroneous numbers despite the new hardware. After checking the code and trying different ports on the orcBoard, it was found that ports 2 and 3 for the quad phase encoders were faulty. Both encoders now occupy ports 0 and 1. It is likely that the previous behavior (blamed on other hardware) was instead caused by ports 2 and 3 working intermittently, rather than the blamed hardware. We did test the ports theory early on, by changing encoders from "0 and 2" to "1 and 3"... and thought we eliminated ports as a source of error since the behavior was the same, and we didn't think two ports could fail.
Saturday, 27th January
Made full scale cardboard template for ball storage container.
Transferred measurements from cardboard template to aluminum sheet metal (freebie).
Used nibbler, tin snips, hand shear, hand brake, and hammer to beat-the-sheet into submission (the hand brake proved almost useless since it lacked rigidity and wasn't big enough for most of the bends).
Installed the container on the bottom of the chassis. In most respects it was a perfect fit, however the bends made using a hammer had larger radii than if they'd been made using a brake. The result of this was that the ball container extended below the rear caster and didn't slope towards the front of the robot as steeply as initially planned. To rectify the former, a piece of cardboard was used to shim the rear caster of the robot so it would make ground contact below the bottom of the container.
Re-glued the long-range IR sensors to the top of the platform (they had fallen off).
Sunday, 28th January
Removed long-range IR sensors so that they may be repositioned 10" back from the front tip of the circular base.
Tweaked the ball container by raising its front edge. This was necessary to allow adequate clearance when passing over bumps in the carpet. This had the adverse affect of decreasing the containers slope (so balls were less likely to roll towards the front of the container for scoring) and making it more difficult for the capture mechanism to push balls in.
Reshaped the ball container's leading edge profile. The are two protrusions that are shaped like skis. When a bump is encountered, the "skis" lift the front of the container, preventing sharp edges from catching on the carpet.
Raised camera ~0.75" and moved it back ~0.75" so that it no longer sees the front edge of the circular base and the range of view falls just below the walls' blue lines.
Monday, 29th January
Added bumpers to constrict the passage through which the balls travel after being captured. This corrected a problem where two balls could potentially become stuck in the passage.
Further tweaked the ball container to increase the slope. This was done to permit the balls to roll from the rear of the container to the front where they could be ejected by reversing the capture mechanism's direction of rotation.
Robot photo shoot.
Cut a recess in the center leading edge of the ball container's sheet metal. It is now easier for the turnstyles to push a ball onto the incline.
By now mapping (wall finding) based on camera works fairly well.
Tuesday, 30th January
The final mock contest was today, however the robot was not in working order to compete. Efforts are being made to merge the code for all of the robot functions (driving, mapping, collecting, etc.) into one executable. Dmitriy has been handling the herculean task of covering all software duties until Anna returns.
Wednesday, 31st January
Added four mechanical bump sensors (two at front, two at rear) to serve as a fail safe in the event the robot accidentally collides with a wall. The sensors are comprised of momentary SPDT switches with sheet metal extensions to increase the span over which contact can be made. The sheet metal extensions are 6" long by 0.75" wide strips of aluminum with curvature along both long and short axes. The radius of curvature along the short axis proves flexural rigidity, while the curvature along the long axis matches that of the robot's chassis. The sensors are connected to four digital I/O ports with the appropriate 10k pull-up resistors on the +5V leads. The bump sensors still have to be interfaced in the software. Anna is back with a vengeance and burning up the home row now that it's crunch time.
Mr. Whiskers (Front view)
Mr. Whiskers (Right side view)
Mr. Whiskers (Left side view)
Mr. Whiskers (Top view)
Thursday, 1st February
The Final Day. The robot will be impounded this evening. Anna and Dmitriy coded all day long in a final attempt to get the robot working. The camera "pitch, roll, and yaw" angles were trimmed and set using hot glue.
The robot maps correctly (it can detect walls at quite a long range), and the algorithm figures out waypoints to drive to correctly, but the driving part, which should be easier, does not work.
Here is a sample map ('W' means wall, 'U' means uncertainty. '.' means likely a floor tile (not important for driving, but important to determine what robot will explore. This run had robot using "explore" rather than "pick up balls" function. 'X' is robot's position, 'b' and 'x' are balls (depending on confidence, and floor status. Each ball is placed in 9 squares to compensate for possible error in future mapping, so the picture below has 2 balls):
. .. .. .. ...
. . . .. ...
WW . .. .. ....
WW .. . .. ....
... .. .. .. ... .
WW. .. .. .. ... ..
WW W W... . .. . ... ...
.WWWWW .... . .. .. ... ....
...W.WW WW... . . .. ... ....
.......WW.... .. .. . .... ....
............ .. . .. ... ...
............ . .. .. ... .... .
............ . . . ... ... ...
........... . .. .. ... .... .....
.......... .. .. .. ... ... ......
.......... .. .. . ... ... ......
........W . .. .. ... ... ......
......... . . .. ... ... ......
.bbx....WW. .. .. .. ... ......
bxb.....W. . .. .. ... ......
bxb.....W. .. . ...... .....
.......W . .. ...... .....
W......WW.... ..... ..... .
W.......W. . W.... ..... .....
W....bbbW... .W.. ..... .........
W....bxbW.. ...W...... ..............
W....bbbWW .....W.. ..................
W........WW.....W .................
W.........WW....W ...............
W..........W....W..........
WW..........WWW..W...
W.....X.....W.WW.W
........WW...........W.WW.............................
..................W ..W.WW...........WWW .............
............. ...... .WWW..........WW .............
....... ....WW.........W ..
...... ..... WW.......WW
W ... ...... ..........W
....... ..........WW
... .. WW.......WW
.... ... ........WW
.... ... ........WWUU
... ... ...........U
.... ... ...xxx......UU
.... .. ...xxx.....W.U
.... ... ....xxb.....W.
.... .. ............WWW
.... ... ..W...........W
This (walls) looks very much like the playing field, including, amazingly, the wedge of the top, that is ~12 feet away from the robot. There are a few "extra" walls on the left, but they have low confidence (due to being far away), so once robot gets close they'll be replaces by whatever it sees there, so they won't cause the problem. (In a "normal" run robot only pays a lot of attention to walls it has seen from more or less up close. But the bigger map that shows what it thinks it sees is likely more interesting).
The DP-type algorithm (an adapted A-star algorithm), given direction to drive to unknown while avoiding walls (and a penalty for being close to walls), gives the following way points:
Path to way point: 9.0 , -27.0 cost: 1508.6048916900277
Path to way point: -9.0 , -57.0 cost: 1254.9558132621592
Path to way point: -21.0 , -75.0 cost: 1072.9354881259915
Path to way point: -33.0 , -69.0 cost: 1000.0
(way points are in inches, one map " letter" is 6 inches, first coordinate is left-to-right, second is top-to-bottom) -- this does look like an optimal path.
Then driver is engaged, and after the first way point the robot promptly proceeds to run into a wall (in this case it thought it drove 30 inches from way point 2 to 3, but I'm fairly sure (didn't write it down at the time) it drove a much longer distance. Thus we suspect another encoder problem (which would also explain why we had trouble with ball capture, which worked better 1-2 weeks ago than it does now).
Friday, 2nd February
Competition Day.
Saturday, 3rd February
Mr. Whiskers was disassembled into his component parts and his computer was returned to the staff. Final lab clean-up.
