Internet of.... Brisket?

 

Here is an adaptation of the ESP32 BBQ probe, integrated with the more recent experimentation with air quality sensors for an easier to access brisket smoking logger. The main motivations are for more convenient (remote) monitoring and logging. Monitoring is important to make any needed adjustments, especially during initial setup when the temperature is not stable. Logging is important to observe the overall burn times, especially for overnight periods to see how much overall heat actually went into the meat. We're not hardcore enough to care about having a continuous 20 hour cook, and usually end up starting the fire again the next morning after the charcoal "snake" has burnt out.

Overall, the pipeline is relatively straightforward:

Starting with the thermocouple hardware, the sensor data is polled by the ESP32 and served via a HTTP server. A python script running on a computer pulls data from the server, parses the temperature value, and emits it along with a timestamp into a Google Sheet document via the Drive API. From there, the online chart can be set to the appropriate input columns, and will update automatically as more points are added.

The main drawback of this current system is that it still needs a laptop (or computer) to run on the local network to do the bridging between the ESP32 and the cloud server. From a cursory search, it should be possible to implement the Drive API's directly, so that would be a good next step.

What are we cooking with this? One of the two USDA prime briskets we picked up at Costco in Burlington last week, when the border was still open (and return trips did not require PCR testing, as it will within a matter of days):

Pictures of results to come!

ESP32-based wireless BBQ probe

At work I've been using the ESP32 lately, and its proving to be a much more capable platform compared to the cheaper (but more mature) ESP8266. The great thing about the ESP32 is that it has a dual core processor, and a really adaptable I/O matrix that allows you to route hardware ports to many different pins. The flip side is that it costs a bit more (dev boards are around $10, while the chip itself is about $5. This makes the ESP8266 about half the price). Additionally, the software support is nowhere as developed and there are many bugs and undocumented stuff throughout, so for that the ESP8266 may be a more stable platform.

Over the past weekend, I played around with adapting a teensy-based thermocouple 

Part List

- MAX6675 thermocouple driver (and k-type probe)*

- ESP32 dev board (this is the cheapest one with a lot of pins at $7USD currently. You can get a fancier one with built in OLED, or 18650 battery holder and charging circuitry for about $10. There's also one that has a standard Arduino Uno shape if thats what you're into...)

- Mobile phone power bank (I use a 5000mAh one that lasted comfortably overnight. a 10000mAh one like this one would probably power it for 2 days straight ;)

- Computer for programming, and monitoring temperature over http (via a browser)

Hardware Setup

The MAX6675 thermocouple driver uses a simple SPI connection. However, unlike many common setups, the chip doesn't take in any commands from the master so there is no MOSI line and only CS, MISO, and CLK are required. Once the chip select pin is pulled low, the resultant data gets sent out on the MISO line bit by bit for every CLK cycle. 

In this case, I used pins 18, 19, and 21 on the ESP32 for CLK, MOSI, and CS respectively.

The dev board has a micro-USB input for power (and programming), so to power it portably I simply use a power bank.

Software Setup

I'm using the Adafruit driver which can be found and downloaded automatically using the Arduino library manager. Note that like the ESP8266, you may need to add this change to explicitly implement the delay function as util/delay.h does not exist for the Arduino ESP32 library. The library allows you to hook up the MAX6675 to any pin that supports digital I/O, and using additional digital pins for the CS pin supports more than one probe driver if necessary.

To actually serve temperature values, I built upon the SimpleWifiServer example so that the user can access the value through the browser. As a lazy way to make the display update, I added a refresh tag to the served html so the browser will reload the page every 5 seconds. Hacky, but works!

The code is available here.

Test and Use

Here's a short test comparing it with a Thermopro wireless system: off by less than 2F at room temperature. Not bad!

I did a longer test while practicing the "snake" method which is a way to have a long and low temperature cooking technique for smoking on a Weber-style bowl BBQ. Here are some not-so-well-lit shots of the starting of the snake:

