During the winter session (IAP) of my sophomore year, I competed in the anual 6.270 Autonomous Lego Robotics Competition of 2012. The competition involved autonomously navigating a playing field using a visual tracking system, capturing territories by spinning gears, accumulating resources (ping-pong balls), and depositing them before the end of the round. With two other team members, I built and programmed the "Brave Little Toaster".
Here is a video of the entire competition.
This is one of the seeding rounds.
The autonomous Brave Little Toaster. Able to navigate, capture territories, acquire ping-pong balls, and deposit them while competing against another robot.
Building legos required a few hours to get used to. Reinforcements are vital to avoid falling apart when running into walls or other robots, dimensions have to line up, gearing has to be well supported to minimize friction, and the design of systems is preferably as simple as possible. We started with a wide, short base, for a few reasons. One, the gear boxes (one for each wheel) had many gears to provide the right gear ratio (about 120:1), necessary to provide enough torque to the wheels from fast spinning DC motors (by nature, DC motors have low torque and high speed because too many windings causes a large back emf, requiring a lot of power and causing a lot of dissipation through the coils). Each gear was supported on both sides by lego bars, so the gearing quickly became quite wide. Another reason we thought this would be favorable was to allow the drive to have a torque advantage. Having the wheels further apart would allow the robot to spin and turn faster. Lastly, we were limited on lego parts so the wide body had to be compensated by being short. Instead of using caster wheels, we just put two sliding contacts in the front and back of the base.
Here is a video of the entire competition.
This is one of the seeding rounds.
The autonomous Brave Little Toaster. Able to navigate, capture territories, acquire ping-pong balls, and deposit them while competing against another robot.
Building legos required a few hours to get used to. Reinforcements are vital to avoid falling apart when running into walls or other robots, dimensions have to line up, gearing has to be well supported to minimize friction, and the design of systems is preferably as simple as possible. We started with a wide, short base, for a few reasons. One, the gear boxes (one for each wheel) had many gears to provide the right gear ratio (about 120:1), necessary to provide enough torque to the wheels from fast spinning DC motors (by nature, DC motors have low torque and high speed because too many windings causes a large back emf, requiring a lot of power and causing a lot of dissipation through the coils). Each gear was supported on both sides by lego bars, so the gearing quickly became quite wide. Another reason we thought this would be favorable was to allow the drive to have a torque advantage. Having the wheels further apart would allow the robot to spin and turn faster. Lastly, we were limited on lego parts so the wide body had to be compensated by being short. Instead of using caster wheels, we just put two sliding contacts in the front and back of the base.
Other than the drive, the robot had three mechanisms. On the back, there was a gear driven by another DC motor. This gear spun gears mounted along the walls of the playing field in each territory for capturing purposes. On the front, there is a continually spinning lever that pulls a wall mounted lever, which activates a mechanism that drops ping-pong balls onto the roof carriage of the robot. This was powered by a servo hacked for continuous rotation. Finally, another servo opened a gate at the back of the slanted carriage, allowing the ping-pong balls to roll out into the depositing area.
The spinning gear on the back of the robot spins wall mounted gears on the playing field to capture territories.
A lever on the front of the robot pulls a wall mounted lever on the playing field to release ping-pong balls into the roof-top carriage.
After two days of building, it was time to start coding the HappyBoard controller (uses ATMega processor, much like an Arduino). Using a gyro and position input, coming from a visual tracking system (that is what the ID tag on the top is for), the first thing we coded was a navigation function. First, the robot set the gyro by acquiring an initial heading from the visual tracking system. Then, the gyro would take over the heading feedback (more accurate than the visual tracking system). A desired heading was calculated using a simple inverse tangent function between the desired location and the robots location. Using proportional feedback, the robot would spin to the desired direction within a specified tolerance. Then the motors would drive the robot in the desired heading, continually using more proportional feedback (using the angle error) to provide the right PWM to each motor that would keep it aligned in the correct direction.
In the video you can see some oscillations when trying to align to spin gears or acquire ping-pong balls. At the time, I did not have the knowledge to implement more advanced controls, but now I would do some analysis and introduce derivative control to reduce the time constant of the response. A zero in the correct location would pull the root locus more negative on the s-plane.
Next, we had to implement many functions to make decisions based on which territories had been captured or not, how many resources were in each territory, where the robot was, and where the opponent was. Autonomously, the robot could decide what it thought was the most optimal territory to capture next. At first, this was the territory which was closest, not ours, and had more than three ping-pong balls. After testing this against other robots, we ended up changing it last minute to the territory which was furthest from the opponent, not ours, and had more than three ping-pong balls. This was because we had so many problems colliding with the opponent, an unforeseen problem for many of the teams. Also, the robot decided when an optimal time to deposit balls was. Keeping it simple, we decided it was sufficient to just give the robot 10 seconds to perform this task at the end of the round, or when the carriage was overflowing (over 24 balls).
The spinning gear on the back of the robot spins wall mounted gears on the playing field to capture territories.
A lever on the front of the robot pulls a wall mounted lever on the playing field to release ping-pong balls into the roof-top carriage.
After two days of building, it was time to start coding the HappyBoard controller (uses ATMega processor, much like an Arduino). Using a gyro and position input, coming from a visual tracking system (that is what the ID tag on the top is for), the first thing we coded was a navigation function. First, the robot set the gyro by acquiring an initial heading from the visual tracking system. Then, the gyro would take over the heading feedback (more accurate than the visual tracking system). A desired heading was calculated using a simple inverse tangent function between the desired location and the robots location. Using proportional feedback, the robot would spin to the desired direction within a specified tolerance. Then the motors would drive the robot in the desired heading, continually using more proportional feedback (using the angle error) to provide the right PWM to each motor that would keep it aligned in the correct direction.
In the video you can see some oscillations when trying to align to spin gears or acquire ping-pong balls. At the time, I did not have the knowledge to implement more advanced controls, but now I would do some analysis and introduce derivative control to reduce the time constant of the response. A zero in the correct location would pull the root locus more negative on the s-plane.
Next, we had to implement many functions to make decisions based on which territories had been captured or not, how many resources were in each territory, where the robot was, and where the opponent was. Autonomously, the robot could decide what it thought was the most optimal territory to capture next. At first, this was the territory which was closest, not ours, and had more than three ping-pong balls. After testing this against other robots, we ended up changing it last minute to the territory which was furthest from the opponent, not ours, and had more than three ping-pong balls. This was because we had so many problems colliding with the opponent, an unforeseen problem for many of the teams. Also, the robot decided when an optimal time to deposit balls was. Keeping it simple, we decided it was sufficient to just give the robot 10 seconds to perform this task at the end of the round, or when the carriage was overflowing (over 24 balls).
Shopping used is a great alternative to long waiting lists and inflated prices, especially since the number of resources available to buyers grows on a regular basis. webuyanyspaceship.com
ReplyDelete