"Rover One" is the combination of several technologies documented by Wizardry and Steamworks in order to create an analog RC drone with a remote VR headset along the lines of a remotely operated vehicle (ROV). The fabrication of the "Rover One" loosely hoovers around IoT technology, by making an ESP32 the centerpiece of the build and then using low-power technology to realize the build.

The failed controller was fished back out, so, it was decided to use Bluetooth Low Energy (BLE) from the ESP32 to control "Rover One" with a standard game controller. Even though the controller used was an 8BitDo controller, it is trivial to adapt "Rover One" to any other game controller that supports connectivity over Bluetooth.

One of the advantages of using a retro / console controller is that the amount of buttons is sufficiently large to cover all the control needs of the build. An SN30 8BitDo controller has one directional pad for all directions, plus two separate joysticks, four buttons for the typical A, B, X and Y buttons, as well as the edge buttons. Not only the buttons, but also a combination of the buttons and joystick movements can be used to create functions like combos (a bit like DJI drones use the diagonal movement of the joystick buttons in order to affect an emergency stop or quick start of their drones).

Video transmission was assured by an analog drone transmitter and the receiver was a very cheap and convenient VR headset with a removable screen labeled PNJ G-SKY 100.

We see the PNJ G-SKY 100 as a builder item, but so sweet given its versatility: the VR headset costs up to USD 60, comes with a screen that is also incidentally a analog signal receiver, the plastic has a nice finish and looks very ripe to drill holes into the headset to add and/or customize it, the wraps are detachable and can be replaced with a street-style urban wrap and the foamy pads that will be pressed against the pilots head seem quite comfortable (albeit something that might have to be replaced in the future).

Traction and the car skeleton is ensured by mecanum wheels powered by DC TT motors that have been purchased together for up to USD40.

The skeleton chassis and DC TT motors are not too great and needed to be customized separately because the ensemble did not really fit together properly and reliably. Nevertheless, these are base-materials for DIY custom builds, such that quality is not that important and can be enhanced by building on top of the base.

Here is a list of Wizardry and Steamworks technologies that have been used to build "Rover One"

• The PTZ caddy that we designed some time ago based on popular PTZ caddies from China as initially created in order to be integrated with "Rover One". The PTZ caddy is a bit of an overkill for this project and one could get away with just mounting the camera on top of the rover, but hey this is a custom build, such that adding camera pan and tilt is easy and convenient given that the caddy was created some time ago.

Here is a list of components and their realization for the "Rover One" project in chronological order.

Power will be provided by combining several 18650 vaping device batteries, up to 3S, which seems to be the maximum that can fit onto the "Rover One" chassis, with a Li-Ion 18650 battery charger. First the batteries are slotted into a 3S holder.

The holder is wired to provide by connecting all the three batteries in series, and then connected to a multi-S battery charger. The battery charger was a random find "Terra Cell" battery charger for multiple-S battery configurations.

From the same lines, the normal voltage is drawn that will power the rest of the build.

The battery holder is wired up and wire terminals are used on either side, glued together to be one single piece.

The Terra charger seems to recognize the batteries well and charges them up adequately, commuting between the voltage for each individual cell / battery and the display of the overall charge for all batteries that output nominal voltage.

The Terra charger is disassembled and holes are drilled into the bottom plate, as well as the base chassis with the mecanum wheels, in order to fix the charger onto the base chassis with screws and washers.

One other concern is that these vaping batteries are pretty powerful, even designed for their capability to fastly output all the amperage contained within them, as well as having a long lifespan, such that any short produced between the batteries, the holder, the charger and the aluminum chassis should be prevented. The connector circuit between the poles of the holder that exposes the terminals of the batteries is even designed on the bottom of the holder, such that the circuit will have to somehow be short-proofed. One impressively and unexpectedly elegant way to ensure that opportunities for shorts are minimized, is to use plastic hot-melt glue to seal off the circuit.