With a relatively short snake that spanned less than a third of the grill I managed to keep the temperature around 250~270F for about 3 hours. This bodes well as typical cooking times for pork ribs is around 3-5 hours (depend on a number of factors; here's a good recipe). And the snake could always be lengthened for really long cooks for brisket and larger roasts.

Next Steps

Here are some things I'd like to add to the system:

- a better web user interface!

- multiple probes: at least one for the grill and one for the food. almost essential to do any legitimate smoking.

- explore possibility of powering it directly off a thermoelectric module, making use of temperature difference between the BBQ enclosure and surrounding air.

*note: the MAX6675 is actually discontinued, but it is still widely available on most online retailers. Its replacement, the MAX31855, is also double the cost. What you get as extra are an extended temperature range, as well as some additional sensor info (e.g. probe short circuit detection, etc). Might play around with the newer chip at some point, but for now the 6675 will do... ;)

Raspberry Pi Robot with PiShield, Part 2

The previous post showed the basic functionality of the Raspberry Pi Robot. The Arduino-based motor driver takes in commands to drive the robot in different directions, can be controlled remotely in a serial terminal via SSH using the screen application.

This is what the system looks like:

The Raspberry Pi talks to the Arduino via USB serial. The movement commands are sent from the Pi to the Arduino, currently, 'w', 's', 'a', 'd' to toggle movement, and ' ' (space) to stop. there are also ASCII numbers 1-6 that correspond to PWM values to control the speed of the motors. While it would be possible to control the motor driver with the GPIO pins of the RPi directly, I had that other circuit all hooked up from a previous project, and all it required was a single USB cable to the Pi, so I went with that instead of rewiring everything.

This time, we want to start doing something a bit more fun. Here's a preview of the end result:

The premise of the example is quite simple: get too close to the robot, and it runs away from you!

We use Python this time to implement the sensing behaviour. The source code that implements the above is available here. I call this one the PyPiBot as it runs on Python... ;)

Basically, what it does is the following:

Initialization:

1. Open SPI device for getting sensor data from the PiShield 

2. Open serial port (for sending commands to the motor driver)

Main loop:

1. Get data from sensor port

2. If sensor value is greater than a certain threshold trigger a move forward routine:

   - send a 'w' to the robot, which puts it in forward mode

   - wait a second (sleep)

   - send a ' ' to make it stop

3. Check for ctrl+c and quit the program

What you notice about this particular script is that it is blocking, which means that while the robot is in the move forward mode and the script sleeps, you can't respond to anything else. We'll tackle that in another example in the future!

Raspberry Pi Robot with PiShield, Part 1

Using the base from Tippy, I've started building a Raspberry Pi powered, sensor enabled robot. Currently, you can SSH into it and control it via the serial port. The original Arduino-based motor driver from Tippy is still there, but in theory we could just send out PWM and control signals from the Pi directly.

Main components:

- Raspberry Pi Zero with inline 2-port USB adapter:

- - Port 1: wifi dongle

- - Port 2: Arduino USB serial

- PiShield Sensor Interface (current Kickstart project here)

- 5000 mAh OCHO mobile power bank (1A and 2.1A outputs).

- Arduino and Sparkfun motor driver. Its been a few years since I ordered that part. This one has two channels with PWM input for each channel for speed control. There are now ones that fit directly on the Raspberry Pi as well which could be more convenient to use...

- Tamiya Track and wheel set. Really handy little platform for making a basic tracked robot. One of the cheapest options out there too.

My idea is to add sensors to the PiShield, and then have it react to local environment conditions in addition to receiving wireless commands. The software I'm running on the Pi is the latest minibian, which usually boots up and gets an IP from my router in about 10~15 seconds.

Could this have been done on an Arduino or even an ESP8266 based board? Sure - but its kinda neat to be able to run linux on-board in a relatively compact package. Stay tuned for more updates!

p.s. apologies to /r/cablemanagement. This part is clearly not my strong suit... ;)

Raspberry Pi, openFrameworks, Analog to Digital stuff

Raspberry Pi, openFrameworks

I've been doing some work with the Raspberry Pi lately with openFrameworks, and it has served as a great reminder how accessible these hardware and software platforms are for building stuff.

Setting up the RPi for oF is super simple, and relatively well documented. The extra hurdle that is worth jumping over in the setup process, is cross compilation. I followed the official guide here, and found a few steps that were missing. The cool thing with oF is that its a very active community, and I was able to update the documentation, and push it to the official webpage within a matter of hours. Currently the instructions should be up to date for the active version (0.8.4).

