Team Eleven/Journal
From Maslab 2007
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 |
| Team Eleven’s Journal |
TO DO LIST 012607
goal
goal
hardware
make the robot work
software
make sure the hardware work lol
long term plan
useful links, check often
plan A
1/12 today
1/19 mockcontest1(optional)
this one is optional, but still it will be nice if we can have our robot join the festival.
things to do:
turn the design into prototype. the prototype should be capable to:
[mechanical features]
pick up ball
release ball
[control features]
drive straight using gyro
avoid wall using ir combo
detect stuck using bump combo
[vision features]
locate ball
locate goal
detect stuck
1/25 mockcontest2(mandatory)
based on the results we got from mockcontest1, our final version should be done before mockcontest2.
things to do:
[hardware]
adjust bump sensor combo
[software]
fine tune the algorithm
1/30 mockcontest3(mandatory)
minor tweaking, clean up
2/1 impounding
get excited
plan B
1/12 today
1/25 mockcontest2(mandatory)
things to be done:
turn the design into prototype. the prototype should be capable to:
[mechanical features]
pick up ball
release ball
[control features]
drive straight using gyro
avoid wall using ir combo
detect stuck using bump combo
[vision features]
locate ball
locate goal
detect stuck
1/30 mockcontest3(mandatory)
based on the results we got from mockcontest2, our final version should be done before mockcontest2.
things to do:
[hardware]
adjust bump sensor combo
[software]
fine tune the algorithm
2/1 impounding
minor tweaking, clean up
plan C 012607
neither plan A and plan B happened
here's the last[hopefully] possibility
1/26 today
1/29 checkpoint
being able to goal
1/30 mockcontest3(mandatory)
kickbot should behave itself
2/01 impounding
hang out
Monday, Jan 8, 2007
Well day one - let the fun begin
Got our bot parts - Began putting it together
Brainstorming begins
Problem - picking up balls - Archimedes Screws???
Arm??? sucks
Revolving Door
Jim and Feng's basketball robot idea
Vacuum Idea (the more it sucks, the less it does)
Gyroscope???
Encoder - for speed
Use vision and frame changes to determine speed
Feng - principles of motion
Bayo - How do speedometers work
Map idea - Girraffe neck robot idea - telescopic neck
- IR sensors on left and right and follow wall
Tusday, Jan 9, 2007
Finished robot prototype installed IR sensor Wrote new program testing ir sensor - YAY it WORKS Built encoder for determining velocity of wheel - encoder finished - testing in progress
Wednesday, Jan 10, 2007
Lecture - FUN - cool dood with robot controls and bloopers Brainstormed for quite a while about plans for the robot's control system, vision algorithms, etc. Divided up work between software and hardware
The first attempt at red ball finding and blue line filtering:
Checkpoint One
Team 11 Robot Kick Ass Proposal
1.0 Strategy
1.1 Find the ball/goal
Turn the camera on a servo. Survey the environment. Locate the target. Make a decision of where to go.
Servo control: Turn 360 degrees.
Take pictures of good quality.
Analyze pictures: Recognize balls, walls and goal; Determine the distance between the objects and the robot.
Make decision: Find the direction to the closest ball/goal.
1.2 Go to the ball/goal
Go straight towards the ball/goal.
When the wall is on the way
Avoid the wall first, turn the camera to keep track of the ball, then go straight to the ball. Use IR sensors to avoid the wall. Turn camera according to the angle the robot has turned from the gyroschope to keep track of the ball.
1.3 Pick up/release the ball
Use a rake to get the ball in a storage place
A ball comes within range of the robot.
The rake pushes the ball into...
...the storage place.
Once the robot gets close to the goal, it opens up the back gate allowing the balls to roll into the goal.
2.0 Design
2.1 Hardware(28pts)
2.1.1 Motors
Drive motor * 2
Servo * 5 (25pts)
2.1.2 Sensors
Webcam
Gyroscope
2.2 Software
2.2.1 Orcboard Control
Robot control is event-based. For testing purposes, we have created one thread for monitoring sensors and one for buttons/joystick on the OrcPad. In addition, there is a thread for visual processing. All button-up and down actions trigger an event. However, the OrcPad-related thread won't be implemented in the final version to save CPU time (the robot should be autonomous anyway, so we don't need any human input during the competition). Visual processing is done on a separate thread, which runs simultaneously with sensors monitoring. The two are connected to a mediator deciding what action to take. The mediator prioritizes sensors in order to avoid situations, for example, when the robot sees a ball ahead of it but cannot move after one of its sides hit a wall.
2.2.2 Vision
The locating of multiple red balls and collection of relevant statistics has already been implemented using an amazingly efficient connected component analysis algorithm that relies on a decision tree and an equivalence vector to improve its speed. The algorithm currently only does one sweep of the image while managing to label almost every single pixel correctly. Depending on how critical the time performance of the algorithm turns out to be once we get the code running on the robot, a second sweep of the image (most likely in the reverse direction) may be added. The code is running unexpectedly quickly.
There is also basic blue line filtering code in place, although the conceptual approach needs to be modified a bit. In particular, the tolerance for small columns of blue pixels needs to be increased.
Thursday, Jan 11, 2007
Overlapping balls?
The robot should behave properly in all situations. It cannot go crazy when it comes across something unexpected, therefore we are working to maximize the robot's consciousness of the world around it. One of the 'extreme' conditions occcurs when there are two or more balls overlapping. Such a situation could possibly give fake distance measurements as well as cause a number of different problems. We can't let this happen. After a brainstorm and some research on separating overlapping objects, we came to a conclusion that a separation algorithm is CPU-intensive and therefore it should be applied to frames only when necessary. Necessity is the mother of invention - we developed a simple yet fast and effective algorithm for telling if a 'red blob' is a single ball or a few balls overlapping. Due to its statistical character, it is relatively noise resistant and its tolerance can be adjusted. Below are some sample images. Enjoy!
Classified as: Single
Classified as: Overlapping
Design
Here is our first sketch of the robot.
This is another view, showing each of the "floors" of the robot.
Friday, Jan 12, 2007
Blue Line Filtering
The rash first attempt at blue line filtering was rewritten more carefully and the results have improved as expected. The biggest question is how to optimize the algorithm (because scanning for a column of blue pixels requires scanning down a column which is slow). Obviously there are also plans to preserve the parts of the goal that were erased in the images below.
Software Overhaul
Today saw great progress on the software side. Code to efficiently and accurately find the centers of overlapping balls is almost finished and the software controlling the basic functionality of the robot has been hooked into the OrcBoard API and has been totally restructured to make life more supremely awesome in the future!
Saturday, Jan 13, 2007
To be (red) or not to be?
The isRed function provided in the vision tutorial is completely ineffective when it comes to changing lighting conditions and other environmental factors. We have been working on a different approach, which utilizes an artificial perceptron neural network to compute the parameters which our new algorithm uses. The values can be computed on any computer and then plugged in directly into the robot. This gives the overhauled isRed function a speed comparable to that of the original one (without the overhead of converting the image to HSV). Below are the algorithm's results for sample Maslab images as well as some completely random ones. The NN was not trained on these images so they reflect how the algorithm would perform in a real world setting. Enjoy!
These two didn't want to upload correctly for some reason, so here are the links:
Before After
Sunday, Jan 14, 2007
Colorspaces Revisited
Independent comparison of yesterdays ideas about using RGB instead of HSV show that the ease of use is not even comparable. Identifying a pixel in RGB requires a third fewer parameters and a third fewer boolean statements to be evaluated while also not incurring the overhead of converting the entire image to HSV. Sweet!
Development Continues
The Prototype Is Coming
Here is a 3D model of our prototype.
Tuesday, Jan 16, 2007
Development continues. PID controller gives an error of approx. 0.2%, although we would like to make turning a little faster. Also, we are working on mapping which will rely primarily on the camera. More info soon.
Wednesday, Jan 17, 2007
The protype did it's job. We found lots of things that went wrong or that COULD go wrong during the competition. For example, design v1.0 squeezed the ball against the ground instead of pushing it in. Other problems were that the robot was too jitery and might fall over, and that the motors took up too much space!
After a long redesigning period, version 2.0 of the robot is out.
KickBot v2.0
1st Floor
2nd Floor
3rd Floor
Views
Wednesday, Jan 24, 2007
due to the excessive abuse of servos, we managed to avoid wall with camera
and barcode mapping strategy is being practiced
Thursday, Jan 25, 2007: KickBot II died.. here KickBot III comes!
to be continued
Monday, Jan 29, 2007
got a new orcboard and fine tuned the structure. kick bot iii is ready to rock ;)
