Hardware wish list for next design iteration of Robot Controller

[Alec]

1. Separate battery port on the Control Hub dedicated to powering the SBC only.

2. RP-SMA Female port(s) for attaching external WiFi antennae.

3. Upgraded SBC: better CPU, more RAM, a DSP, ...

4. MIPI CSI port for connecting CSI cameras to the CSI bus on the SBC.

5. ???

[Tom Eng]

Interestingly enough, I believe there is an SMA adapter inside the CH housing (on the controller board). The CH actually comes with an "external" antenna that is mounted inside the plastic housing (under the face that reads "Control Hub").

In testing the WiFi performance with this external antenna was quite good. I'm not sure if I agree about the utility of having an external (external to the plastic housing) antenna option.

[gszczesz]

Another thing to note: we tried to use the worst antenna phones and considered adding a partial Faraday cage to the receiver for better performance. The newer the phone, the more sensitive the radio, the smaller the signal that it could detect and thus when sharing the channel with other phones, the further away those other phones could be and still be detected. We only need the phones to communicate with the robot when it's very close, thus reducing the amplitude of far-away interferes improved performance.

[Tom Eng]

Interestingly enough, I believe there is an SMA adapter inside the CH housing (on the controller board). The CH actually comes with an "external" antenna that is mounted inside the plastic housing (under the face that reads "Control Hub").

In testing the WiFi performance with this external antenna was quite good. I'm not sure if I agree about the utility of having an external (external to the plastic housing) antenna option.

PS "In testing the WiFi performance" means that we actually measured the signal strength using a spectrum analyzer and it was quite strong with the internal antenna installed within the CH housing.

[Alec]

Interestingly enough, I believe there is an SMA adapter inside the CH housing (on the controller board). The CH actually comes with an "external" antenna that is mounted inside the plastic housing (under the face that reads "Control Hub").

In testing the WiFi performance with this external antenna was quite good. I'm not sure if I agree about the utility of having an external (external to the plastic housing) antenna option.

Hi Tom, there are many factors that can affect signal-to-noise ratio in the FTC competition environment, such as:

• size, shape, construction, and movement of the bot
• size, shape, construction, and movement of adjacent bots
• placement of the control hub within the bot
• proximity of the control hub to DC motors within the bot
• proximity of the control hub to DC motors in adjacent bots
• size, shape, and construction of game elements, which vary from season to season
• RF interferences at the venue

If teams had access to the SMA port(s) inside the control hub then teams could mount COTS WiFi antennae in optimal position(s) on the bot in consideration of factors affecting SNR.

Also, if REV has any plans to sell the control hub outside of FIRST, then an SMA port external to the control hub housing could be a feature that non-FIRST customers would need.

[Alec]

1. Separate battery port on the Control Hub dedicated to powering the SBC only.

2. RP-SMA Female port(s) for attaching external WiFi antennae.

3. Upgraded SBC: better CPU, more RAM, a DSP, ...

4. MIPI CSI port for connecting CSI cameras to the CSI bus on the SBC.

5. Rename "SERVO" to "PWM OUT" on Control Hub and Expansion Hub, per industry standard.

6. ???

[Alec]

0. Stream Sensor & Encoder Data from Control/Expansion Hub to RobotController App:

When an OpMode instantiates a sensor object, the REV firmware starts sampling the sensor at the loop rate of the firmware [or appropriate rate]. Likewise for encoder data in the case of a DcMotor object. The firmware streams sensor and encoder the data [asynchronously] to the RobotController App where it is cached. It is a waste time and a waste of CPU and network resources for the RobotController App to have to poll for sensor and encoder data. In the case of unknown I2C sensors, the OpMode loads a subroutine onto the firmware that reads the data. Configuration of I2C sensors is done synchronously as is currently. Ideally, an OpMode could optionally load a subroutine on the REV firmware for any sensor. The subroutine could pre-porcess sensor data and stream data or triggers to the RobotController App as needed.

1. Separate battery port on the Control Hub dedicated to powering the SBC only.

