My decision to follow ROS conventions for my Micro Sawppy rover control software also meant taking on some of the challenges of adapting manual control conventions to an automation-centric world. I remain optimistic that this short term pain will prove worthwhile long term, but it’ll be some time before I know for sure.

I chose an ESP32 as my rover brain, thanks to its feature set being a good match for my ambition to design a low-cost entry-level rover. The cost-cutting decision to move hardware from Raspberry Pi to ESP32 has a big impact on the software environment. From Python running on a general purpose Linux-based operating system to C running on a bare-bones FreeRTOS environment optimized for embedded systems. While I’ve written a C version for Sawppy’s alternate Arduino control scheme, I couldn’t port my old code straight across due to my new ROS-centric focus.

This is far from the first attempt at a ROS-friendly Sawppy rover code base. I tried to do it once myself before aborting that effort due to unneeded duplication. I looked at Rhys Mainwaring’s rover software stack for ROS Melodic to see if I could adapt it to Micro Sawppy’s ESP32. Logic-wise, it follows all the ROS conventions I wanted to follow, but it also used all the ROS software frameworks I won’t have on an ESP32. I also wanted more abstraction between rover chassis math and actuator code. In ROS this is the job of ros_control which Rhys plans to adopt, but that is part of the ROS infrastructure I won’t have on bare ESP32 FreeRTOS.

So I went back to something I created as part of my aborted effort: a Jupyter notebook for working through my rover math. Jupyter has since evolved into JupyterLab but it didn’t seem to have any problem opening up my old notebook. Thanks to all the markdown documentation I had written alongside my Python code in the Jupyter notebook, I could quickly get back up to speed on my thinking on the project. Reviewing my code months later, I even found and fixed a bug that slipped through earlier! I’m not sure this is the most elegant fix, my Python code is not very “Pythonic” because I still think like a C programmer. It is technically a bug, but today it is a feature because I’m porting it to C that will compile for ESP32. My plan was to build a FreeRTOS task that takes a desired rover chassis movement command similar to a ROS cmd_vel message, and outputs data similar to a ros_control message… but then my plan changed.

One of the things I knew I wanted to do for my Micro Sawppy rover’s ESP32 brain was an option for wired analog joystick input. This proved useful for Sawppy V1 and I wanted it for Micro Sawppy as well. Not just as a backup control method, but as the first test in my hypothesis that I will benefit from following ROS precedents for generic messages. In addition to the evergreen ambition to give Sawppy autonomy, I want to support the following manual input control mechanisms:

• Wired analog joystick for noisy wireless signal environments.
• Web-based control similar to what I created for SGVHAK rover and adapted to Sawppy.
• Bluetooth based control to connect with devices like the BBC micro:bit.
• ROS2 joystick control message via micro-ROS.

If I have a generic message type resembling ROS joystick message, each of these input methods can theoretically be isolated in their own FreeRTOS tasks. They all post the same message type to the same message queue, so the rest of Micro Sawppy doesn’t have to care about where their input came from. Swapping input was something very difficult to do on SGVHAK rover software and I want to do improve this time around.

So as a starting point I wanted to take my quick hack of ADC joystick support in my FreeRTOS play project and rewrite it to be something suitably robust for Micro Sawppy. Since it was a quick hack, there were a few weird things that happened but I chose not to worry about it at the time. Thinking I’ll sit down and figure it out later. It is later and… I failed to figure it out. But I did devise a workaround so I can continue with the project. I’ll come back and update this paragraph if I figure it out later.

The issue center around ESP32’s ADC (analog-to-digital converter) peripheral. I had been familiar with ADC peripheral on a Arduino’s ATmega328, which can read values in a range from 0V to +5V via analogRead(). The ADC on a PIC16F18345 works in a similar manner. The ESP32 is a 3.3V chip so I had expected its ADC to read the range from 0V to +3.3V but I was wrong. By default it only reads from 0V to 0.8V. We can configure a signal attenuator to increase range of ADC sensitivity, but even at maximum attenuation it only claims to read from 0V to 2.6V.

