Maslow Home Maslow Community Garden Newsletter

ESP32 Ground Control and Firmware in One

In various places we have a running discussion about using an esp32 as a replacement for the Arduino. I want to consolidate and focus that work in one place.

The esp32 would give us a lot more processing power and the ability to connect the machine over bluetooth and wifi. At the same time the esp32 can be programmed by the Arduino IDE making it relatively easy to use.

The first plan of attack is to use the existing esp32 port of GRBL (https://github.com/bdring/Grbl_Esp32) and modify it for use with a closed loop control system.

I have been playing around with reading the encoder values and creating an asynchronous web server on the esp32. Here are the files I have been using.

Maslow_4_Firmware.zip (2.8 KB)

6 Likes

My plan of attack is to:

  1. Continue exploring how to use the esp32
  2. Start to explore how the esp32 grbl program works and see what we can use from it
2 Likes

On the basis that one of the goals is to incorporate all functionality (web/ground control and firmware) into the esp32, one of my concerns is the flash memory space that’s available. With the current branch of grbl_esp32, there’s very little room left in the program area and spiffs area when you retain OTA capability.

I think the OTA capability is pretty awesome and would love for it to stay, but I’m concerned that we will be limiting the functionality of ‘espcontrol’ just because we can’t fit the code into the program area. If the plan is to incorporate the esp32 directly into a custom controller board, then I think using an ESP32 with a bigger flash space is readily doable and would ease the concern over what can and cannot be incorporated. However, I believe most existing users of grbl_esp32 are using 4MB flash variants so the changes/improvements we make won’t be able to be incorporated into the main branch.

In a nut shell, I’m ok with sticking with the stock 4MB flash drive and making it work, understanding that some functionality will likely not be able to be incorporated and we’d need to find some other solution.

For example, if optical calibration is something desired (in whatever form/method it ultimately is), we could conceivably decouple it from the esp32 and make it a stand alone application that would run on an RPI, windows/mac computer, maybe phone?, and communicate with the esp32 over wifi/bluetooth or something. I don’t think eps32 can run opencv which is needed, so maybe the idea would be to use the esp32 to grab a picture, it gets sent over bluetooth or wifi to something else (i.e., pc/mac, phone? cloud???) to process and it responds back to the esp32 with location information. That actually sounds pretty cool…

Finally, another possibility is to include an additional eeprom directly on the custom controller to house ‘maslow’ specific data outside the esp32. For example, there maybe maslow-specific html/js/css code that won’t fit in the spiffs partition and we can put that data there… that would allow us to maintain compatibility with the main branch.

5 Likes

I like this idea more and more. There’s already a build process using gulp? that combines all the html/ccs/js into a single zip file so we can simply maintain a maslow-specific web interface but have our maslow-specific code incorporated into the main branch. For those that are using stock grbl_esp32, the webserver can serve whatever is in the esp32’s spiffs, but for people using maslow, the webserver can serve whatever is in the external eeprom of the custom controller. That way, we can size the eeprom to our needs and not affect stock grbl_esp32 users. The only constraint on us at that point is to make sure whatever program (c++) modifications we make, it fits in the program data area.

1 Like

I’m not too worried about trying to push our changes back up into the main esp32 repository since I doubt that we would be making many contributions which would benefit them so they probably wouldn’t be interested in taking the time to address our pull requests, and being able to remove a lot of the stepper specific code would be really great for freeing up space for our uses

That would help for certain.

1 Like

I just don’t think we’d be doing them any favors with our changes, and that would leave us a lot more room to improve on the design and add our own things (like holey calibration) which they probably wouldn’t want

1 Like

It would also be nice to leverage that existing stepper code to expand Maslow to work with Steppers which are more familiar to much of the CNC community. We can try to split stepper and servo(motor and encoder) code into seperate .h files and conditionally compile only what is needed. Perhaps one or the other could fit within the 4MiB flash, but if the user had larger flash he could use both. That would allow motors w/encoders for X,Y but one of those cheap prefab stepper Z axis.

Edit: This is a stretch goal. Just want to make it clear that no decision needs to be made on this. We can discard stepper code completely now, and if we want it back at any point, the GRBL code base will still have it for us to plug in when we need it.

Would it work to use microSD card instead of EEPROM? ESP32 has a native SD interface which is actually what is used to connect external flash. With all that SD space would we still need to compress the HTML? SD would be a convenient location to store all sorts of things. We could pop the SD card into phone, or computer, write some configuration files, perhaps with the help of a simple app. We could load up some G code on SD, then pop it back into Maslow ready to run our stock parts at any time without requiring any network connectivity.

Which AS5048A library are you using? Is it this one?

I am using this one https://github.com/Dmitry-Chernikov/AS5048A-Arduino

But I modified it to be a little easier to read. I will post the version I am using as soon as I get to a computer

1 Like

That’s an option also. I think the new controller should have an SD slot for loading gcode… however, I’m concerned about reusing it for the web interface (what if someone messes it up, or loads an old sd card in, etc.) I think if we aren’t concerned about backward compatibility and the chip will be integrated in the board, I’d say we go with one with more flash ram and not worry about it.

1 Like

Given that the price difference is trivial I think that is the way to go for sure.

Is there a surface mount version we can use which doesn’t require headers?

Here is my modified version:

AS5048A.zip (7.4 KB)

1 Like

I think you can only get the larger flash variants as a module (no dev boards) and the modules are smd

1 Like

eMMC modules have been tested to work on the ESP32 SD lines. Just in case we need non removable huge storage. Unfortunately I dont think it can be memory mapped to program space so that doesn’t solve the unavailability of large flash dev boards.

We are really early in the development process. I would not worry about it yet.

long term there are a few options

  1. make the various features compile-time options

  2. increase the hardware requiements (esp32 modules are all cheaper than the
    arduino we’ve been using)

  3. do a two stage OTA upgrade (upgrade to a tiny bootloader that then can then
    load a bigger firmware image)

but for the current level of development, just make it work, don’t worry about
the resulting image size.

David Lang

having an external SD card so that we could load/save gcode on that rather than
have it trickle in a line at a time or have to get stored in RAM would be a good
idea.

This could potentially eliminate the need for OTA upgrades (save the new
firmware file on the SD card under a specific name, the system boots, sees the
file, and upgrades itself)

look at what’s being done with the current generation of 3d printers and how
they get upgraded.

David Lang

they have other people asking for using the firmware for v-plotters, so I don’t
see any reason why they should reject our changes, as long as we make everything
compile-time options so that they can opt not to use it if they don’t want it.

David Lang

html is small and can probably fit in the flash, not the SD card, the SD card
would be more for pretty icons, and we can store a default one in flash to use
if the SD card isn’t there or has gotten messed up.

having a “don’t touch this at the risk of breaking your machine” directory on
the SD card doesn’t seem like it is going to be that risky to depend on.

and if it eliminates another chip (and the gpio pins it would take up, and board
complexity), it seems like a win.

Depending on a SD card that can get messed up hasn’t seemed to hurt the
Raspberry Pi that much :slight_smile:

David Lang

I’m itching to get some hardware.



This looks like it will work for the 4 motor maslow as well as regular maslow.
It seems to use this dev board https://www.smart-prototyping.com/NodeMCU-32S-Lua-WiFi-ESP32-module

Is there any reason that this should not be the initial development platform for "ESP32 Ground Control and Firmware in One?

1 Like