Team Two/Final Paper

From Maslab 2011

(Difference between revisions)
Jump to: navigation, search
(Team Members)
(Software Design)
Line 83: Line 83:
On top of abstracting out sensors, we also abstracted out everything else, including images, color statistics, and the on buttons, and had a function for just about everything.  This is perhaps excessive, and in the end, we had over 9000 lines of code, but it also came in useful again and again.  During our numerous testing sessions, we were able to easily fix most issues because all the functions were already available.
On top of abstracting out sensors, we also abstracted out everything else, including images, color statistics, and the on buttons, and had a function for just about everything.  This is perhaps excessive, and in the end, we had over 9000 lines of code, but it also came in useful again and again.  During our numerous testing sessions, we were able to easily fix most issues because all the functions were already available.
-
===Multi-threading===
+
In addition, instead of trying to predict all kinds of situations our robot could be in, we interspersed our code base with the use of randomness and heuristics.  For example, if we don't know whether to turn left or right, we will sometimes randomly generate a direction.  If we don't know how much we've turned since the last iteration through a loop, we will make a reasonable guess. 
-
cathy
+
-
issues?
+
-
===States===
+
===State Machine and Robot Behaviors===
-
cathy
+
-
what states
+
We used a simple state machine design that heavily relied on vision.  By default, the robot spins in place scanning the surroundings for balls or scoring walls.  Detecting respective objects allows the robot to transition into its ball fetching or scoring behaviors.  A timeout into a wall following behavior allows us to roam into new regions to find more objects.  All behaviors default to scanning for objects. 
-
timeouts
+
Our behavior for obtaining a ball involves lining up to the ball, getting closer to the ball, and then charging it for a short duration.  We charge to make up for the complete lack of information when we are too close to a ball for the camera to be useful.  This has worked well for us, since it is fairly accurate and also captures balls quickly. 
 +
 
 +
Our behavior for scoring involves lining up to a scoring wall, moving towards the scoring wall until the appropriate bump sensors trigger, extending the hopper to dump the balls, and retracting the hopper.  Due to the placement of our camera, when the robot is flush with a scoring wall, the camera will only see the blue tape, so we have also added in a
 +
 
 +
===Time and Ball Count===
 +
 
 +
We leveraged some time and ball count information to help robot performance.  In the first 30 seconds of a round, our robot does not attempt to score, so that it can collect the easy balls.  In addition, each ball that the robot obtains allow it to wall follow for more time.  The idea is that with fewer balls on the field, the robot should be given more time to explore in order to increase its likelihood of finding new things.
 +
 
 +
===Controller===
===Vision===
===Vision===

Revision as of 03:27, 26 January 2011

Contents

Team Members

  • Leighton Barnes - Course 18, 2013 - Focused on sensor design and electrical work. Instrumental in debugging robot in all disciplines.
  • Cathy Wu - Course 6, 2012 - Focused on major software components: vision, testing suite, multi-threading, ball collection and scoring behavior. Managed day-to-day activities and big picture plans for the team and made sure things got done.
  • Stanislav Nikolov - Course 6, 2011 - Focused on major software components: overall architecture, wall following, stuck detection.
  • Dan Fourie - Course 2, 2012 - Focused on mechanical design. Got things done extremely quickly.

Overview

Mechanical Design

Our robot was designed for robustness and reliability. The robot serves as a reliable platform for the vision and control software systems. As such, it should be sturdy, constructed quickly, have extremely low mechanical failure rates, be able to withstand hours of testing, and be robust to positioning errors. The robot's structural members were built primarily from 1/4" acrylic sheet. It utilizes a rubber band roller powered by a DC motor to collect balls and 4-bar linkage hopper actuated by another DC motor to get balls over the wall. DC geared motors will drive no-slip wheels.

Drive System

The high level design of the robot's drive system consists of three structural boxes secured together in a line. The two outside boxes contain the direct-drive motors, which are mounted to aluminum plates for strength. The central box forms the majority of the rest of the robot's structure and primarily contains the hopper. The three boxes are fastened together with steel brackets (to leverage the powers of the laser cutter and to avoid excessive tapping) and locknuts (to ensure the final assembly did not disassemble).

Toothed no-slip wheels were chosen to minimize slipping on the playing field carpet. This condition proved effective in increasing the speed of the robot and in stalling the drive motors to provide current feedback for stuck detection. The wheels were not perfectly no-slip however, and did not stall in all cases, which was specified in the initial design to obviate the need for bump sensors. The wheels were cut from 1/8" aluminum plate on an abrasive waterjet machine.

Steel hubs were precision machined to provide a stiff, reliable coupling between the motor shafts and the wheels. They also allowed the wheels to be placed as close as possible to the motor in order to decrease torque on the gear boxes.

Electronics Mounting

Electronics were mounted to the robot with the goals of rigidity, interchangeability, and adjustability where necessary.

The EeePC was completely disassembled in order to determine the best way to securely mount it to the robot. It was decided to remove the extraneous monitor and keyboard, but to retain the hard, white motherboard shell to protect the sensitive components. While other teams utilized tape or Velcro, our netbook is bolted to an acrylic plate and shock mounted (with foam padding) to an angled back plate.

In addition, the Orc Board was secured to its own acrylic plate and provided with a protective cover to ward off balls possibly fired from the other side.

The webcam was removed from its plastic housing and the PCB was potted in epoxy and attached to an acrylic backing plate. These adjustments saved an enormous amount of space and allowed the camera to be positioned in the ideal location on the robot. The camera angle was also adjustable which proved valuable in eliminating the need for blue line filtering.

The bump sensor suite

limit switches

battery slot

encoders

Scoring Mechanism

4 bar linkage