This presents an issue with analog joystick inputs, which are electrically potentiometers that feed a voltage value somewhere between its input max voltage and ground. Wiring such a device up to the ESP32’s 3.3V supply means we’ll lose the ability to read the high end of the joystick corresponding to the range between ADC maximum of 2.6V and 3.3V. It also means the joystick’s center position will return about 1.65V which is higher than midway between 0V and 2.6V. So I had expected ADC readings to be higher than what I would expect.

The reality was just the opposite, they were lower instead. I configured the ADC for 9-bits resolution, so the values are anywhere from 0 to 511. Midway would be 256, but joystick center actually correlated to ~220. And even though I expect to hit maximum value partway through the high range of joystick motion, I never got there. Maximum value never exceeded ~460. I used a voltmeter to measure the input and confirmed +3.3V, but the reading wasn’t close to the actual maximum value of 511. Several rounds of fiddling with configuration flags did not change this result.

So as a workaround, my new joystick code does a range check upon powerup. It assumes the joystick is centered at powerup (hopefully reasonable assumption when they are spring loaded) and waits for me to move each axis through its minimum and maximum values and press the button. Before that first button press, my code tracks the highest and lowest values seen, which are used to normalize joystick message output to the range from -1 to +1 that is used in ROS joystick message. I’m using some very inexpensive joysticks whose potentiometers drift significantly, so maybe a range check is a good idea anyway. Either way it’s good enough for me to move on.

It was time well spent to study my batch of commodity breakout boards for the DRV8833 DC motor driver IC. It reinforced that I should not take random instructions downloaded online at face value, even though in this case the errors wouldn’t have been relevant to my planned usage. Armed with confidence I understand how to use the board I have on hand, I proceed to the next step: verify I could write code to control one with an ESP32 and its MCPWM peripheral.

My self-education FreeRTOS project was created with this future in mind when I started by controlling a L298 DC motor driver IC. The first exercise used the control scheme utilizing three pins per motor (two digital for state, one PWM pin for magnitude) which is compatible with the TB6612 but not DRV8833. The beauty of FreeRTOS was that I was able to isolate code specific to this control scheme in its own FreeRTOS task. In theory, all I would need to do is to write another task with DRV8833’s control scheme (a pair of PWM pins per motor) and swap out the motor driver control task. The remainder of my test program, from the joystick ADC to the heartbeat status LED, would remain untouched and blissfully unaware I’ve switched my motor control task.

I’m happy to report theory matched practice this time! The problem I encountered was unrelated to FreeRTOS. It was really easy to get one motor up and running but I was tripped up by my misinterpretation of Espressif documentation when trying to run two motors simultaneously at different speeds. Each MCPWM unit on a ESP32 can control three motors, and each MCPWM unit had three timers. The quote from Espressif documentation that I misunderstood was:

Each A/B pair may be clocked by any one of the three timers Timer 0, 1 and 2. The same timer may be used to clock more than one pair of PWM outputs.

I tried to run two pairs of PWM outputs (one pair per motor) with the same timer, which is explicitly allowed by the documentation and generated no compiler or runtime errors. However, the fact that it is possible and allowed doesn’t mean it actually does what I want. By using the same timer, I had also locked those motors to the same speed. Different speeds require separate timers. Which is why MCPWM offers up to three timers so we can run each motor at a different speed. Once I realized my mistake and understood what was going on, it was an easy fix to get both motors up and running each with their own timer. With both motors running on my existing cardboard testbed, I thought it was time to upgrade to a fancier (but still cardboard) testbed.

This coding practice project is publicly available on GitHub.

After deciding I should learn to use FreeRTOS as part of my ESP32 projects toolbox, I read through the free e-Book PDF. I don’t understand all of it yet, but it built a foundation. Enough for me to start a practice project using some basic FreeRTOS features. What’s the first thing I did? What we always do in embedded hardware: blink a LED!

I’ve used this particular ESP32, mounted on this pink breadboard, for several projects. I had a few external LEDs configured on this pink breadboard for experimentation, and that was because I somehow never noticed that there was a second LED available for direct use on my ESP32 dev module. I knew there was a red one to indicate power, but I didn’t notice the blue one until this project. Apparently this particular ESP32 development board (*) is not a direct clone of Espressif’s official ESP32 DevKitC, because that had only one red LED to indicate power. I have no idea how popular this particular two-LED layout is among ESP32 development boards, I’ll have to keep an eye out as I buy more.

