Now we are only supporting the VESC motor controller and we are using UART to communicate to it.

As we want Pacer to become more universal we need to have the ability to add new types of motor controllers.

The challenge is to have an abstraction layer for the motor controller.

It would be great if a user could download the binary file of the firmware and use it to flash the NodeMCU/ESP32 in order to be able to use it.

For now there are 3 things require for Pacer to function correctly:

• Flash Firmaware
• Flash SPIFFS
• Upload the data/ directory containing the configurations and the web files.

Does anybody know any tools or how we could bootstrap a tool for flashing?

Uhg..

I love and hate this Console component. We are able to interact with the Pacer Vehicle very easily which is very good. At the same time the console seems to have too much power over the Pacer vehicle. More to that the Console got quite messy in the code.

Let's try and define what should be the role of the Console be and how can we secure it.

Replication:

Connect 5 clients to the WebSocket server: ws://10.10.100.254:81
Try to access 10.10.100.254/index.html
ESP8266 stalls.

Some ideas:

Have a heartbeat check with all clients. If not response is received back from the client remove the client.

Library that is used: https://github.com/Links2004/arduinoWebSockets

Early on there was an attempt to abstract devices that are connecting to Pacer. However it turned out to be challenging as different devices have different specifications. As of now the connecting devices are mainly controllers and are wireless.

The classes can be found here: https://github.com/faraday-motion/pacer/tree/master/src/components/Device

You can see how currently we are using the abstract device to register controller here:

components/Connection/ConnectionManager.cpp
Each connection type is handling the registration of a pendingDevice that should be abstracted.

void ConnectionManager::handleClientConnections()
{
  if (handleClientInterval->check() == 1)
  {
    this->handleWifiConnections();
    this->handleRadioConnections();
    this->healthCheckWebSocketConnections();
  }
}

components/Connection/Wifi/Wifi.cpp
Wifi.cpp is using the components/Device/WifiDevice.h for its pendingDevice

/** Checks if wifi is instantiated and checks for new clinets wanting to connect */
void ConnectionManager::handleWifiConnections()
{
  if (this->wifi != nullptr)
  {
    if (this->wifi->handleClientConnections() == true) {
      // Log::Logger()->write(Log::Level::DEBUG, "Wifi Detected New Pending Device");
      // TODO:: We have an issue the pending devices are being overwritten here by handleRadioConnections()
      this->pendingDevice = this->wifi->pendingDevice;
    }
  }
}  

components/Connection/Radio/RadioHandshake.cpp
Radiohandshake.cpp is using the components/Device/AbstractDevice.h

/** Checks if radio is instantiated and checks for new clinets wanting to connect */
void ConnectionManager::handleRadioConnections()
{
  if (this->radio != nullptr)
  {
    this->radioHandshake->handleHandshake();
    if (this->radioHandshake->pendingDevice.pending == true)
    {
      Log::Logger()->write(Log::Level::DEBUG, "Flagging a pending radio device.");
      // Copy the pending Device so that FMV can work with it.
      bool registerd = this->controllerManager->registerController(this->radioHandshake->pendingDevice);
      if (registerd)
        this->radioHandshake->pendingDevice.isRegisterd = true; // Flag registration succeeded.
    }
  }

}

components/Connection/WebSocket/WebsocketCommunication.cpp

WebSocket clients are a bit different as they are auto connected and by pass the pendingDevice layer. This should be subject to a discussion.

Now WebSocket clients can register themselves as controllers through the Console.cpp

We are using the following VESC library for being able to communicate with the VESC.
https://github.com/faraday-motion/bldc_uart_comm_stm32f4_discovery
Read more about what I used to implement this here:
http://vedder.se/2015/10/communicating-with-the-vesc-using-uart/

Because that library is written in C and requires callback functions and we cannot set class methods as such callbacks I had to do a workaround that is all but optimal.

You will see that in src/FMV.cpp we have a while loop that checks if there's serial data and triggers the processing of the VESC UART bytes.

// Read Data from VESC  // TODO:: This should be moved somewhere else.
    while (Serial.available() > 0) this->controllerManager->motorController->processUartByte(Serial.read());

I have two assumptions here:

1. This produces garbage on the serial monitor
2. This could be process intensive for the ESP.

Here' where the mess really begins:

Step 1

components/MotorController/MotorController.cpp::processUartByte(usnigned char b)
is calling bldc_interface_uart_process_byte(b) from the bldc_uart_comm_stm32f4_discovery library

Step 2

bldc_interface_uart_process_byte(b) triggers the plain callback in components/MotorController/VescUtility.h called void printValues(mc_values *val)

Step 3

void printValues(mc_values *val) stores the values in a singleton class called VescParams.h.

Step 4

We access the singleton VescParams.h to read those values in different parts of the application.

Note:

For each of the commands that we want to send to the VESC we have to register a different callback.

This is a huge issue and needs to be solved.

Here are some potential solutions:

1. We could process the packets on our own based on the library source code.
   https://github.com/faraday-motion/bldc_uart_comm_stm32f4_discovery/blob/master/bldc_interface.c#L130

2. We can find a better way to register the callbacks.

3. Currently I can't think of a third one.

Note 2

Keep in mind that we need to also abstract the VESC from the MotorController.h class.
See more here: #8