The Mech Warfare turret concept I’m developing involves having basically two independent robots, the actual robot and the turret.  To make that be controllable in a sane way, the control station will command and receive telemetry from both simultaneously, allowing control actions to be given in the camera frame of reference.  Otherwise, remote piloting is… very challenging.

This could be done just by having two separate transmitters.  Since the nrfusb that I’m using is spread spectrum, many transmitters can easily co-exist at the same time.  However, the protocol is designed such that a single transmitter can simultaneously communicate with multiple slaves at the same time, simply by switching channels more frequently.

I’ve been developing a new bi-directional spread spectrum radio to command and control the mjbots quad robot.  Here I’ll describe my first integration of the protocol into the robot.

To complete that integration, I took the library I had designed for the nrfusb, and ported it to run on the auxiliary controller of the pi3 hat.  This controller also controls the IMU and an auxiliary CAN-FD bus.  It is connected to one of the SPI buses on the raspberry pi.  Here, it was just a matter of exposing an appropriate SPI protocol that would allow the raspberry pi to receive and transmit packets.

With a protocol design in hand, the next step was to go and implement it.  My goal was to produce a library which would work on the nrfusb, and also on the auxiliary stm32g4 on the mjbots pi3 hat.  In this first implementation pass however, I only worked with the nrfusb as both transmitter and receiver.

While developing this, I had more than my share of “huh” moments working from the datasheet and with the components.  To begin with, the initial nrf24l01+ modules I got were all Chinese clone ones.  While I was having problems getting auto acknowledgement to work, I discovered that the clones at a minimum were not compatible with genuine Nordic devices.  Thus I reworked genuine parts into the modules I had:

Last time I discussed the rationale for building a custom control and telemetry solution.  Here I’ll describe the protocol design a little bit, before discussing the implementation in a future post.

Frame design and frequency hopping

The basic idea is that the transmitter sends a frame to the receiver every 20ms, and each frame is sent on a different radio frequency.  A set of frequencies and their order is generated pseudo-randomly based on a “key” that the transmitter and receiver each share ahead of time.  The receiver replies on the same frequency with its telemetry.  Then the transmitter and receiver each switch to the next frequency in the list to get ready for the next frame.

Now that I have both sides of the nrf24l01+ link covered, it was time to design a protocol to take advantage of them.

Design space

To recap, what I needed was a reliable means of commanding the robot and receiving telemetry, even in congested radio environments.  At competitions or events like Maker Faire, Robogames and such, the wireless environment is often totally trashed.  Hundreds of devices are operating in close proximity, across all spectrum bands, including plenty of things that probably aren’t licensed to be transmitting in the first place.  When we first built Super Mega Microbot, we used a custom protocol with a 5 GHz wifi transmitter as the physical layer and selected USB based dongles which allowed control over the physical layer.  USB proved problematic, and with national RF regulations, it is extremely challenging to find wifi devices which provide that level of control at the RF layer.  Also, even with full physical layer control, wifi is difficult to make work in a reliable manner as there is so much congestion in both the 2.4GHz and 5GHz bands and the channels are so wide.

In order to bring up the final piece of the raspberry pi 3 hat, the nrf24l01+, I wanted a desktop development platform that would allow for system bringup and also be useful as a PC side transmitter.  Thus, the nrfusb:

Similar to the fdcanusb, it is just an STM32G474 on the USB bus, although this has a pin header for a common nrf24l01+ form factor daughterboard.

The next steps here are to get this working at all, then implement a spread spectrum bidirectional protocol for control and telemetry.