Anyway, this board has a blue LED wired to GPIO2, who still got routed to the same pin as the Espressif module. The LED is wired in parallel and should not interfere with using that pin as output. Though it might affect the signal if I use it as input. I spun up a FreeRTOS task purely for the task of blinking the LED at regular intervals, just to verify I could. My first effort put the ESP32 in an infinite reset loop, and I eventually figured out it was caused by insufficient memory allocated to task stack. I was very surprised that a simple LED blinker needed more than one kilobyte of stack, but it’s not the most important thing right now so I’ll look into it later.

After I successfully created a FreeRTOS task and see it running blinking the onboard blue LED, I proceeded to set up my first message queue. Queues are the simplest way for FreeRTOS tasks to pass data to each other. I copied code from my earlier ADC experiment to read position of an analog joystick, and queued the joystick position message for retrieval by another task. First run of the reader task simply dequeued the joystick position and printed to serial terminal, but that was enough to verify I had the queue running correctly.

With those basic pieces established, I then wrote two more tasks. One reads the joystick position and puts motor control commands into yet another queue, and finally a task that reads motor control commands and adjusts MCPWM control signal for the L298N motor driver accordingly.

This exercise was a good test run to verify I could get the advantages I hoped to get by adopting FreeRTOS.

• By writing individual subareas as tasks, I could test them individually. In this case, I could smoke test the ADC task by writing another task to read the data it queued.
• Each task could be in charge of its own ESP32 configuration. ADC configuration is handled by the joystick reading task, separate from the other tasks. And likewise MCPWM configuration is handled by the L298N output task.
• Tasks are run independently from each other, and more importantly, can be modified independently. I found the blue LED was obnoxiously bright and went into my LED blinking task to reduce the on time to a brief flash and extend the time between flashes, and doing so did not affect timing of other tasks. Reading the joystick and sending motor control signals do not necessarily have to run in sync, I could update motor speed more often than reading the joystick, which would be useful if I wanted to add motor acceleration logic.

That last item is especially important. If I learn enough to design my interfaces (FreeRTOS queues) right, I could swap out FreeRTOS tasks without worrying that I would interfere with other tasks. I want this design to scale from micro Sawppy to regular size Sawppy V2 by swapping out different modules written for different motor controllers. By similar token, it should be easier to do quick hacks like swap out a single steering motor as SGVHAK rover had to do. I also want different control input options, from simple wired joystick to web UI to ROS messages, each of which would be a different task module but they could all use the same message queue format to communicate with the rest of the rover.

Knowing how to set up FreeRTOS tasks and queues aren’t nearly the whole picture of using FreeRTOS, but it gave me a good introduction and built confidence for continuing forward. And as a side effect of this software project, I also made a valuable non-software discovery: cardboard backing for electronics prototypes.

[Source code for this project is publicly available on GitHub]

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

After successfully installing PlatformIO’s ESP-IDF support (and a sigh of relief nothing else seems broken on my computer) I resumed practicing writing code for ESP32. The next exercise was motivated by Emily’s optical audio decoder project where we traded a few e-mail about generating stepper motor signals. For her project she used an Arduino and the AccelStepper library, but it has a maximum speed of roughly four thousand steps per second on classic Arduinos. I was confident the ESP32 can do far better than that, and decided to try it myself.

It was also an opportunity to play with a Trinamic TMC2208 breakout board sometimes called the SilentStepStick. I think this board might be a Trinamic original design, but there’s a slight chance they just hosted materials on their website since it was such a popular use of their chip. Either way, there are a lot of Amazon vendors selling these in affordable multi-packs(*) targeting the 3D printer market. Mostly for people who are unhappy with the high-pitched whine of many inexpensive 3D printers, because TMC2208 is a good choice for helping a printer run much silently than they would on the very popular A4988 driver chip that helped start the current wave consumer 3D printers. My own 3D printers had A4988 drivers soldered on the board so I couldn’t use these modules to upgrade, but I foresee these modules becoming useful in other projects.

