This is our second revision of the driver controls system. The first revision featured a single carrier board that communicated with a steering interface board and a pedal board through I2C directly. This was simple from a firmware perspective since all the external ADCs or IO Port Expanders were slaves on the same I2C bus. Despite working well on the bench, we faced significant issues during ASC 2018 with EMI interfering with the I2C lines. This could be seen with an oscilloscope when the accelerator is pressed and the motors are being driven by the Wavesculptor20 motor controllers. A temporary fix with ferrites allowed us to finish the race despite dealing with a lot of I2C errors, but decision to switch over to CAN was made soon after the race. 

The current driver controls features 3 main boards that communicate to the rest of the car over System CAN. This architecture was chosen to keep the boards close to what they're sensing, and to avoid long runs of analog or digital signals that could be susceptible to noise and interference. 

Pedal Board

The Driver Controls Pedal is responsible for measuring the accelerator, brake pedal, and potentially steering angle through analog measurements. The accelerator pedal we use on MSXII is taken off a Chevrolet Malibu from UWAFT, and has 2 potentiometers built in for redundancy purposes. The board uses the external 12V and the 3V3 regulated from the controller board to power the op-amps for filtering, to be applied across the potentiometers and on the LDO. The 3.0V from the LDO is used to power the on-board ADC taking in the analog inputs coming from the accelerator, brakes and steering angle potentiometers. It uses I2C to communicate with the controller board.

Due to the noise present in the car from the motors and other communication devices, an active low pass filtration system was implemented on the analog inputs from the various potentiometers. The type of filtration uses passive RC filtering with a non-inverting amplifier providing a gain of 1. The RC filter provides a frequency cutoff, while the op-amp acts like a buffer and isolates Vout from the filtration.  (see figure below)

Steering Interface

The Steering Interface board is responsible for handling the inputs from the steering stalk (such as the turn signals, cruise control, lane assist, etc) and horn. These are a mix of digital and analog signals, and the board uses different methods to reduce noise from EMI interference for each. Similarly to the pedal board, this board uses the external 12V and the 3V3 regulated from the controller board to for power. For the digital signals (horn, high beam back, high beam forward, lane assist, CC on/off, and CC set), RC filters and schmitt triggers are used. For the analog signals (turn signal stalk, CC cancel/resume, CC speed, and CC distance), active low pass filters are used by combining RC low pass filters and op amps. (See diagram above). In addition, 0.1uF capacitors for stability/EMI reduction were added, such as those by the power supplies and power for the schmitt trigger.

Centre Console

The Driver Controls Centre Console board is responsible for a few things including the handling of the physical button interface on the centre console, powering the Raspberry Pi responsible for the driver display, powering fans for rPi cooling, and toggling the BPS Indicator for the driver. The following sections will break down how each of the above tasks are implemented, and the rationale behind these design decisions.

Let's begin by addressing the buttons, how they're powered, and how the board handles them. The figure below is a photo of the buttons we are using in the car (19mm ones). These buttons have 5 exposed pins: LED +, LED -, Normally Open, Normally Closed, and Common. The LED +/- are used to power the LED rings surrounding the buttons - these LEDs are setup as outputs through a GPIO Expander going to a FET Driver responsible for sending the appropriate voltage to the LEDs to power them on. When a button press is detected, the firmware sends an I2C message to the IO Expander corresponding to the LED of the button pressed. The FET Driver inputs are normally pulled down; the IO Expander pulls up the pins on the FET Driver when a certain LED needs to be powered, and the DET Driver drives the LED output high to turn on the LED. The GPIO Expander was used because the controller board is already handling so many IOs like the button signals, display enable, fan enable, and a few other things. By using the IO Expander, we relieve the MCU from handling so many individual LEDs, and simply using an I2C bus to enable the LEDs. The FET Driver is used to provide the necessary voltage (~12V) to the LEDs.

The button signals themselves are handled in a very simple manner: like the diagram below states, the 19mm button uses the Common and Normally Open as the switching pins. The Common pins are grounded, and the Normally Open pins are filtered using an RC filter with fc = 1.5kHz and tr = 0.23ms. These filtered signals are passed to an Inverting Schmitt Trigger for a clean digital input to the Controller board. For rationale behind why the buttons are filtered this way, refer to Hardware 101.

Let's now address the rPi and how it works with the Centre Console board. First of all, the rPi required 5V supply, and since the board only has 12V from the car, and 3V3 from the Controller board, a 12V to 5V switching regulator is used. This regulator design was provided by TI. The regulator was tested given different load currents, and proved stable with minimal ripple - this is key for powering the rPi. The rPi can communicate with the controller board via UART, and the rx/tx pins are connected appropriately. The rPi is mounted on the Centre Console board using its appropriate 40-pin receptacle. Finally, the Centre Console board also houses a Real-Time-Clock chip along with a 32.786kHz Crystal that are responsible for providing time to the rPi when not connected to WiFi (This has not been fully tested, as there were some issues initializing an extra RTC on the Pi). This RTC uses I2C to communicate with the Pi. 

The decision to place the Pi on this board makes sense since the 5V regulator can be placed on there and not on a separate board - this also made communication with the Pi easier since a Controller Board is already housed on the Centre Console. 

Finally, using the same logic and electrical path as the button LEDs, the BPS LED is connected to this board, and turns on when commanded by the Pedal Board. 

This board design is quite simple, as it involved solving a few simple tasks - handle the button signals, button LEDs, BPS LED, and host the rPi.