Cross compiling on a desktop (i7-4770k) VM running Ubuntu sped up the compile time from over 1 hr for the entire library to less than 1 minute. Basic apps went from 2-3 minutes to a couple of seconds. Therefore, the amount of time it takes to set up the cross compile is more than worth it for any kind of significant dev work. Currently my setup involves SCP'ing the compiled binary to the RPi, but it would be possible to set up the shared file system to avoid this step. DistCC is also another way but is slightly more involved (IMO).

Media Performance

One of the applications I'm currently working on for the RPi, is the interactive playback of videos. Due to the well optimized GPU libraries available, the RPi has quite impressive video decoding capabilities for the amount of overall raw processing power. For oF, there is a nice wrapper of the OMXplayer on the Pi which takes full advantage of the hardware decoding capabilities. As such it is possible to easily run HD video in an interactive application in your openFrameworks app. Here's a nice page from creativecoding.net describing a few things you can do to get started with oF and Rpi

Analog to Digital on the RPi

One thing that the RPi lacks, compared to other boards like the BeagleBone Black, is built in analog to digital (A2D). The 26 GPIO pins (or 40 on the newer A+/B+ models) are digital only, so if you want to interface analog sensors, you have the following options:

- Use another microcontroller (such as the Arduino, teensy, etc) on the USB port and run an app that talks to the virtual serial-USB. This is quite common since the set up is very similar to when using such a microcontroller with a desktop/laptop environment. However, it does add a greater cost, and also on systems like the A/A+ board, you only have a single USB port that you might want to use for something else without having to add an extra hub...

- Interface an A2D on the GPIO. There are a few common methods, and each one requires some hardware that provides either: UART, I2C, SPI, or cook you own A2D solution such as described in this excellent post by Hertaville that also demonstrates how typical A2Ds work. For my initial attempt, I used the MCP3008 SPI chip, due to local retailer availability and some quick online reading. To get the pins of the RPi easily exposed on a breadboard, I used the ElecFreaks GPIO adapter kit. I'm not sure if I'm using it correctly, but there seems to be a major flaw in the design of this adapter board: the power rail pins do not line up with the rest of the header pins. Either I'm not using it the right way, or there was a bit of a design flaw here...

Anyway, here's a quick screenshot of a quick test program using using the wiringPi library:

Next steps: brushing up my PCB design to build a small breakout board for this chip, as well as looking at potential alternatives. The drawback of this SPI implementation is that without any further multiplexing, we're limited to one of two channels, which means a max of 16 input pins using 2 MCP3008's.

access granted

It's been a while since we finished this project, but I've been neglecting to update this... so here goes: (Video should be pretty self-explanatory).

The Singing Notebook

As exploratory steps in controlling articulatory speech and singing synthesis (research topic), I hacked some sensors into an old notebook that fittingly contained some notes regarding the hardware I was using.

The book contains a bend and two pressure sensors hooked up to an Arduino Pro Mini interfaced to the laptop using a BlueSmirf serial to Bluetooth interface, and runs off a 1000mAh lipo cell. In the first mapping, the one pressure sensor controlled the lung parameter of the source model driving the synthesis, and the other one the blend between the tube shape for an I and AH vowel. Then, I change the mapping using a preset (on the laptop keyboard) which changes the target vowels used for the blending. Finally, I open the book and show the bend sensor controlling the pitch.

Headtrack+Servo+Webcam = fun

For our EECE541 project, we're building a 3D webcam chat system. I've been working on the headtracking portion, and decided this would be a neat way to demonstrate the results:



Ingredients:

-Processing sketch
-Arduino Microcontroller
-Servo
-Two webcams: one for head tracking, one for the view. One is slightly hacked to fit onto the servo.

The system demonstrates three concepts:

1. Simple pixel-based 1D head tracking - take the difference between a static background and a live view, threshold it, and return the horizontal value of the top-most pixel

2. Fishtank AR/VR systems: utilizes the viewer's position to render a scene. Kinda like this.

3. Arduino/Processing: An awesome platform to work with hardware and software to prototype new ideas. Servos, webcams, image processing... all done with a couple lines of code!