LogoLogo
  • Welcome!
  • Mission Statement
  • Contributing Guidelines
    • Embed CADs in Wiki Articles
  • VEX Worlds Livestream Archive
    • VEX U
    • V5RC High School
    • V5RC Middle School
    • VIQRC Middle School
    • VIQRC Elementary School
    • JROTC
  • ⚙️Hardware
    • Design Fundamentals
      • Gear Ratios
      • Internal Forces (Stress)
      • Torque
      • RPM
      • Center of Mass
    • Introduction to VEX Parts
      • Structure
        • C-Channels and Angles
        • Fasteners
        • Retainers
        • Gussets and Brackets
        • Bearings
        • Plate Metal and Flat Bars
      • Motion
        • High Strength Components
        • Gears and Sprockets
        • Traction Wheels
        • Mecanum Wheels
        • Omnidirectional Wheels
        • Flex Wheels
    • Robot Decorations
      • Part Dyeing
      • Metal Coloring
      • License Plate Holders
    • Lifts
      • Double Reverse Four Bar (DR4B or RD4B)
      • Four Bar
      • Scissor Lift
      • Six Bar
      • Other Lifts
      • Best Practices
    • Shooting Mechanisms
      • Catapult
      • Flywheel
      • Linear Puncher
    • Drivetrains
      • Tank Drive
      • Mecanum Drive
      • Holonomic Drive
      • Designing a Drivetrain
      • Best Practices
    • Pivots & Joints
    • Pneumatics
      • Best Practices - Pneumatics
    • Intakes
    • Flip Out Mechanisms
    • Defensive Mechanisms
    • Misc. Building Techniques
    • VexU
      • Common Manufacturing Techniques
        • 3D Printing
        • Laser Cutting
      • Custom Manufactured Parts Library
      • Commercial Off The Shelf Parts Library
  • 👑Team Administration
    • New Team Resources
      • Creating The Team
      • Gaining Interest for Robotics Teams
      • Attending Competitions
        • Elimination Bracket
    • Team Dynamics
      • Organization Structure and Longevity
      • Member Allocation and Management
      • How *Not* To Run a Team
    • Team Finances
      • One-Year Team Financial Breakdown
      • Funding Your Teams
    • Hosting Competitions
      • Live Streaming
      • Tournament Manager
        • Competition Electronics
        • Creating a Tournament
        • Tools
          • Field Set Control
          • Connecting Mobile Devices
          • Connecting Raspberry Pis
        • Match Control
          • Inputting Match Scores
          • Inputting Skills Scores
          • Inputting Scores on TM Mobile
        • Displays
        • Alliance Selection
      • Additional Event Partner Resources
    • VexU Organization Management
      • Getting Started in VexU
      • Team / Personnel Management
      • Volunteering At Local Events
  • 📚The Judging Process
    • The Engineering Design Process
      • Test and Refine
    • The Engineering Notebook
      • Segments of the Notebook
      • BLRS2 '23-'24 Engineering Notebook
      • Integrating Inventor Models into Documentation
      • Engineering Notebook Rubric Breakdown
    • The Interview
      • Interview Rubric Breakdown
    • Using Notion for an Engineering Notebook
      • How to Setup a Notebook
      • How to Create Entries
      • How to Export a Notebook
      • Purdue SIGBots Notion Template
        • Game Analysis
        • Identify The Problem
        • Brainstorm Solution
        • Select Best Approach & Plan
        • Build Log
        • Programming Log
        • Testing Solution
        • Tournament Recap
        • Innovative Feature
  • 🖥️VEX CAD
    • CAD Programs
      • Inventor
      • Fusion 360
      • Solidworks
      • OnShape
      • Protobot
    • Making a Chassis
      • Inventor Chassis: The Basics
        • Installation
        • User Interface Overview
        • Dark Mode
        • Assemblies
        • Placing Parts
        • Navigating CAD
        • Changing Visual Style
        • Grounding
        • Connecting Two C-Channels
        • Modifying Existing Constraints
        • Toggling Visibility on Existing Parts
        • Completing Half of the Chassis
          • Inner Drive Channel
          • Bearing Flats
          • Motors
          • Wheels
          • Sprockets
          • Spacers, Washers and Standoffs
          • Spacers Cont.
        • Creating Mid-Plane
        • Mirroring
      • Inventor Chassis: Best Practices
        • File Structure
        • Subassemblies
        • Wheel Subassembly
        • Origin Planes
        • Cross Brace
        • Drive Channels
        • Simple Motor iMates
        • Replacing Simple Electronics
        • Completing Half of the Drive
          • Bearing Flats (Best Practice)
          • Wheels
          • Powered Gear
          • Spacer Boxing
          • Spacers, Washers and Standoffs (Best Practice)
        • Model Browser Folders
        • Mirroring (Best Practice)
        • Model Browser Folder (Right)
        • Main Assembly
      • Fusion 360 Chassis
      • Solidworks Chassis, Chain, and Custom Plastic
    • Remembering The Best
      • 62A Skyrise
      • 400X Nothing But Net
      • 2587Z Nothing But Net
      • 365X Starstruck
      • 62A In The Zone
      • 202Z In The Zone
      • 5225A In The Zone
      • 169A Turning Point
      • 929U Turning Point
      • 7K Tower Takeover
      • 5225A Tower Takeover
      • 62A Change Up
    • Scuff Controller
  • 💻Software
    • Odometry
    • Path Planning
    • Robotics Basics
      • Arcade Drive
      • Tank Drive
      • Joystick Deadzones
      • Curvature (Cheesy) Drive
      • Subsystem Toggling
    • Organizing Code
      • Code Style
      • Code Styling Guide
      • Writing Good Comments
      • Version Control
    • Control Algorithms
      • Bang Bang
      • PID Controller
      • Basic Pure Pursuit
      • Flywheel Velocity Control
      • Kalman Filter
      • Take Back Half (TBH) Controller
      • RAMSETE Controller
    • Competition Specific
      • Operator Control
      • Autonomous Control
    • C++ Basics for VEX Robotics
      • Basic Control Flow
      • Enumerations
      • Namespaces (::)
      • Multiple Files (C/C++)
    • VEX Programming Software
      • PROS
        • OkapiLib
      • vexide
      • Robot Mesh Studio (RMS)
      • EasyC
      • RobotC
      • VEXcode
      • Midnight C
    • General
      • Stall Detection
      • Register Programming
      • Sensors and Odometry in Autonomous
      • Embedded Programming Tips
      • Debugging
      • Bit Shift
      • Bit Mask
      • Autoformatting
      • Finite State Machine
      • Data Logging
    • Object Recognition
      • Red Green Buoy
      • AMS
      • OpenCV
      • OpenNI
    • 🤖AI in VRC: Pac-Man Pete
  • ⚡VEX Electronics
    • V5 ESD Protection Board
    • VEX Electronics
      • VEX V5 Brain
        • V5 Electronics Observations and Issues
      • VEX Controller
      • VEXnet and V5 Robot Radio
      • VEX Battery
      • VEX Motors
    • VEX Sensors
      • 3-Pin / ADI Sensors
        • Encoder
        • Potentiometer
        • Limit Switch
        • Bumper Switch
        • Accelerometer
        • Gyroscope
        • Ultrasonic
        • Line Tracker
        • LED Indicator
      • Smart Port Sensors
        • GPS Sensor
        • Rotation Sensor
        • Vision Sensor
        • Optical Sensor
        • Distance Sensor
        • Inertial Sensor (IMU)
        • 3-Wire Expander
    • V5 Brain Wiring Guide
    • Legacy
      • VEX Cortex
      • Power Expander
      • VEX Motor Controller
      • VEX Cortex Wiring Guide
  • General Electronics
    • General Topics
      • External Boards
        • ASUS Tinker Board S
        • Arduino
        • Beagleboard
        • Leaflabs Maple
        • LattePanda
        • Meadow F7 Micro
        • Netduino
        • ODROID-XU4
        • Pandaboard
        • Raspberry Pi
      • Analog-Digital Converter (ADC)
      • Bit-Bang
      • GPIO
      • I2C
      • Jitter
      • Line Noise
      • List of Tools
      • Output Drive
      • Power Consumption
      • Radius Array
      • Resettable Fuse (PTC)
      • SPI
      • Slew Rate
      • Stalling
      • USART
      • UART
      • 5 Volt Tolerant
      • DC Motor Basics
