As many people discovered, both in Engineering Projects and life - parts that work well separately can behave strangely when put together.
We did a fairly good job of sketching out the mechanical construction of the robot as a whole, and so integration of the different mechanical systems went pretty smoothly. As for software integration, we maintained good communication between the team about our assumptions. The bizarre integration bugs occurred as a result of various inter-dependencies in the Arduino board. For example: Certain PWM Arduino pins are tied to timers utilized either directly by us, or in the depths of imported libraries. PWM on pins 5 and 6 on the Arduino are on 2x faster frequency than the rest of the pins. Interrupts can only be programmed from certain pins. These and a couple more bespoke inter-dependencies resulted in some very bizarre bugs. After a fun game of pin-out sudoku, we were very grateful to have started integration early.
Besides starting to think about integration early, the other lesson we learned is to be very familiar with the HW/Firmware you are using.
Unfortunately, we attempted to integrate the IR sensor too late into the developmental process. Using an oscilloscope, it was determined that the IR circuitry was functional. Although the IR circuit was not the critical component in alignment, it could have been very useful to fine tune the bot's position. However, it was difficult to integrate this with the motor control. Because we are using DC motors for drive, after the Arduino detected the signal, sometimes the bot would coast by a large amount. Sometimes the bot did not stop turning. It was suggested that once the signal was detected, the drive train motors should be pulsed in order to make small turns. In addition, the sensor placement on our bot was non trivial. We wanted to place the sensor in line with the shooter to achieve maximum precision, but there was not a lot of space on the bot. Also, placing the sensor at an angle that could receive the beacon signal was inconsistent. While we did use heat shrink as a barrel, it might have been too constricting. If more time was permitted, it might have been more efficient to use a cone structure around the sensor.
Late into the check off process, we either shorted a voltage rail and ground or two different voltage supplies. In addition, there was a considerable amount of current being drawn from the supplies because we were running a myriad of devices and three different sets of motors. In order to mitigate the pain of debugging, a fuse between the circuitry and the supplies and more isolation between the different subsystems would have been a great choice. Fuses would provide initial protection against shorted components.
We also agreed that although they are expensive, omniwheels would have been the better choice for drive train wheels. Our decision to use the walls for alignment and our reasoning for using a drive train of 2 regular wheels/2 coasters both made sense separately. Yet, given our strategy, omniwheels make more sense. Using omniwheels would have made movement out of corners and off of walls much easier. They allow multidirectional movement that our generic wheels could not provide. We should have made our decision for the drive train primarily informed by what type of driving we wanted to achieve based on our game strategy.