In the current Sawppy rover context, these drivers may become useful if I investigate using stepper motors in a future rover iteration. I’ve already received requests to drive and steer Sawppy wheels with NEMA17 style stepper motors commonly used in 3D printers, and there’s always that mythical robot arm that my rover is still patiently waiting for. Commodity NEMA17 motors typically have far less torque than LX-16A serial bus servos, but I’m not sure it is a critical difference for a rover and the best way to find out would be to build one.

But for now I’m just looking at the stepper motor driver, which is commanded by two signal pins: one signifying direction, and another that signals a step for the stepper motor. Direction pin is fairly trivial, it’s the step pin that presents a challenge. Generic portable code like AccelStepper couldn’t reliable pulse the step pin at high speeds, that requires coding to the hardware as GRBL did for the ATmega328.

For the ESP32, my experiment used the ADC peripheral to read the position of a potentiometer and the LED control hardware PWM module to generate step pulses. This module is optimized for dynamic adjustment of pulse width duty cycle during application execution, but stepper motor control is a bit of a off-label use where I left the duty cycle at 50% and changed the PWM frequency at runtime in response to knob position.

According to LEDC peripheral documentation, it is theoretically capable of up to 40MHz pulses at 50% duty cycle. However, for any given configuration, the ESP32 is constrained to a subset of the total range of speed possible. I’m not sure how feasible it is to reconfigure the LEDC peripheral at runtime, but such tricks will be required for anyone with ambition to generate a wider range of pulse frequencies. In my exercise it is limited to a range of 32 Hz to 32.5kHz, which is plenty for today as proof we can surpass the 4kHz limit of AccelStepper on a ATmega328. A stepper motor’s torque diminishes as the speed rises, so I expect the stepper motors will run into mechanical problems well before becoming limited by ESP32 PWM frequency range up to 40MHz.

Once I got this exercise up and running, I started eyeing a desirable luxury advertised by PlatformIO: source-level JTAG debugging.

Code and schematic for this practice exercise is publicly available on GitHub.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Based on my limited experience, the installation script for ESP-IDF (Espressif IoT Development Framework) made some assumptions about an ESP-IDF developer’s computer, including the all-too-common assumption that nothing else will be on the computer. This is problematic for several reasons, but the one that made me pull back was Python. Python is infamous for its problems keeping track of different version and their associated code libraries. It’s such a common problem there are tools made specifically to help developers keep Python ancillaries organized. I’ve had first experience with venv and conda and I understand there are many others. In the absence of such isolation in the default installation script, I went online looking for others who have taken a stab at keeping ESP-IDF from messing up the rest of my computer.

I found a few blog posts and GitHub repos, but what made me happy was a reminder that I already have experience with one solution to this problem: PlatformIO has support for ESP-IDF development. I encountered PlatformIO earlier in the context of HX711 strain gauges interface with an Arduino Nano, so my computer already had PlatformIO on board configured for Arduino on classic ATmega328. I can switch it to Arduino on ESP32, but right now I’m more interested in PlatformIO’s promise to make ESP-IDF easy to install, isolate, and eventually uninstall.

There are a few downsides to this approach. First is the fact I’m no longer using ESP-IDF directly, and thereby adding the possibility that a problem might be caused by PlatformIO instead of Espressif or myself. I would also have to switch over to PlatformIO project structure which is not the same as the ESP-IDF application template. This had greater repercussion than I initially thought, because it’s not just a matter of where the source files were placed. While those source files are still calling the ESP-IDF API I can read in Espressif documentation, the portions of documentation about project configuration may or may not apply. When working directly in ESP-IDF, a lot of project configuration is done by running idf.py menuconfig and that’s not necessarily the case anymore. The people who work on PlatformIO ESP32 support recently added some sort of compatibility in response to user requests, so that’s something I’ll have to look into later.

I’m willing to accept some limitations in exchange for PlatformIO’s ability to keep ESP-IDF Python separate from anybody else’s Python on my computer. As long as I can figure out how to do what I want to do on an ESP32… which means it’s time for more ESP32 programming exercises!