However, the hot-melt glue will not be used conventionally, as in just applied to terminals, but rather the hot-melt glue will be used as a mold around the battery holder that will cover all the bottom part of the holder. In order to achieve that effect, the battery holder is turned upside down with the bottom circuit pointing upward, then surrounded with some blue painter tape raised a few millimeters off the bottom and finally hot-melt glue is poured indiscriminately on top, similar to creating a form, in order to seal all the bottom circuitry inside.

The results are impressively satisfying with the hot-melt glue cooling off to become a sheet that isolates the bottom of the battery holder where the connections between the individual battery terminals are made and the base chassis.

The charger and battery holder can then finally be mounted onto the bottom chassis together with this build providing power to the entire build.

The battery and charger are adequately small to fit onto the base-chassis that has been purchased, but then again, the question is where to place the rest of the electronics. It becomes more or less clear that "Rover One" should at least be a double-decker and constructed on two stages. Here is a lateral view of the double decker chassis that has been derived:

where the battery and charger will fit on the lower layer and the upper level will be reserved for the actual controller and the rest of the instrumentation. Here is a top side view of the chassis:

The double layers are realized by creating two lateral struts mounted along the side of the chassis in order to provide for maximal clearance between layers and at the same time provide sufficient stability to the build.

The struts are fixed onto the bottom chassis and the top layer using screws and washers resulting in a build sturdy enough to crash into a wall without dismembering itself. Similarly, the upper plate is an aluminum plate, fixed onto the struts with screws and washers, that will host the controller box where the circuitry will be placed.

Note that this will make the batteries unreachable in terms of removing them from the charger caddy but this is acceptable because the batteries are not meant to be hot-swapped. Quite frankly, 18650 are designed to have no death, and are typically long-term batteries that can put up with a lot of abuse, the batteries being created to be able to sustain being literally shorted together inside vaping device and with high wattage discharges reaching up to or more.

As a general comment, the blueprinting of the project in terms of electronics consisted in a hunt for devices that would overlap in terms of power requirements. For example, looking at IoT hardware, very often one would find different devices that run at either and , and very often the distinction is extremely strict. Even the WEMOS ESP8266 and the ESP32 differ in terms of power requirements, with the ESP8266 being powered strictly at and the ESP32 strictly needing . That being said, we even had a sticky on the desktop summing up what hardware has been found or purchased and at what voltage it runs, in order to track the various voltage usage and then minimize or fold onto either or technologies. After lots of struggle, the "Rover One" ended up being a strictly powered device, but with the analog transmitter floating up to by design and the camera floating up to .

The main instrumentation consists in the ESP controller, coupled with some DC motor controllers and the rest of the electronics meant to control the rover. Note that in effect, building the "Rover One" is more complex in terms of mechanics, most of the work revolving around the design of the chassis and the alignment of the wheels because the electronics and instrumentation side is fairly trivial.

Back when the project was started, there were great ambitions, with the PCB being tailored for a lot of instrumentation. The following image is an image of the early days design that differs greatly from the final build yet still referential and good to discuss given the differences.

Here are some comments:

• The electronics is designed to maintain two main power lines, one at and one at in order to provide power for any auxiliary circuitry. However, the final build does not contain a power line, with all the electronics being re-selected to run at .
• The WEMOS ESP32 C3 was chosen as the controller (upper-left) but it turned out that the number of required GPIOs would exceed the pins of the WEMOS ESP32 C3, such that the final build ended up being based on a WEMOS LOLIN32 ESP32.

By contrast, the following is an image of the final result.

The main attraction to this board is the small vertical PCB protruding from the base PCB into the air behind the white cable with the red heat-shrink tube. The vertical PCB is a pololou step-up-step-down converter that turns into . Contrasted to the regular buck stepdowns that were in use by Wizardry and Steamworks, the pololou step-up-step-down is fairly expensive but offers a very stable conversion to . The step-up-step-down provides very stable voltage by both stepping down voltage but also by stepping up voltage in case the voltage so happens to drop below the expected input voltage - for example, the minimal design input voltage of the pololou step-up-step-down is about . The decision was made to use this expensive converter because when hard-mechanics are involved, such as motors that need to do physical work, the stability of the circuit always ends up suffering due to fluctuations and peak-voltage drains from the battery. The step-up-step-down converter thereby provides a very stable voltage source to power the rover and is able to cover anything from instabilities caused by physical conditions (ie: the rover ending up stuck and thereby the torque needed to escape generating large voltage fluctuation) and up to the typical low-battery conditions where emergency voltage has to be used to at least reach the operator that can then charge the device.

