So it turns out there are versions of the esp32-s2 chip that don’t have any onboard flash. It took me the bones of 2 weeks and lots of debugging to finally arrive at that little nugget of truth.
The boards that I had assembled by JLCPCB had the ESP32-S2. When I tried to flash micropython, esptool could detect the chip and communicate with the USB bootloader (stored in ROM), but when it tried to write micropython to flash it failed.
I assumed it was a hardware issue because this is a custom board, the flash has separate power pins etc and I didn’t realise that you could even get esp32 chips without embedded flash.
Long story short 2 weeks after getting the boards and trying to figure this out I was reading through the datasheet, saw the table listing the chip variants, and had a forehead-slapping moment.
After that, it was just a case of ordering the right part (ESP32-S2FN4R2) on digikey and reflowing it on. Micropython flashed on straight away without issue.
Here is what has been tested:
- USB works! Was able to use the USB dfu bootloader to flash the esp32-s2 chip with micropython
- Wifi works, was able to connect to my home network
- Both H-bridge driver chips work for driving the motors
- The user LED works
- The lipo battery charging circuit works, the LiPo gets charged when the USB-C is plugged in
PCB files, test firmware and step files all on the github repo:
So what now?
So I’m at a bit of a crossroads with this project. The main reason I made this was I wanted to make a custom ESP32 board with USB and Wifi just to check that I could get it all to work correctly.
Being able to plop down a 2.4Ghz SMD antenna next to the esp32-s2 and connect to wifi with micropython is a really interesting recipe and I’m happy that now that I’ve done it once, I can re-use this circuit again elsewhere.
For the short term here is what I’m thinking for improvements:
- Replace the N20 motors with a lower ratio gearbox version to increase robot max speed
- Update the wheel design so the rubber bands are more securely held in place
- Buy in the JST-PH crimps and do a proper job of connecting the motors to the connectors instead of the current solder bodge job
Longer term goals
In my head, this robot was the starting point of a game. The first part of this game would be to add a camera to one of the robots:
The robot with the camera attached would be controlled by a human.
The human controlled robot enters a 1m x 1m x 0.5m box with multiple levels like this:
At the end of each level, there is an elevator to go up one level. The elevator is activated by driving onto it.
Along the way, the human-controlled robot will have to navigate a series of challenges. The elevator for each level will not work until the challenge for that level has been completed.
Some ideas for level challenges:
- The walls of the level have several phototransistors on them with an LED beside them. At the start of the level, all LEDs are red. The human-controlled robot has a small laser pointer on it. The human must line up their shot and “fire” the laser at each phototransistor to turn them all on. Once all LEDs are green, the elevator will be enabled.
- Level with autonomous robots. The robots are driving around randomly, just avoiding obstacles. On the ground there are pressure sensors with LEDs beside them. The pressure sensors are able to detect when a robot is on top of it. The human has switches that can stop each robot (robots are colour coded to switches). Once a robot drives on top of a weight sensor, the human has to flip thee switch to stop that robot while it is on the weight sensor. Once this is done the LED turns green for that weight sensor. Once all weight sensors have been activated, the elevator will activate.
- Variant on the above idea. Same thing with autonomous robots and weight sensors but the human has switches for each robot. These switches enable to human to take control of a given robot. So the human would need to line up their camera so the robot was in sight, flip the switch, then drive it onto the weight pad and leave it there. Then repeat this for multiple robots to activate the elevator.
- Another Variant on the above idea again. Same think but each autonomous robot has an IR sensor. The human has to “zap” each robot with the laser to get it to stop on the various weight sensors. Makes use of the laser again so that is a benefit
- Boss Level – one larger autonomous robot. This robot will be 2-3 times the size of the pretty small robots. It roams the level at random, searching for any object using its ultrasonic sensor. Once it detects something, it will charge at it. It will charge until it hits a wall. Once it hits the wall it pauses there for 5 seconds without moving. It then resumes its hunt. During that 5 second window, the human-controlled robot has a window in which to pivot and fire the laser at the IR sensor located at the back side of the boss robot. One hit is not enough to win though. Each laser hit will detract health points from the boss robot so this procedure must be repeated several times. Once the boss robot is defeated, the final elevator is enabled and the robot can drive onto the roof of the arena.
So that is the general idea right now. Feels like there is a huge amount of room for coming up with new ideas here. I’ve ordered the FPV camera and am planning on getting a basic test version of a single level working.