Software/Electrical

Systems

Voltage/Power Rails

We have three major voltage rails on the robot. There is a 5V logic rail, a regulated 11.8V rail to maintain consistent behavior for drive and shooter motors, and an unregulated 15V rail from the 2 NiMH batteries to power the ball-dispensing stepper motor.

If we were to do things differently, we would definitely 1) add fuses/circuit breakers much earlier in the process and 2) separate out the sensors (ultrasonics) onto a different 5V rail (we added capacitors to mitigate disturbances but the signal might have been cleaner on a completely separate rail)

Drive Train

The drive train consisted of 2 DC motors controlled by the Arduino through a L298N dual h-bridge. In the L298N h-bridge, a motor's direction is controlled by setting one direction pin high and the other low. The speed is set by sending a PWM signal on the enable pin. In order to cut down from controlling both direction pins, the Arduino controlled one direction pin directly (which was fed through a logic inverter to control the other direction pin.) This last change was done later and so not reflected in the systems circuit diagram.

Ball Shooter

In order to be able to accurately control our shooting speed, and have a lot of power, we choose a 2400KV brushless motor controlled by an ATMEL ESC. This motor is generally used to power propellers on quadrotor aircraft. In hindsight this was probably serious overkill and largely spurred by the fact that both Ryan and Noa are members of the Stanford UAV club.

We did have incredibly good accuracy with the shooter. The ESC is controlled by the Arduino by varying the duty cycle of a PWM signal, which was achieved by using the Servo.h library. The firmware on the ESC is configured such it requires an enable, servo.writeMicroseconds(1000) . Another writeMicroseconds command from 1000-1900 sets the speed, we used 1160 - speeds even not significantly higher were insanely fast.

Ball Dispenser

Because we wanted to control dispensing and therefore one ball at a time, we chose a stepper motor for more precise movement control. The motor speed is controlled by varying the period of a 50% PWM cycle. This was achieved using the ME210 Pulse library

Ultrasonic Sensors

The ultrasonic sensors work by sending a short sound burst from the transmitter and waiting to detect it on the receiver. The distance is computed using the time it took the signal to travel from the transmitter, hit the object and bounce back into the receiver. Ideally, waiting for the sound signal to bounce back would not block the code and we could do other things in the meantime (and have non-blocking code/interrupts).

Practically, the amount of time you wait for the signal to come back is extremely short, and we wanted to use more sonar sensors than the number of interrupt-enabled pins on the Arduino. We decided to go with the naive solution of simply making the program wait until the sonar sensor picks up the return signal and computing the time difference waited.

To get cleaner readings from the sensor we implemented a sliding window average (which seems to work reasonably well, making us not pursue more rigorous statistical techniques such as Kalman filtering)

The robot had one sonar sensor in the back and two on the right side.

Our strategy for using two sonar sensors to get a differential reading from the wall is discussed in the 'Alignment Strategy' page.

A system's diagram which gives a pretty good sense of the sonar pinout. The drive system setup shown is outdated.

IR Sensor

The IR sensor circuit was constructed such that a detected signal pulls the output from high to low. We wanted to align with the IR by turning until see a the IR. We connected the output of the IR circuit to pin 2 and defined an interrupt that would stop the motors when pin 2 is pulled low.

Autonomous Program

The autonomous program is modeled as a daisy chain of states representing steps necessary to align ourselves, go to the shooting position and shoot

All exit condition thresholds were initiated based on field dimensions and iterated empirically.

The program outline was as follows (the diagram of our path on the 'Strategy and Alignment' page could provide useful context):

Aligning so that the safe space wall is on right

Action:

• Left motor on, speed 120. Right motor on, speed -120

Exit condition to next state:

• Back facing sensor above a threshold,
• right facing sensors below a threshold
• the right-forward distance > right-back distance + some threshold

Driving forward until encountering sanity check wall

Action:

• (abstracts 2 internal states, one drifts left if right sonar< threshold; else in other, drifts right )

Exit condition to next state: Timer 1 expires

Rotating so that sanity check wall is to our right

Action:

• Left motor on, speed -127. Right motor on, speed 127

Exit condition to next state:

• right facing sensors below a threshold
• the right-forward distance > right-back distance + some threshold

Driving forward into sanity check wall/shooting corner

Action:

• Left motor on, speed 170. Right motor on, speed 127

Exit condition to next state: Timer 1 expires

Shooting round 1

Action:

• (abstracts a couple of internal states engaging the ESC and stepper motor)

Exit condition to next state: Delay counter of last internal expires

Realignment

Action:

• (abstracts a couple of internal states, drives backwards [based on time], rotates until right-front sonar sensor within range)
• Starts fine alignment: Left motor on speed 190, right motor on speed -190

Exit condition to next state:

• right-front distance + threshold within a range above right-back distance

Shooting round 2

Action:

• (abstracts a couple of internal states engaging the ESC and stepper motor)

Exit condition to next state: Delay counter of last internal expires

Done

Reflections on challenges and lessons learned from system integration are included in the next page