Powered by GitBook
LogoLogo

This work is licensed under a Attribution-ShareAlike 2.0 Generic License

On this page
  • Motivation
  • Procedure
  • In - Practice (Honey Badger)
  • Teams Contributed to this Article:

Was this helpful?

Edit on GitHub
Export as PDF
  1. Software
  2. Object Recognition

Red Green Buoy

PreviousObject RecognitionNextAMS

Last updated 1 year ago

Was this helpful?

The Red Buoy, Green Buoy Algorithm, or simply Red/Green Buoy for short, is a simple terminal guidance algorithm for homing at close range on an object initially sensed by techniques.

Even in the advanced with the use of the 50-FPS XBC FPGA-based parallel vision controller, using the camera to track objects at close ranges was problematic. Cameras mounted to see the maximum area of the field often had perilously small fields of view up close, and the rate at which robots needed to react to capture objects was much higher than the camera could functionally provide.

Initially, additional analog sensor ports connected to short range IR rangefinders were utilized to provide some simple control, but this often introduced wild oscillations that hurled objects throughout the field. While potentially also disastrous for an opponent, such careless behavior rarely led to productive scoring. A breakthrough came when the iRobot Roomba's algorithm for finding its charging base, applied in reverse, was used to provide a much smoother method for proper close-range guidance.