Since I decided to learn to write code for ESP32 using Espressif’s own tool ESP-IDF for the sake of following official instructions, I went straight to the official directions for installing ESP-IDF and saw it was the “run this one script to install everything” type of instruction. This is not itself a problem, but when I saw that ESP-IDF had a lot of Python scripts, that made me suck air through my teeth. Automated scripts doing unknown things to Python (without mentioning any kind of environment isolation like venv or conda) sets off many alarms. Hesitant to run ESP-IDF installation script on my main computer, I tentatively dipped in my toes by using a computer running Ubuntu I could dedicate to this experiment. A long but uneventful installation process enabled me to compile the ESP-IDF project template and I proceeded to do a few introductory projects on this test machine.

After the trivial blinking light exercise, I moved on to the ADC (analog-to-digital converter) peripheral. When I built a wired handheld controller for Sawppy V1 with an Arduino Nano, its joystick position was read using an ADC and I expect I’ll need something similar again for micro Sawppy running on ESP32. The unexpected twist I had to learn was the attenuation parameter for ESP32 ADC input. Most microcontrollers ADC can read the range from zero volts to input voltage level. (For an Arduino Nano, 0V to 5V.) So I expected the ESP32 to read from 0V to 3.3V. But by default it only reads up to a much lower level and, even with maximum configurable attenuation, it only reads from 0V to roughly 2.6V. Meaning the joystick potentiometer’s center point will not map to the middle of the allowable range of values. But I was able to take Espressif’s sample ADC project and simplifying it for my needs. I removed all the parts that dealt with calibration and conversion to an accurate voltage reading. Such efforts are largely wasted on a low-quality joystick anyway, they drift far more than the ESP32 will.

The next exercise was to take that ADC data and do something with it. I expect to use ESP32 MCPWM peripheral to control micro Sawppy’s six rolling wheels, so I started learning how to use the LEDC peripheral to generate control signals for micro Sawppy’s four corner steering servos. When an Arduino ESP32 project implements the servo() command, they usually turn to LEDC and I decided to follow suit. Generating a one-to-two millisecond signal every twenty milliseconds is well within the capabilities of the LEDC peripheral, and at the end I had a simple ESP32 servo tester generating servo control signals based on the position of a potentiometer.

So far so good. Out of all operating systems at my disposal, Ubuntu was the least problematic one and I’m glad it passed the first few tests. But this was a test computer, with nothing else on it to break. Certainly no other critical Python dependencies. In contrast, Apple Mac OS X is infamously temperamental about its integrated Python and woe to anyone who messes with it.

Windows lies somewhere in between, with no hard system dependencies to fatally break, but still a complicated relationship with Python. Still wary, I whipped up a Windows test computer and ran the ESP-IDF installer. According to ESP-IDF Windows setup page, it was supposed to install associated dependencies including Python 3.7. But when I launched idf.py I got a Python 2.7 error.

error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

Ugh, what a mess. Now I’m very glad I had used test computers for these experiments. I shall proceed to wipe them clean and consider alternate options.

[Practice projects described in this post are publicly available on GitHub]

I was a little disappointed when I learned that the ESP32 can only use a tiny fraction of its vast peripheral interface capabilities due to the fact there are only a few physical I/O pins to be allocated among them. But to be honest, roughly 20 is a fair number in terms of controllers in this price range. It’s only “few” when compared to literally hundreds of possible uses for those pins. It also makes sense when we think about the target market for the ESP32: it was derived from the ESP8266, and they are both intended to act as a WiFi interface to some device, not to be in charge of a large complex thing. So does my little rover qualify as a small focused-purpose device that needs a WiFi interface? I think so, but it’s a tight fit.

I originally intended to drive L298N by digitally setting the direction on its two input pins and put a PWM signal on the enable pin to control velocity. The straightforward implementation of this would require 3 pins per wheel. Six wheels mean 18 pins, and I still need four more. One for each of the four corner steering servos. I don’t think I can get 22 output pins on the ESP32 dev board I have. Fortunately it isn’t quite that bad, because all three wheels on one side of the rover are always rotating in the same direction, so they can share the same direction control pins. Two pins to control all left wheels, two more to control all right wheels, and one pin for each of the six wheels for PWM add up to ten pins, plus four more for corner steering servos add up to fourteen pins. This will work.