2. RP-SMA Female port(s) for attaching external WiFi antennae.

3. Upgraded SBC: better CPU, more RAM, a DSP, ...

4. MIPI CSI port for connecting CSI cameras to the CSI bus on the SBC.

5. Rename "SERVO" to "PWM OUT" on Control Hub and Expansion Hub, per industry standard.

[4634 Programmer]

0. Stream Sensor & Encoder Data from Control/Expansion Hub to RobotController App:

When an OpMode instantiates a sensor object, the REV firmware starts sampling the sensor at the loop rate of the firmware [or appropriate rate]. Likewise for encoder data in the case of a DcMotor object. The firmware streams sensor and encoder the data [asynchronously] to the RobotController App where it is cached. It is a waste time and a waste of CPU and network resources for the RobotController App to have to poll for sensor and encoder data. In the case of unknown I2C sensors, the OpMode loads a subroutine onto the firmware that reads the data. Configuration of I2C sensors is done synchronously as is currently. Ideally, an OpMode could optionally load a subroutine on the REV firmware for any sensor. The subroutine could pre-porcess sensor data and stream data or triggers to the RobotController App as needed.

The asynchronous model is how the Modern Robotics electronics worked. I realize that it does have advantages, but I wasn't a huge fan of it. For one thing, you had to call waitOneFullHardwareCycle() after motor mode changes or encoder resets to make sure they took effect. Also, if you didn't call waitOneFullHardwareCycle() as part of your OpMode loop, you could get multiple loop iterations with the same stale data. Also, when issuing a bulk read command to the REV firmware, you get all the data at the exact same point in time. If an asynchronous model was used, you can't guarantee that your encoder reads are from the same timestamp. The idea of loading a subroutine for I2C into the REV firmware, while an interesting thought experiment, seems to me like it would cause complexity of a lot of things to go through the roof.

What I would like to see is 1) the REV firmware be open sourced 2) have bulk write and bulk data exchange commands added to the firmware 3) have a mode added to the firmware where it can optionally be configured with "read windows" sort of like the CDIM, and have that I2C data read by an internal timer and included in the bulk read response. I think that would provide a nice balance between simplicity for non-advanced users and non-performance-critical things, as well as the ability for more advanced users to improve efficiency of their code using the bulk read/write/i2c.

[Alec]

...The idea of loading a subroutine for I2C into the REV firmware, while an interesting thought experiment, seems to me like it would cause complexity of a lot of things to go through the roof...

I understand that distributed computing scares a lot of programmers to death, but it is really not that difficult. Just teasing ya!!! Thanks for the valuable info and input.

[Alec]

The asynchronous model is how the Modern Robotics electronics worked. I realize that it does have advantages, but I wasn't a huge fan of it. For one thing, you had to call waitOneFullHardwareCycle() after motor mode changes or encoder resets to make sure they took effect. Also, if you didn't call waitOneFullHardwareCycle() as part of your OpMode loop, you could get multiple loop iterations with the same stale data. Also, when issuing a bulk read command to the REV firmware, you get all the data at the exact same point in time. If an asynchronous model was used, you can't guarantee that your encoder reads are from the same timestamp. The idea of loading a subroutine for I2C into the REV firmware, while an interesting thought experiment, seems to me like it would cause complexity of a lot of things to go through the roof.

What I would like to see is 1) the REV firmware be open sourced 2) have bulk write and bulk data exchange commands added to the firmware 3) have a mode added to the firmware where it can optionally be configured with "read windows" sort of like the CDIM, and have that I2C data read by an internal timer and included in the bulk read response. I think that would provide a nice balance between simplicity for non-advanced users and non-performance-critical things, as well as the ability for more advanced users to improve efficiency of their code using the bulk read/write/i2c.

Yes, it would be great if the REV firmware were open sourced. The Expansion Hub appears to be running Silicon Labs’ open-source [URL="https://www.micrium.com/rtos"]Micrium

[Alec]