Due to the user manual's reference to the three sensors as the "Red Buoy", "Green Buoy", and "Force Field", the new algorithm came to be known as the "Red-Buoy Green-Buoy Method". iRobot's use of these names likely stems from the use of similar techniques to properly moor ships in dark harbors centuries ago by observing two colored buoys set up along intended paths. Modern airplanes still carry one red and one green light on opposite wingtips, allowing other pilots to instantly tell in dark skies which way another aircraft is facing.

Procedure

A minimum of three range-finding sensors, such as a or Sharp IR rangefinder, must be used for proper implementation of the algorithm. Up to seven sensors can be used for the best possible quality, but it is also possible to do a decent job with only two sensors.

In addition, it must be possible to use an object recognition system to verify the presence of a valid scoring object in the field of view. Objects belonging to the opponent and opposing robots look just as good to rangefinders as the appropriate target, although the multi-sensor versions do a good job of differentiating walls from narrow objects.

The sensors must be configured in the pattern shown in the diagram, with a narrow beam of coincidence just wider than the size of the intended target between the two central cones of detection. Additional sensors, if available, should be configured as to create additional beams of coincidence at steadily increasing angles in order to widen the effective field of view. However, having too many sensors can reduce the rate of data acquisition if the sensors must take turns to avoid interference.

The algorithm follows a to keep the object inside the narrow beam; if the object strays to the side, it will cease to register on one of the beacons, and the robot will turn towards the new heading. When initially scanning for a target, the algorithm looks for a set of transitions to start detection; wide targets like walls will not have any perceptible edge transitions and will hopefully be excluded. In practice, the algorithm should be performed far from interfering objects.

At extremely close ranges, the third sensor, known as the "Force Field", is used (if present) to slow the robot down and provide the final commands needed to bring the object inside the manipulator. In the case of wide intake devices, this sensor can optionally be omitted.

In - Practice (Honey Badger)

Due to a constraint on the number of digital ports, Honey Badger (BLRS's Gateway Robot) only was able to field two VEX Ultrasonic sensors. In addition, the object recognition software was not ready at the time of the algorithm's initial development. Therefore, a custom Red/Green Buoy variant was devised as a general object search technique. It followed the original algorithm closely, but had a much larger scan range to actually find faraway objects, as opposed to simply providing close-in guidance. In addition, no edge detection was possible at such far ranges, so the scan algorithm simply spun until something was found in the overlap region and then drove out to collect it.

These compromises unfortunately led to an inability to properly sense which objects were of the desired color, and a tendency to detect people, robots, and walls as candidates due to the very long maximum scan range. However, it was effective enough to fill the intake mechanism each time it was run.

Teams Contributed to this Article:

(Purdue SIGBots)

💻
object recognition
Motivation
Botball Robotics Competition
bang-bang
VEX Ultrasonic
PID loop
BLRS