Alternatively, I can implement the control scheme used by Espressif’s sample program for controlling a L298N motor controller using ESP32 MCPWM peripheral. I’m skeptical of this one, though. It wants the enable pin to be tied high, and controls speed by using PWM signal on the direction pins. As per my understanding of L298 data sheet, this toggles between powered state and brake state. Which sounds like an extremely inefficient way to control velocity. Nevertheless, doing this would require 2 PWM pins for each of the six wheels. Plus the four corner steering pins for sixteen output pins. Even though there are only fifteen easy to use output pins, I can probably make one of the caveat-encumbered pins work for the sixteenth.

The final consideration: what would happen if I decide I don’t want to use the L298, and want to use a different motor controller instead? I haven’t studied them as much as I’ve studied the L298, but the few I’ve glanced at appear to use one of the two above control schemes. Perhaps the L298 is established enough that most newer DC motor controller offer drop-in compatibility with L298 control signals? Even if not, I believe a mini rover using another DC motor controller would still be feasible to implement on an ESP32. And the best way to know for sure is to start writing some code.

Now that we’ve celebrated the success of Perseverance rover’s arrival on Mars, I resume working on my little rovers. I was happy to discover that I’m less intimidated by the ESP32 than I was over two years ago. I now have a basic understanding of its capabilities and the ecosystem that has grown up around it. Enough to figure out where to start if I have a problem to solve. And the problem of the day is to determine if micro Sawppy can use an ESP32 as its brain.

The reason I started looking at the ESP32 is because of its WiFi capability and its low cost. I liked the idea of web browser-based UI like what I wrote for SGVHAK rover and adapted for Sawppy. But that ran on a Raspberry Pi which, even in its lowest-cost Pi Zero form, is far more expensive than an ESP32. My experience with other ESP32 projects like Ben Hencke’s Pixelblaze and Bart Dring’s Grbl port taught me the ESP32 is quite capable of serving up HTML user interfaces. So the next thing to do is to verify an ESP32 can generate all the control signals for a Sawppy rover, which means investigating its PWM capabilities.

PWM (Pulse Width Modulation) is a tool that can be used to solve many problems in a microcontroller. For micro Sawppy I need PWM capability to control four steering micro servos and the six wheel drive motors. It doesn’t matter if they are micro servos modified for continuous rotation or a real DC motor driver like the L298N, they all need PWM signals. And what I found was that no only can ESP32 generate PWM signals, it has separate interfaces dedicated to specific problem someone might want to solve with PWM.

First up is LEDC, the Light Emitting Diode Control module. I bring this up first because our first project with any new piece of electronics is to blink a LED, and in many tutorials the next step is learning how to vary the brightness of a LED via PWM. LEDC is designed with the intent of controlling intensity of up to 16 LEDs via PWM.

Another problem commonly solved with PWM is to convert a digital signal into an analog one. This is sort of like controlling the brightness level of a LED, but some applications are sensitive to the sharp pulse transitions of a PWM signal. One example is for generating sounds, which needs a smoother output. And here the ESP32 delivers a dedicated DAC (digital-analog converter) peripheral. Anticipating that this would be used for audio, Espressif provisioned it to interface with I2S which is popular with audio applications. This may be fun to look at later, but it is not critical for driving a little rover.

And finally, I was surprised to find there is a dedicated Motor Control PWM module for generating PWM signals sent to motor driver modules like the L298N. It included many motor-specific features absent from LEDC, but they are mostly aimed at controlling brushless motors which usually have three coils each requiring independent control. ESP32’s MCPWM is set up to control two brushless motors, which means controlling six coils. But it is not required to control brushless motors, each of those coil control an be used to control a single DC brushed motor.

So the ESP32 MCPWM peripherals can control six brushed DC motors, which is a perfect fit for a six-wheel-drive little rover. I should be able to use four channels of LEDC to generate PWM to control four steering servos. This first pass over the spec sheet supports the idea of using ESP32 as little rover brain, though there is a potential problem in assigning control signals.

Seeing all the interesting projects built with an ESP32 has made me interested in learning more about the popular platform, but it wouldn’t be real until I dedicate the time and focus to build some projects of my own. My micro Sawppy project might be the motivation I needed to get down to business.