Eerily enough, the WEMOS LOLIN32 Lite seems to only want to be powered via the built-in battery port on the left of the button because the device was designed to be used in conjunction with a battery. However, for this build, we have a much more powerful battery than the WEMOS would be able to charge in useful time, such that, in order to avoid having to use the internal charging circuit, a mini USB charging cable was severed in order to power the WEMOS LOLIN32 Lite directly from the USB port with the WEMOS being powered directly by .

The two smaller and square PCBs across the side of the PCB are the DC motor controllers, with copper traces on the bottom of the PCB leading to the ESP, in order to implement the movement of the wheels that will make "Rover One" more around.

Then, there is a nice flip-switch added to the back of the rover (in blue), as well as an antenna extension that takes the WiFi and Bluetooth signal and brings it to an external antenna on the outside of the rover.

The rest of the homebrew electronics consists in ports constructed out of JST ports in order to ferry signals and power around. First there are 4 separate JST sockets and 8 small wires that lead to the DC motors on the outside that hook into the instrumentation box. There is one JST connector that provides to the inside of the enclosure. Another JST connector links up with the PTZ caddy and there are several smaller JST connectors that hook up with the analog transmitter and camera.

One very cool trick devised, given that a lot of connections will have to be made with devices exterior to the instrumentation box, consisted in cutting through one of the lateral plates of the aluminium box, then using JB weld glue to glue the sides of the PCB on top of the cutout, thereby constructing a PCB that is exposed both to the inside and the outside of the box, along with the ability to add electronic components right onto the front grill. After the front grill is cut and the PCB glued on top, the grill is then filed down to expose the metal and repainted with a fresh coat of primer, then paint whilst using painter's tape to protect the PCB from being painted over (the left-most image).

Even though it would seem suitable to add the video transmission to the instrumentation section, those components were kept fairly separate, in their original format such that even if they connect to the front grill, they are self standing and will be presented in the video section.

Ironically, video transmission and receptions is fairly cheap, with the required components being short of USD30 for fairly good all-in-one solutions. Even more ironically, we were not able to acquire something that would be adequately cheap, such that the solution settled on has been a "FlyFish Totem RC". Fortunately, the camera was fairly cheap and we managed to secure a cheap Runcam clone that presented identical performance to an original Runcam.

The FlyFish Totem RC is a little analog transmitter gem on and with the full typical range of 48 provided channels, with an output transmission power rated at probably being able to transmit up to or (with LoS), as well as providing the TRAMP protocol for the OSD text.

The FlyFish Totem RC is able to self-regulate its own power (and even provides a regulated output port for the camera) with an input voltage range of to such that the FlyFish Totem RC was patched in directly into the battery caddy without drawing power from the internal pololou step-up-step-down .

As for the camera, the camera chosen was a Runcam knockoff, up to USD 27, that was paired with the FlyFish Totem RC. The camera does not have too bad specifications either and as a Chinese knockoff no-name clone, the customer reception has been fairly good, such that it seems that the specifications are truthful.

The receiver of course will be the VR headset screen that unfortunately does not seem to have a port to extend or amplify the antenna signal such that the VR headset screen will have to be modified at a later date. Fortunately, as mentioned, the PNJ G-SKY 100 VR headset seems to be just ripe for modifications with the sturdy plastic case providing lots and lots of clearance for modifications (additional battery, external antenna and amplifier, alternative street straps, etc.).

For the while, the current setup will have to do, such that the FlyFish Totem RC is fixed on the side of "Rover One" right onto the sideways struts that hold up the second level supporting the instrumentation, making out of the chassis of the rover a massive heatsink. Similarly, the camera is mounted onto the PTZ caddy and both are wired up together.

