ESP8266 and the balance bot
I've built a new balancing robot. Unlike the last one it actually works a bit, which is nice. I've been working on it for quite a while, and neglecting to post about it, which leaves me with the dilemma of what to write about first.
One of the most annoying things about the previous development experience was using Bluetooth. Specifically Linux Bluetooth support. The main reason for using a Bluetooth serial module was it's low cost. Now you can pick up a ESP8266 WiFi module for less than £2. Since WiFi is so much better supported than Bluetooth, it seems like a no-brainer.
There are quite a few different formats out there, and I've bought a few different ones.
At the high end are the NodeMCU boards. These include a usb serial adapter, and require the least fiddling around to get going. I recommend you get one, because what you are going to find immediately is you need to flash whatever you buy with a newer firmware. The flashing tools will just work with one of these, so you will know if the firmware is the problem.
At the cheap end are tiny boards with just enough pins to re-flash the device and communicate via a UART. These sometimes get called ESP-01.
In the middle are boards which break out enough GPIO ports to use the I2C, SPI, PWM etc. They are usually build using another surface mount module that includes an RF shield and is FCC approved.These are often called ESP-12. This is what I've used in my robot.
The ESP-01 and ESP-12 module types will require you get an FTDI module that's 3.3V capable.
I've used esptool to flash all these types. It's README perhaps does say enough about wiring, but I had to solder on some extra headers to my FTDI module to get access to RTS. Also, it generally takes several goes to flash something as big as the NodeMCU firmware.
I originally thought I would use the 'AT' firmware, and then discovered NodeMCU. It's eLua running on the esp8266. There's nothing special about the NodeMCU board: NodeMCU runs on any of the modules. I've looked at eLua before. eLua is targeted at bare metal, but here it runs embedded in the ESP8266 firmware which is based on FreeRTOS. The functionality corresponds directly to an underlying firmware function. Because Lua lacks continuations and threads, NodeMCU uses an event driven model, hence the 'Node' in the name. This makes complex programs pretty ugly, but it works fine for simple stuff.
Here's some API documentation.
I've written a few different serial bridge functions. The one I've ended up using for the balancing robot is the UDP one. The tuning server bridges between the web browser and UDP. It's a simple python twisted app. It's 1/3 the size of the Bluetooth version, which had lots of code for locating and connecting to the Bluetooth serial adapter.
I use nodemcu-uploader to upload the init.lau file that gets run each time the device starts. The downside to the serial bridge is that once you install it in init.lau with a command to choose one of the modes, you have to re-flash the device before you can do anything else with it. You could omit the start command, and have your connected device send it. I've also considered having the command run only if a GPIO pin set to pull-up mode is pulled low.
I could have done this with the AT firmware. The reason I didn't was it's reasonably complicated to parse the output of the AT firmware: it's too chatty, and doesn't have a quiet mode. I wasted quite a bit of time on this before switching to NodeMCU, although it turns out part of that was Minicom ignoring me when I turned off hardware flow control.
There's one really helpful feature of both the AT firmware and NodeMCU: when you set up your wifi network, it remembers the settings in the flash and will re-connect automatically when you turn it on again.
I'd really like a SLIP bridge firmware for the ESP8266 so I can just run lwIP in the main micro controller. Separate modules having direct access to the network would be much simpler than multiplexing everything into a single protocol. As I add a camera, and remote control features than will get more important. I wonder if that's possible. A future project I guess.
One of the most annoying things about the previous development experience was using Bluetooth. Specifically Linux Bluetooth support. The main reason for using a Bluetooth serial module was it's low cost. Now you can pick up a ESP8266 WiFi module for less than £2. Since WiFi is so much better supported than Bluetooth, it seems like a no-brainer.
There are quite a few different formats out there, and I've bought a few different ones.
At the high end are the NodeMCU boards. These include a usb serial adapter, and require the least fiddling around to get going. I recommend you get one, because what you are going to find immediately is you need to flash whatever you buy with a newer firmware. The flashing tools will just work with one of these, so you will know if the firmware is the problem.
At the cheap end are tiny boards with just enough pins to re-flash the device and communicate via a UART. These sometimes get called ESP-01.
In the middle are boards which break out enough GPIO ports to use the I2C, SPI, PWM etc. They are usually build using another surface mount module that includes an RF shield and is FCC approved.These are often called ESP-12. This is what I've used in my robot.
The ESP-01 and ESP-12 module types will require you get an FTDI module that's 3.3V capable.
I've used esptool to flash all these types. It's README perhaps does say enough about wiring, but I had to solder on some extra headers to my FTDI module to get access to RTS. Also, it generally takes several goes to flash something as big as the NodeMCU firmware.
I originally thought I would use the 'AT' firmware, and then discovered NodeMCU. It's eLua running on the esp8266. There's nothing special about the NodeMCU board: NodeMCU runs on any of the modules. I've looked at eLua before. eLua is targeted at bare metal, but here it runs embedded in the ESP8266 firmware which is based on FreeRTOS. The functionality corresponds directly to an underlying firmware function. Because Lua lacks continuations and threads, NodeMCU uses an event driven model, hence the 'Node' in the name. This makes complex programs pretty ugly, but it works fine for simple stuff.
Here's some API documentation.
I've written a few different serial bridge functions. The one I've ended up using for the balancing robot is the UDP one. The tuning server bridges between the web browser and UDP. It's a simple python twisted app. It's 1/3 the size of the Bluetooth version, which had lots of code for locating and connecting to the Bluetooth serial adapter.
I use nodemcu-uploader to upload the init.lau file that gets run each time the device starts. The downside to the serial bridge is that once you install it in init.lau with a command to choose one of the modes, you have to re-flash the device before you can do anything else with it. You could omit the start command, and have your connected device send it. I've also considered having the command run only if a GPIO pin set to pull-up mode is pulled low.
I could have done this with the AT firmware. The reason I didn't was it's reasonably complicated to parse the output of the AT firmware: it's too chatty, and doesn't have a quiet mode. I wasted quite a bit of time on this before switching to NodeMCU, although it turns out part of that was Minicom ignoring me when I turned off hardware flow control.
There's one really helpful feature of both the AT firmware and NodeMCU: when you set up your wifi network, it remembers the settings in the flash and will re-connect automatically when you turn it on again.
I'd really like a SLIP bridge firmware for the ESP8266 so I can just run lwIP in the main micro controller. Separate modules having direct access to the network would be much simpler than multiplexing everything into a single protocol. As I add a camera, and remote control features than will get more important. I wonder if that's possible. A future project I guess.