Querying in this blog’s history, I was embarrassed to realize that it’s been over two years since I first thought I would build something with an ESP32. My first exposure to the fire hose of information online was overwhelming. But I returned occasionally to pick off little bite-sized pieces to digest. Reading documentation on some specific aspect on the ESP32 at a time, usually in response to seeing someone’s project making cool use of that particular aspect. I wanted to see how it was done!

During this incremental learning, I picked up on the fact something is coordinating the works to keep all the plates up in the air. Eventually learning that the default ESP32 runtime environment includes a minimalist operating system for embedded hardware: FreeRTOS. Which was a world onto itself! There is a tutorial e-Book to help get people up to speed but again, it is a lot of information that I had to digest a little bit at a time. I’ll write more about FreeRTOS later.

And though I hadn’t reached the point of writing my own ESP32 code, I did start getting a bit of hands-on experience working with an ESP32 developer board. Which was more full featured than the minimalist mesh networking Supercon hack that was my first introduction to the hardware. Even though I was only running other people’s code (like Bart Dring’s ESP32 Grbl port) and not my own code, it was valuable familiarization of the ESP32 landscape.

All of these individual pieces built up a comfort level that was absent from my first time facing the avalanche of information available for ESP32 over two years ago. Now I can look at the page like ESP32.net and have a much better understanding why things are organized the way they were, and which pieces of information are relevant to others. This knowledge map is important as I do some basic due diligence to see if it’s feasible to build a micro Sawppy brain from an ESP32. Before I get any further on my little rovers, though, there’s a big event for a big rover.

My diversion to learn a bit of Unity 3D was a good change of pace, but now I will set that aside and return to rover work. My latest little rover Micro Sawppy Beta 3 (MSB3) had a few interesting features that I reviewed before taking this Unity break, most recently a few notes on MSB3’s living hinge differential link. MSB3 was built around the TT gearbox, which requires DC motor drivers commanded by some kind of rover brain.

I have the option of using the same brain I used for MSB1 and MSB2, which was adapted from Sawppy V1 and allowed me to control everything with servo PWM control signals. This worked for MSB1 and MSB2 because they were all micro servos. Four in their original form for steering, and six modified to continuous rotation to drive the wheels. But now that I’ve converted rover locomotion to DC gear motors, I’ll have to switch to something else.

My current generation of rover software was originally written for SGVHAK rover, which had DC motors in its wheels and used RoboClaw motor controllers. Those are nice, but far too expensive for my micro Sawppy price target. Or I could continue controlling via PWM by using forward/reverse brushed DC motor controllers(*) from the world of remote control hobbies. These are far less expensive than RoboClaw controllers but also less capable. Unfortunately they are still too expensive to meet my price target. Motivation to find a cheap commodity was why I investigated commodity L298N driver boards earlier.

But I’ve always known I couldn’t keep using a Raspberry Pi. In order to meet my price target, I have to swap it out for something more affordable. For MSB1 I chose to use the Pi as a known quantity, because the rest of the rover was all new and I wanted to reduce the number of unknowns for the first prototype. After several revisions I’m at MSB3 and I’ve decided it’s fine if a baseline micro Sawppy didn’t have the computing power of a Raspberry Pi as long as there are provisions for people to upgrade if they wish. So any microcontroller capable of generating the required PWM control signals (for servos and for L298N motor drivers) would suffice. The classic Arduino is always the first candidate I consider for a project, but ATmega328P based Arduinos only have 6 PWM channels. That’s not enough here so I have to move upscale.

Classic ATmega328P-based Arduino are also missing another very important feature: WiFi. SGVHAK rover’s Raspberry Pi based brain served up a web browser-based rover control interface. Controlling Sawppy from my touchscreen phone was very useful. Not just because of convenience but also because I didn’t need to worry about building a separate device to act as handheld controller. Which, in a bit of cheat, also meant I did not counted the cost of controller phone in micro Sawppy budget. I justified this by saying many people today have old web-capable touchscreen phone or two sitting around collecting dust. Maybe a stretch, but I’m going with it!

If I want something more powerful than a classic ATmega328P-based Arduino, but more affordable than a Raspberry Pi, and can handle web-based network traffic over WiFi, the top candidate is pretty obvious: ESP32, we meet again.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.