rubber band roller

stage 1
stage 2
stage 3

Electrical Design and Sensors

Motor Controllers

Because our robot design required four motors (2 drive motors, 1 to pick up balls, and one to score them) and our Orc Board only features three H-bridges, we had to design an additional circuit to control the last motor. The motor that drives the roller in the front to pick up balls only had to go in one direction, so we chose that one as the one that would be driven by this addtional controller.

Our first attempt at this additional controller was just a 40N10 power FET whose gate was driven by the digital out of the Orc Board (with a protection diode accross the motor of course). As we learned with this first attempt, the digital out of the Orc Board is somewhere around 3.7V, instead of the nominal 5V, which could barely overcome the 2-4V gate threshold voltage of the FET (or any other power FET we had on hand). Instead of spending the time to build a gate driver to get around this problem we tried an L298 H-bridge package instead. This worked with the logic-level voltage provided by the Orc Board although we stuck to one directional capability in favor of using the standard four protection diodes instead of one.

Batteries

Throughout the build period Dan and Leighton continued to investigate different battery options and even contruct multiple different kinds of battery packs. The input from previous teams' papers suggested that a high voltage (18V or so) NiCd pack from a cordless power tool was the ideal battery. This type of pack was lighter and had a much higher power density than the standard lead-acid pack. In past years, the increased voltage and power-density such a pack offers would have been a huge plus, but this year we were given adaquately powerful drive motors even when driven at the standard 12V. We found that our NiCd packs ran down much too quickly with their 1.7Ah while the standard lead-acid pack, which was rated at 8.7Ah, could last while testing for hours on end. We also briefly tested a pack of four 3.3V A123 cells which seemed like it could have been the perfect choice. The pack was rated at 2.2Ah, was lightest out of all of them, and dumped as much power as we wanted on demand, but it was a pain to charge. We had access to a charger, but not one that we could take with us anywhere.

Sensor Choice

bump sensors

break-beam

encoders

IR range-finders

gyro (or lack thereof)

Software Design

Overview

Our software architecture emphasized simplicity and modularity. For the operation of our robot, we used a simple state machine that was mainly driven by a focus on speed and vision. Within each state, we also performed stuck detection and also additional actions if bump sensors were triggered.

We wrote classes that abstracted out each and every type of sensor we used and we forked a thread for each type to record and process readings. During a run, there are about 10 threads running.

On top of abstracting out sensors, we also abstracted out everything else, including images, color statistics, and the on buttons, and had a function for just about everything. This is perhaps excessive, and in the end, we had over 9000 lines of code, but it also came in useful again and again. During our numerous testing sessions, we were able to easily fix most issues because all the functions were already available.

In addition, instead of trying to predict all kinds of situations our robot could be in, we interspersed our code base with the use of randomness and heuristics. For example, if we don't know whether to turn left or right, we will sometimes randomly generate a direction. If we don't know how much we've turned since the last iteration through a loop, we will make a reasonable guess.

State Machine and Robot Behaviors

We used a simple state machine design that heavily relied on vision. By default, the robot spins in place scanning the surroundings for balls or scoring walls. Detecting respective objects allows the robot to transition into its ball fetching or scoring behaviors. A timeout into a wall following behavior allows us to roam into new regions to find more objects. All behaviors default to scanning for objects.

Our behavior for obtaining a ball involves lining up to the ball, getting closer to the ball, and then charging it for a short duration. We charge to make up for the complete lack of information when we are too close to a ball for the camera to be useful. This has worked well for us, since it is fairly accurate and also captures balls quickly.

Our behavior for scoring involves lining up to a scoring wall, moving towards the scoring wall until the appropriate bump sensors trigger, extending the hopper to dump the balls, and retracting the hopper. Due to the placement of our camera, when the robot is flush with a scoring wall, the camera will only see the blue tape, so we have also added in a

Time and Ball Count

We leveraged some time and ball count information to help robot performance. In the first 30 seconds of a round, our robot does not attempt to score, so that it can collect the easy balls. In addition, each ball that the robot obtains allow it to wall follow for more time. The idea is that with fewer balls on the field, the robot should be given more time to explore in order to increase its likelihood of finding new things.

Controller

Vision

cathy

color calibration

data structures

down sampling

goal filtering

botclient

documentary mode

Wall following

stan

Stuck detection

stan

Testing

Testing suite

cathy

Mechanical Issues

ball jamming

eeepc access

battery placement

bump sensor coverage

pins falling out

motor failing

Failure modes and Countermeasures

Electric Issues

leighton

single-conductor wire and broken connections

uORC sample rate

power for fourth motor

Software Issues

cathy & stan

multi-threading

ball jamming

wall following

stuck detection

Performance

Suggestions

  • Form a team early and commit to doing MASLAB for all of IAP. We formed our team before the start of the school year.
  • Have a well balanced team. It's important to cover all grounds with software, mechanical, and electrical. Our 2 software + 1 mechanical + 1 electrical combination balanced us very well.
  • Work really really hard and stay motivated. We pulled endless all-nighters and never gave up. We continued to pester the staff mailing list with questions and even took a day to set up some legit practice fields in 26-100 before the seeding tournament.
  • Start before IAP and aim to have most of everything done in the first 2 weeks of IAP. Because we did most of the design before IAP, We managed to have a functional robot (not the pegbot) by the first mock competition, which helped us out greatly. We also were able to spend the last week and a half making fixes for various edge cases and had time to just polish up things.
  • Test often and relentlessly. You'll find something wrong with your robot every time.

Photos

Error creating thumbnail:
libgomp: Thread creation failed: Resource temporarily unavailable
Screenshot of CAD model finalized before IAP
Personal tools