The asynchronous model is how the Modern Robotics electronics worked. I realize that it does have advantages, but I wasn't a huge fan of it. For one thing, you had to call waitOneFullHardwareCycle() after motor mode changes or encoder resets to make sure they took effect. Also, if you didn't call waitOneFullHardwareCycle() as part of your OpMode loop, you could get multiple loop iterations with the same stale data. Also, when issuing a bulk read command to the REV firmware, you get all the data at the exact same point in time. If an asynchronous model was used, you can't guarantee that your encoder reads are from the same timestamp. The idea of loading a subroutine for I2C into the REV firmware, while an interesting thought experiment, seems to me like it would cause complexity of a lot of things to go through the roof.

What I would like to see is 1) the REV firmware be open sourced 2) have bulk write and bulk data exchange commands added to the firmware 3) have a mode added to the firmware where it can optionally be configured with "read windows" sort of like the CDIM, and have that I2C data read by an internal timer and included in the bulk read response. I think that would provide a nice balance between simplicity for non-advanced users and non-performance-critical things, as well as the ability for more advanced users to improve efficiency of their code using the bulk read/write/i2c.

Yes, it would be great if the REV firmware were open sourced. The Expansion Hub appears to be running Silicon Labs’ open-source Micrium uC/OS realtime OS and Micrium uC/OS-III realtime Kernel. The C source code for the Kernel and OS is maintained on GitHub. The Micrium OS and Kernel is very impressive and highly capable so it is quite feasible to add sensor/encoder streaming capability to the Expansion Hub, as well as support for user defined subroutines for reading and pre-processing sensor data.

The main issue is that the OpMode is running in a JVM. The OpMode needs sensor data in realtime so currently the OpMode has to send a request for sensor data to the Expansion Hub every 5 milliseconds and for every sensor. The JVM is not designed for performance nor timeliness. The OpMode can be delayed in sending requests for sensor data so it is not possible for the OpMode to have realtime data from the sensors. Any delay in access to sensor data affects the OpMode's ability to send motor and servo commands in a timely manner. Also, the processing overhead of having to send requests for sensor data is counterproductive to achieving adequate performance of an OpMode that is running in a JVM.

Moreover, the minimum sampling rate of a sensor varies from sensor to sensor. One sensor may be be able to produce new samples every 10 ms while another sensor may only be able to produce new samples every 100 ms. Plus, the minimum sampling rate of a sensor can vary between different sampling modes of a sensor. It is a waste of resources to read a sensor every 5 ms when it can only produce new samples every 100 ms.

There is no need for the OpMode to have to waste processing and network resources to send a request for data and there is no need for the Expansion Hubs to have to wait for a request for data before it reads the sensors:

The Expansion Hubs can read sensor data at the minimum sampling rate (or greater) of the sensor and send the samples in realtime to the Robot Controller. Likewise encoder counts and velocity data can be sent [in bulk] at the minimum sampling rates of the encoder and/or velocity calculations.

A realtime queue service (RTQS) on the Robot Controller queues incoming samples. Each sensor/encoder can have its own queue. Optionally, the Expansion Hub can put a timestamp on each sample as it is captured and the RTQS can put a timestamp on each sample as it arrives. To be clear, the RTQS isn't running in a JVM.

The OpMode runs concurrently with the RTQS. The OpMode analyzes the sensor queues of the RTQS on every iteration of the control loop. If the size of any queue is greater than one, the OpMode will know that it is late in processing the samples. In some cases, the OpMode will be several hundred milliseconds late. Having access to the older samples of a sensor/encoder will enable the OpMode to recover more gracefully than if the older samples were lost as is currently the case. Samples older than a certain period of time will necessarily be lost since the RTQS cannot allow the queues to grow unbounded.

The RTQS can keep a record of queue consumption patterns and anomalies so that teams can identify and address performance issues with their OpModes. By eliminating the processing overhead of sending read requests to the Expansion Hub, and by having faster access to sensor data, the OpMode stands a better chance of sending motor and servo commands to the Expansion Hub in a timely manner.