Design Concepts

Final Mechanical Design

Mobility: Omni-directional wheels on servos and central ball bearing

• Easy movement in any direction
• Can use servo information for localization/position of robot
• Central ball bearing helps reduce the load placed on the servos and omni-directional wheels

Catching: Large net bowl

• Net chosen to soften landing
• Relatively simple mechanism
• Adjustments can be made with camera mounts

Throwing: Dual flywheel design

• Belt driven system implemented to reduce stress on motor shafts and operate brushless at higher speeds
• Custom 3D printed wheels conform to the shape of the beach ball to increase throwing distance
• Flywheel separation distance is adjustable depending on application

Changes from Initial Design:

• Changed throwing mechanism from servo driven fling arm to brushless motor driven flywheels
• Added central ball bearing to mobile base to reduce load on omni-directional wheels
• Added an elevated platform for CatchBot to sit on. This brings the robot to a reasonable human level in order to successfully play catch with a human.

Final Electrical Design

Microcontroller: 2x Arduino Unos for robot control (excluding vision)

• Enough I/O and processing to interact with all desired sensors and servos
• Easy to use, low power, cheap, & small

Motion: Full rotation metal gear servos actuating omni-directional wheels

• Precise control with pwm signal from microcontroller
• Fast/strong enough for this lightweight application

Throwing: 2x 2408 2500kv Brushless quadcopter motors with 20 amp electronic speed controllers (ESCs)

• Had enough torque and rpm capability to spool up 3D printed flywheels via a belt driven system
• ESCs had a high enough current rating to supply power to the motors
• ESCs interfaced with the Arduino via pwm controls

Power Supply: 2x 3 Cell Lipo battery and 5V buck converter regulator

• Already have lipo batteries, connectors, wire and charging supplies from fpv drone experience
• Lipo batteries will be able to deliver enough current to easily run the system
• Short matches meant a low capacity of 1000mah at 12.6V was enough to power the control and motion electronics
• 5V buck converter efficiently regulates voltage output and has high current capability
• ESCs plugged directly into a 2000mah 12.6V lipo battery

Perception/Sensing: Ultrasonic sonar sensor to detect if robot has ball

• Easy to use and have experience working with them
• Reliable pwm signal sent out which Arduino ADC can measure

Vision: USB Webcam

• This option will allow for easy integration of video feed into image processing software

Vision Processing: Raspberry Pi 3

• OpenCV will run on this platform just fine
• Internet connection, full Linux OS

Changes from Initial Design:

• Two Arduinos used for more I/O
• Brushless motors and ESCs used to throw ball
• Ultrasonic sonar sensor used to detect if robot has the ball

Final Software Design

Low Level Control Code: Arduino (C++)

• The servos for the mobile base and the electronic speed controllers for the flywheel design are connected to the Arduino.
• The low level code controlling flywheel speed and servo speeds for movement are written in C++ and run on the Arduino.
• The control code also kept track of game mode (coop/adversarial) and control mode (autonomy/teleop). The reasoning behind this design was: we had intended to set the game mode and control mode via teleoperation via a radio receiver connected to the Arduino. Since our only adversarial strategy was to change flywheel speeds, the Raspberry Pi did not need to know whether it was in adversarial or coop mode. This design decision reduced the amount of communication necessary between the Pi and Arduino.

High Level Control: Raspberry Pi (Python)

• The gameplay logic for catching, aiming and throwing are written in Python and run on the Raspberry Pi.
• Python was chosen for its modularity and many libraries, as well as for easy integration with the webcam input (as discussed in vision below).

Communication: USB Serial (Python/C++)

• The Raspberry Pi and Arduino communicated over a USB serial bridge.
• Communication was kept simple using a Master-Slave architecture, with the Pi as the master device and the Arduino as the slave device.
• We used single byte communication to avoid timing and serial buffer issues and maximize information speed.

Vision: Marker detection with webcam connected to Raspberry Pi via USB

• The ArUco marker library from OpenCV's extended library was used for marker detection.
• We used a board of markers to gain higher resilence to motion blur and obscuration.
• We applied pose and depth detection using the board structure to detect human opponent location and zone in order to properly aim.

Code Repository: Github

• Our code was hosted on Github in a private repository.
• Using Git version control allowed us to backup our code and work in parallel with minimal disturbances to each other's work.

Changes from Initial Design:

• Game mode and control mode logic was implemented in Arduino rather than the Pi to minimize communication necessary between Pi and Arduino.
• We settled on using USB serial for communication. Initially, we had switched to I2C due to issues with the serial buffer. But switching to a master-slave communication protocol and simplifying the message size eliminated those issu.es
• We initially planned on using AprilTags as our marker detection system. But we found there was a memory leak in the open source implementation of the library. Since OpenCV has ArUco marker support and it also support marker board detection which gives us more precise pose and depth estimation, we switched to ArUco.