This page details the design choices and implementation of all the electronics used in the completion of this project.
The schematic .pdf and the KiCad project can be found on published GitHub repository.
The system consists of two PIC32MX170F256B (PIC32) microcontrollers:
DRIVER and OPERATOR.
The PIC32s communicate over SPI.
The system is powered by two 7V batteries wired in series to give 14V total. We have a power distribution board that regulates our voltages down to 5V for the servos and 3.3V for logic, and our drie motors and arm are powered by the 14V battery. We included a 5A fuse and a main power switch; we also included a 2A fuse at the input of the 5V buck regulator.
The MPLAB SNAP programmer and debugger was used.
We made sure to manage wires well and solder into permanence when possible, especially on the levels of modules.
We kept signal lines away from motors and switching drivers. We used twisted pairs for signals' related return paths.
We designed the electronics to be modular and set up any lines between the two PIC32s on a perfboard as shown on the left. All other lines extended out of the perfboard, and each signal is labeled clearly for debugging and organization.
This also removed the need to check whether wires are still connected and significantly reduced the time in debugging, especially while integrating.
handling all drive-train-related motors and navigation-related sensors
Leader for SPI Communications
handling all user inputs, operating all non-driving (operational) subsystems related to handling cargo and deposits
Follow for SPI Communications
The 12V geared DC motors we used for the drivetrain were provided to us along with the quadrature encoders that are mounted to the back of the motor shaft (because we always know the direction, we connected to only one of each side's encoder outputs), which gave us 300 pulses per revolution. The motors are geared 50:1, providing a good balance of torque and speed.
We used drive-brake mode for driving motors with improved linearity.
We drove the motors using a pair of TLE5206-2S drivers.
We tuned our IR beacon detection system to work at distances up to 4 meters for the provided beacons, which is a little larger than the diagonal accross the entire playing field.
The comparator output feeds into the microcontroller.
Each of the resistor values has been selected with handcalculations and then tuned by setting an IR beacon at various distances to detect without saturating a signal at a variety of lighting conditions, keeping the system robust.
The start signal detection circuit is an IR transmit and receive system. The system includes a transimpedance amplifier, followed by a high-pass filter to remove the any low-frequency noise, DC bias, and ambient light, followed by another amplifier stage, and finally a comparator with hysteresis. The output of this chain of analog processing is a digital high or low, indicating whether the beacon is on or off, which in the processor gets converted to a frequency (using Input Capture [IC]). This configuration provides robust threshold voltage control, ensuring reliable transitions between digital high and digital low outputs.
Supporting the IR Beacon Analog Dront End, we used unity-gain buffers to set the bias voltage for our amplifiers and comparators. We included bypass capacitors at each of our IC packages (the op-amp and comparator).
In summary, the beacon detection circuit can be divided into 4 stages: Stage 1 (high-pass filter), Stage 2, and Stage 3. Stage 1 is a trans-resistive amplifier circuit that converts the current produced by the LTR-3208E phototransistor into a voltage. The high-pass filter removes low-frequency noise from other electronic devices (such as 60 Hz noise) and the DC bias. Stage 2 is a non-inverting amplifier that further amplifies the signal, and Stage 3 is a non-inverting comparator with hysteresis to filter noise out and produce a clean digital output.
We used 4 TCRT5000 active reflective IR sensors (in digital configuration) for tape following and pivot (intersection) detection.
Each of these was tuned using its included potentiometer.
We have a pulled-up single-pole double-throw limit switch with analog debouncing for detecting when we reach a cargo deposit.
We used high-torque DC motors for the input, agitator, and feeder subsystems. For the input, we polarity-reversed two drivers and used the same signal to drive both. We drove the motors using TLE5206-2S drivers. We used drive-brake mode for all operation and manipulation motors with improved linearity.
We used 2 TCRT5000 active reflective IR sensors (in digital configuration) for detecting when a cargo gets into or out of our robot's container. Each of these was tuned using its included potentiometer to trigger while the ball was passing through the input or output channels.
The arm servos are high torque 35kg-cm 270 degree coreless servos (RDS3235SG). They are configured with bypass capacitors of 4700uF and tethered, isolated wires from the robot body extending accross the robot arm.
The microcontroller takes an angle from the array (for each of the joints) for the servo to turn to, and generates a corresponding PWM signal to drive the servo motor. The PWM signal determines the angular position of the servo motor by controlling the duty cycle of the PWM.
We have a pulled-up limit single-pole double-throw switch with analog debouncing for detecting when the arm reaches its lowered position. This is to protect against getting stuck at a state of lowering a deposit due to misalignment or a tug-of-war.
We have a single-pole double-throw switch to determine whether the current match is a deathmatch or a standard match, which gets recorded through a digital input and relayed to our system (see Software) when the game start button gets triggered.
For the game start button, we have a pulled-up button with analog debouncing.
Based on which side of the field the robot is on (detected using IC from the IR beacon receiver), the microcontroller drives the servo to indicate on our color-coded field-side indicator by moving a dial towards one side or the other. The microcontroller takes an angle for the servo to turn to, and generates a corresponding PWM signal to drive the servo motor. The PWM signal determines the angular position of the servo motor by controlling the duty cycle of the PWM.
The microcontroller used for the project was the PIC32MX170F256B (PIC32). The microcontroller connected to the MPLAB Snap to enable the programming of the microcontroller using MPLAB X IDE, and the microcontroller was also connected to a USB to Serial device in order to monitor the serial output of the PIC for debugging purposes.
At each IC, we included a 0.1 uF capacitor as local charge storage, providing stability at local transitions and current draws. We used monolithic ceramic capacitors because they are:
+ physically small
+ inexpensive
+ maintain the capacitance value at higher frequencies, so able to support fast responses.
Additionally, we included larger bypass capacitors at high current loads and regulators.
We kept our PIC32s in removable mounts, keeping them modular and swappable.
Signals are kept away from motors and switching drivers.
To maximize the cargo-carrying capacity and to isolate the high-current signals, most of the electronics were placed under the robot, whereas the signal and compute were placed on the front side for accessibility and isolation.
To reduce the effect of electrical noise, high-current power lines and logic-level circuits were distanced to either side of the robot.
Appropriate lines and their associated return paths were also twisted together whenever possible to minimize electromagnetic fields.
All power lines go directly back to the power distribution board (explained below) to avoid undesirable ground loops.
We interfaced with and used the following power distribution board.
The power distribution board was assembled to allow two batteries to supply power to all electronics in the system. Two voltage regulators were configured to provide regulated outputs of 3V3 and 5V. The servos and other such loads were placed on separate power rails to prevent high current draw from interfering with the robot’s sensing circuitry.
We modified it to include an additional fuse to limit the input of the buck converter. We chose the input of the buck converter because a buck can supply more current than it inputs, and the specifications/testing conditions are defined at its input.