Prototype Design for the CommandHand

Overview

The standard for RC vehicles is a transmitter-receiver pair with a proprietary wireless data protocol. The CommandHand is meant as a study of an open-source alternative as well as a more intuitive alternative to the joysticks and buttons of the transmitter provided by a CapSense handheld.

Overall system description

The CommandHand is based on an Infineon PSoC Pioneer Kit. The kit provides 4 haptic objects: 2 CapSense buttons, 1 CapSense trackpad, and 1 proximity sensor loop. These form the base set of haptic inputs for the CommandHand.

The CommandHand connects to an ESP32 Development Kit module in Station mode. The haptic commands ("gestures") are interpreted and encoded on the PSoC Pioneer Kit and transmitted over a WiFi link to the rover DUC ("device under control").

The DUC consists of a NXP Buggy3 rover with an added ESP32 module connected to the controller RDDRONE-FMUK66. The WiFi module is in the Access Point mode (AP). The CommandHand connects to this AP to form the wireless command link. The MAVLink protocol is used across the WiFi link.

The CommandHand device also requires battery operation, which is a side project.

System Component: The CommandHand

The CommandHand is a battery-powered handheld device with haptic input, used as a remote command of an RC rover car. In the heart of the CommandHand is the Infineon PSoC 4100S board along with the flex board which supplies the haptic inputs. The PSoC Creator IDE/SDK is used to program the device.

The prime function of the CommandHand is to generate haptic commands and send them to the DUC. This breaks down into the following: I/O between the haptic objects and the PSoC, interpretation of inputs as commands (and possible output to the RGB led as feedback on the quality of the input), mapping of the commands to MAVLink messages, and sending them over the ESP32 WiFi Link.

The commands required for the drone are not many, consisting of three elements: direction of motion (fwd/rev), throttle (pwm/rpm), and steer angle. The following is a list of a possible mapping of haptic inputs and command elements:

• FWD/REV are mapped to the two CapSense buttons. This will require two-hand operation (see Steering below).
• ANGLE, the steering angle, can be mapped to an arc in the lower half of the trackpad, representing the possible angles of the rover's steering knuckle. A single finger can be used to dynamically change the steering angle of the rover. There are two possible implementations here: one is to map the arc to absolute angles, and the other is to map the arc to a simple left-right increase-to-saturation relative to the midline of the trackpad. There are pros and cons for each implementation.
• RPM, or THROTTLE, is the speed (in RPM) that the rover is moving in the current direction and with the current steering angle. One way to control the RPM is with the proximity sensor, mapping the sensed proximity to RPM, for example, the closer the sensed object, the higher the RPM. Depending on the interaction between the touch-based trackpad and the proximity loop, there might be a danger of misinterpretation of the ANGLE and RPM command components. Another way is to map the RPM to a touch "slider" in the upper half of the trackpad. Ideally, this would be an up-down slider instead of a left-right slider (which is more suitable for the ANGLE).

Once interpreted, the commands are sent to the DUC. There are several ways to do this, and the best implementation will be the one that conforms most closely to the way the DDRONE-FMUK66 controller actually controls the rover. In terms of the MAVLink protocol, the commands can be messages based either on the instantaneous values of the 3 command elements of the interpreted haptic inputs (that is, a different message for each element), or on an aggregate snapshot of the 3 command elements (that is, each message contains the current "state" of the CommandHand). The latter has the advantage of providing for a smoother control, but the possible disadvantage of sensitivity to timing. To alleviate this sensitivity, the commands on the CommandHand side of the link can be sent at a frequency higher than the possible mechanical response of the DUC, and be "diff"-ed at the other end by the controller.

System Component: The WiFi Link

The WiFi link necessary for remote control is implemented by a pair of ESP32 development modules, connected on each end to the main processor. On the CommandHand end the module is connected to the PSoC 4100S, and on the DUC end it is connected to the DDRONE-FMUK66, both by serial protocols (SPI or I2C is configurable on the ESP32s). The module on the CommandHand is in mode Station, while the one on the DUC is in mode Access Point (AP), so the CommandHand connects to the DUC AP SSD with credentials.

The ESP32s are programmable using the Espressif SDK. They require 3.3v of input voltage, which is available on the PSoC 4100S, but has to be stepped down on the DUC side directly from the battery as the DDRONE-FMUK66 runs on 5.3v.

System Component: The Rover

The NXP Mobile Robotics Buggy3 is already equipped with a standard TX/RX RC pair, namely the FlySky FS-i6S 10-channel transmitter and the FS-iA6B receiver, communicating of the proprietary AFHDS3. (Technically, the FS-i6S is an overkill for the rover as it is meant to control quadcopter drones, but it is the controller of choice for the NXP Development Drone/Rover. Incidentally, this is one of the motivators for the design of the CommandHand.)

The ESP32-based WiFi link is meant to replace the FS-i6 pair. This requires reprogramming the controller to receive the motion commands over SPI/I2C (connected to the ESP32 module which provides the WiFi AC for the CommandHand) instead of the RC receiver FS-iA6B).