The FlyFish Totem RC is powered directly from the provided by the batteries, whilst the camera is powered from the internal pololou step-up-step-down converter on the inside of the instrumentation box. Quite conveniently, analog signals and transmissions are very nice to deal with in terms of cabling, such that there is one and only one wire that is connected between the camera and the FlyFish Totem RC, namely the yellow wire that provides the video signal.

For the future and for the record; initially, a BetaFPV camera was selected that turned out to be DOA such that it has to be sent back. Nevertheless, "Rover One" was nearly complete such that we direly wanted to test the FlyFish Totem RC transmitter. Given that we previously realized a large-screen microscope build based on a Raspberry Pi, that, in turn was based on a microscope with an analog video signal, the yellow connector was coupled with the yellow wire (on the pin) and then the connector was grounded (on the side) in order to transmit the microscope image to the VR headset. It worked! - which also meant that the BetaFPV camera did not. Nevertheless, this means that the build is open up to various possibilities given that any analog video signal can be transmitted. Perhaps include a small microcope to take a look at the soil, perhaps a small VHS player, perhaps getting ahead of NASA and Space X and make it on our own to Mars using commodity hardware. . .

Although not related only to video transmission but also pertaining to the Bluetooth connectivity, two antenna ports are pulled, one for the Bluetooth transmission the other for the video, and then two antennas with a good gain are attached to the rover in order to provide more range. It would have been possible to attach larger antennas but it would take away from the overall size of the rover and make it bulkier such that it would not be able to reach too easily underneath furniture.

As it turns out, the traction consisting in the DC TT motors and the chassis that was purchased, as being one of the cheapest components, have been a bit of letdown purely given their design and not really for the quality of the materials. For example, the mecanum wheels are designed to be screwed into the motors using a very long screw yet screwing in the wheels too much, for some reason, also prevents the wheel from moving.

The whole wheel system had to be redesigned, or, more precisely, the wheels had to be fixed. First, the hexagonal plastic strut that was provided, was glued to the wheel using JB weld in order to provide further clearance from the chassis: as you'd have guessed, when the wheels were mounted onto the chassis, the wheels would brush against the chassis itself. We did not even realize such a bad design is possible and as the ESP was being programmed, one of the motors went hot and as it turned out, the motor was trying to spin but was being blocked by the chassis. Similarly, because there was no large screw available in order to connect to the motors, the wheels were hot-glued onto the spindle of the TT motors, making the build permanent. This is not too terrible, except if the motor has to be changed, because messing with the wheels themselves should not be required.

After the redesign, the wheels moved properly such that the ESP could be programmed in order to calibrate the engines and create the necessary controls for the PTZ caddy.

The camera is sweet and very good in low light, but it would be much nicer to include a headlight, and, in particular because there are still plenty of buttons on the controller that are unmapped. A good option is to use a powerful LED light, some of those ranging between to . In this case, a LED was chosen with plain white light to illuminate the path that the "Rover One" will be driving on.

The LED was mounted onto the PTZ arm of the caddy that provides the pitch such that the light will move with the camera itself thereby illuminating wherever the camera is looking. Additionally, for safety and in order to tone down the light a little, a voltage divider was used with and in order to step down to about , which seems acceptable in terms of battery usage, safety and adequate illumination.

However, it is interesting that one could perhaps expand on this idea, and perhaps design a set of types of lighting:

• regular light,
• ultraviolet (UV)
• infrared,
• laser

that could perhaps be switched using the waggle controls on the console controller.

A few notions were preserved whilst programming the ESP for "Rover One":

