Prototyping and Hardware

We only achieved very basic controls for throttle and braking, but it was possible to control the vehicle and dyno separately.

The machine's construction was a solid metal frame inset with four 12-inch rollers used to move the mounted vehicle - essentially these are what made this a dyno. The vehicle sat on top and drove.

Each roller was connected to an electric motor for drive, brake, and torque/HP testing. The motors connected to Kelly motor controllers, which then connected to an Arduino. This was our way to communicate - everything used serial.

On the user's end, a Python program used our custom UART-based protocol to send and receive communications over serial. We used a Teensy microcontroller, which is a souped-up Arduino. See image below. It had eight serial ports, which we needed to handle all asynchronous communication between devices.

I'm writing this years after this project ended and don't remember what everything here connected to anymore. There was much cool circuitry stuff happening, but this is all lost to the sands of time.

Arduino Programming

The gist: the computer sits on one end, the motor controllers on the other, and all comms pass through the Arduino. So the Arduino had to handle bidirectional I/O from both sources:

1. Source In/Out: Python desktop app <=> Arduino
2. Target Out/In: Arduino <=> Motor controllers

1. Source In/Out

The app instigates the communication and the Arduino listens by default using the void loop() API. Incoming messages are broken apart so we can identify what the instructions are. These are executed in part 2.

These needed to be fed into a simple state machine. To handle this, we used something like the JBD BMS Protocol which is from an auto industry battery and electrics company. Our version uses the same start and end byte patterns, but the rest is a mishmash.

Shown here is the scratch protocol. See how it's bookended by the JBD BMS hexadecimal byte patterns [0xDD] and [0x77]? This is the basis of the state processing.

            /* Message Format
             *  Byte: 1       | Start bit [0xDD] (1 byte)
             *        2:7     | Message Header (6-bytes)
             *        8:X     | Message Data (variable byte Size)
             *        X+1:X+2 | Message Checksum (message header + data size)
             *        X+3     | End bit [0x77]
             */
          

Each stage is a different state trigger for a different action.

            switch (rx_state)
            {

            case UART_RX_STATE_IDLE:
            {
              uint8_t data_in = UART_HOST_RX_SERIAL.read();
              // Check for the start bit pattern
              if (data_in == UART_RX_START_BIT_PATTERN)
              {
                // Move to the Header receive state
                set_rx_state(UART_RX_STATE_HEADER);
              }

              break;
            }
            case UART_RX_STATE_HEADER:
            {
              // Read the bytes into the header structure
              UART_HOST_RX_SERIAL.readBytes((char *)&rx_header, sizeof(msg_header_t));
              // Move to the Data receive state
              set_rx_state(UART_RX_STATE_DATA);

              break;
            }
            case UART_RX_STATE_DATA:
            {
              // If all of the expected data has been received
              if (rx_data_idx >= rx_header.len)
              {
                // Move to the Chksum receive state
                set_rx_state(UART_RX_STATE_CHKSUM);
              }
              else
              {
                // Add the received data to the buffer
                rx_data[rx_data_idx] = UART_HOST_RX_SERIAL.read();
                rx_data_idx++;
              }

              break;
            }
            case UART_RX_STATE_CHKSUM:
            {
              // Read the bytes into the checksum structure
              UART_HOST_RX_SERIAL.readBytes((char *)&rx_chksum, sizeof(msg_chksum_t));

              // Compute the checksum of the received header and data
              msg_chksum_t msg_chksum = 0;
              uint8_t i;
              uint8_t *rx_header_data = (uint8_t *)&rx_header;
              for (i = 0; i < sizeof(msg_header_t); i++)
              {
                msg_chksum = bsd_chksum(msg_chksum, rx_header_data[i]);
              }
              for (i = 0; i < rx_header.len; i++)
              {
                msg_chksum = bsd_chksum(msg_chksum, rx_data[i]);
              }

              // Compare the calculated and received checksums
              if (msg_chksum == rx_chksum)
              {
                // If match, move to the End bit receive state
                set_rx_state(UART_RX_STATE_ENDL);
              }
              else
              {
                // Otherwise, reset to the Idle state
                set_rx_state(UART_RX_STATE_IDLE);
              }

              break;
            }
            case UART_RX_STATE_ENDL:
            {
              uint8_t data_in = UART_HOST_RX_SERIAL.read();
              // Check for the end bit pattern
              if (data_in == UART_RX_END_BIT_PATTERN)
              {
                // Message is valid, pass to process function
                handle_uart_rx_message(rx_header.msg_id, rx_header.bus_id, rx_header.len, rx_data);
              }

              // Move back to Idle state to receive next message
              set_rx_state(UART_RX_STATE_IDLE);

              break;
            }
            default:
            {
              // In an invalid receive state, move back to Idle
              set_rx_state(UART_RX_STATE_IDLE);

              break;
            }
            }
          

2. Target Out/In

Once the message has run through all the states and is validated, it hits the function handle_uart_rx_message. This sends the instruction output to the controllers by analogWrite on the output pins. We set the desired intensity and the motor controllers turn the bits into something physical. This is what allows us to plug in the vehicle and run it from a computer.

How the machines' controller operations actually receive, parse, and turn the signals into work is another gap, lost to those same time sands.

            void set_electric_speed_control_throttle(uint8_t id, uint8_t throttle)
            {
              throttles[id] = throttle; // Set the throttle level for this channel
              throttle_time_ms[id] = millis(); // Record the current time in milliseconds
              analogWrite(throttle_pins[id], throttles[id]); // Update the PWM duty cycle on the pin
            }
          

Dyno App

This was the desktop application that operated the dyno. I worked on this section the most.

It was built using Python Tkinter. This was chosen before my time. Tkinter is great because it's built into Python and works well for simple GUIs. It was not the best choice for a complicated multi-page app like this. I was so frustrated that I built tkinter-devtools so I didn't need to keep restarting the app to see every single little change.

Tkinter is a steam engine or wood-burning stove. Reliable, but not a modern tool for building software.

• In a world of components, it still uses "widgets" to construct pages
• Widgets must be "packed" just to show up, and most page geometry must be handled manually
• And styling...fuhgeddaboudit.

There were three main modules:

1. GUI "Frontend"
2. Business Logic "Backend"
3. Socket Networking Interface

Socket Network

We had no official server to handle requests but still needed to communicate asynchronously between the GUI and logic. We used a socket.

I did it all from scratch using the Python socket module. This added much extra complexity: the price of making the app modular and separating the concerns.

Putting the entire code base into a single giant file, for example, would have eliminated the need for a socket. But my fingers would never ever allow my brain to implement such a "design." They'd refuse to type. I do admit this was likely over-engineered and could be improved.

And I kind of lied. Our socket module was an infinite loop listening for connections, AKA a server. Using this, we listened for messages coming from each side, either READ or WRITE.

I leaned heavily on the Real Python Socket Tutorial. Following a pattern for both messages, again using struct, where WRITE packed the data in a specific order and READ unpacked it reversing the pattern, we identified which incoming data was relevant and needed attention.

          
            /* Selector I/O Bit Mask
            *
            * EVENT_READ  = 1  → 01
            * EVENT_WRITE = 2  → 10
            * both        = 3  → 11
            */
          
      

When a new message reaches the server, we check the mask and send it where it should go.

            # performs bitwise on each binary digit - checks if read/write mode

              # if mask AND with 1 is not zero
            if mask & selectors.EVENT_READ:  # 1 << 0 or 1
                self.read(read_mode_callback)
            if mask & selectors.EVENT_WRITE:  # EVENT_WRITE =2
                self.write(server_error_msg, simulation_is_complete, write_mode_callback)