• Almost a full side of the ESP32 WEMOS LOLIN32 has been used to control the DC motors (8 GPIO pins in total) such that the pins corresponding to the serial TX and RX ports had to be used. This meant that the ESP could only be force-flashed every time. Naturally, this lead to implementing OTA in order to update the software of the "Rover One" remotely via WiFi.
• The ESP32 is programmed using a custom board derivative of the baseline ESP32 but with Bluetooth Low Energy (BLE) in mind in order to connect a Bluetooth gamepad. The firmware is provided by BluePad32 and requires a custom board to be installed that hooks even deeper into the hardware. For that reason, some of the standard functionality that you'd expect to work on the ESP32, in particular matters such as timers or signals, are all out of whack, requiring an alternative way to solve certain problems. One such conflict was detected when trying to control the PTZ motors using the standard servo motors library, that simply would not work due to some timing signals being hooked into by BluePad32 itself. Finally, the problem was solved by using the ESP32 LED strip controller semantics to move the servo motors.
• BluePad32 uses one of the ESP32 cores for all its operations, namely CPU0 or core 0, such that a lot of the programming logic had to be distributed between core 0 and core 1. Operations that involved the controller in any way, were scheduled on core 0 and everything else on core 1. Very careful (meaning mostly finecky) multi-thread programming semantics had to be used because straightforward solutions were made impossible by BluePad32 itself resulting in the janky movement of the rover.
• The controls are all very local to the controller itself, such that the buttons had to be calibrated by observation. However, the default BluePad32 test controller sketch provides a debug snippet that was even preserved in the final Arduino code that prints out the button and joystick movements to the serial console.

    Serial.printf(
      "Gamepad control debug: "
      "idx=%d, dpad: 0x%02x, buttons: 0x%04x, axis L: %4d, %4d, axis R: %4d, %4d, brake: %4d, throttle: %4d, "
      "misc: 0x%02x, gyro x:%6d y:%6d z:%6d, accel x:%6d y:%6d z:%6d\n",
      bleController->index(),        // Controller Index
      bleController->dpad(),         // D-pad
      bleController->buttons(),      // bitmask of pressed buttons
      bleController->axisX(),        // (-511 - 512) left X Axis
      bleController->axisY(),        // (-511 - 512) left Y axis
      bleController->axisRX(),       // (-511 - 512) right X axis
      bleController->axisRY(),       // (-511 - 512) right Y axis
      bleController->brake(),        // (0 - 1023): brake button
      bleController->throttle(),     // (0 - 1023): throttle (AKA gas) button
      bleController->miscButtons(),  // bitmask of pressed "misc" buttons
      bleController->gyroX(),        // Gyro X
      bleController->gyroY(),        // Gyro Y
      bleController->gyroZ(),        // Gyro Z
      bleController->accelX(),       // Accelerometer X
      bleController->accelY(),       // Accelerometer Y
      bleController->accelZ()        // Accelerometer Z
    );

• Mecanum wheels and movement have the advantage that just by individually rotating each wheel, back or forward, various movement directions can be achieved that normally would not be possible using a standard DC car. For example, the "Rover One" is able to strafe-left and strafe-right, which is pretty cool given the First Person View (FPV) aspect of the vehicle.

the movement was calibrated by programming each wheel individually by observation in order to derive the functions nudgeEngineForward(), nudgeEngineBackward(), nudgeEngineTurnLeft(), nudgeEngineTurnRight(), nudgeEngineStrafeLeft() and nudgeEngineStrafeRight() that achieve various movement patterns. Looking at the reference sheet of mecanum movement, lots more are possible, even curved trajectories by using half-speed on the various motors and wheels that could be added to the Arduino sketch.

There are further improvements and features that could be added, some of which more critical than others, all of which can be summarized here.

As a builder item, there are several drawbacks of the PNJ VR headset that will require further customization, but that is why the headset is cheap and that what we do anyway so it's all in good spirit. Mainly, all issues can be traced from the fact that the headset itself is almost disjunct from the screen where the screen contains all the electronics, whilst the headset contains a loupe for magnification and then just plastic and straps to contain the screen and fit on the head of the pilot. That being said, it should be fairly easy to tap into the screen controls and charging ports to pull ports on the outside of the headset, such that the screen wouldn't have to be removed every time it needs to be operated.

The camera is a typical RC / drone camera, a clone of Runcam but with an identical performance and even though the camera performs well in dimly lit environments, it is still not a night-time camera; neither in terms of being IR cut, nor in terms of being thermal. Nevertheless, it should be trivial to just mount a powerful LED onto "Rover One" as headlights that could also be triggered via the controller.