Red current and serial

Over the last few weeks, we've received a lot of "passionate" messages (and by "a lot" we actually mean a grand total of 2) from our readership about one specific animal welfare concern of theirs. And it all stemmed from this one careless Tweet we posted several months ago during the feverish height of summer.

Typical wildlife of the West Country. Discovered in kitchen this morning. Missing brains. #RaspberryPi #Robotics #Hexapod pic.twitter.com/7nvFsKJS5h
— Rosie the Red Robot (@rosie_red_robot) August 16, 2018

It has since transpired; several ~~bored~~ responsible members of our society happened to become quite agitated about the fate of this seemingly incomplete hexapod. After all, there have been no updates posted by us about this mechanical contraption ever since. Was it to become the new Rosie? Did it actually exist? If so, was it DEAD? Was it all just FAKE NEWS?

Was this the real life, or was this just fantasy?

Well, truth be told, this little everyday spider-project didn't turn out too well.

Soon after this photo was taken - and while we were too busy recklessly hacking a Gro Egg for no reason whatsoever - work on the hexapod came to an abrupt (and somewhat smouldering) halt.

You see, despite the use of Hi-TEC HS-5645MG digital servos, packing a respectable torque of 10.3-12.1 kg/cm, these servos were still unable to overcome the unapologetically relentless laws of physics. And during one violent incident involving an immovable table leg, an arachnoid dance too far and a case of gross spider-neglect (an incident which is yet to be reported to the RSPCA), this pseudo-robotic insect lost 2 of its 18 servos to a fatal case of servo-overheat-titus. Without a doubt; it's always heart-breaking when a geeky investment or two start charring in a stream of magic smoke (and it's totally your fault). But that feeling is made even worse, if you've just tweeted proudly about the victim to every netizen and their spider on the world-wide web.

In other words, you come out of the ordeal, looking like a complete...

!!! So what were the lessons learnt from this particular Shakespearean tragedy?

It's paramount to find a more sensible hobby that doesn't involve building robots, like collecting stamps... or trainspotting
Don't get dangerously distracted by a parenting gadget you are trying desperately to hack. It's not worth it, or maybe it is?
Creating teddy bears that dance to 160bpm dance music is - surprisingly - a lot easier than building hexapods
...We urgently need to find a sensible way to monitor the "stress levels" of servos in hexapod legs; preferably one that doesn't rely on monitoring the gushing smoke, or smell of burning

As it happens, we have already completed write-ups for 2) "Gro Egg hacking" and 3) "Mr. Ted-E U", and we're fairly confident that we can never do 1) "sensible".

Hexapod-servo-stress-monitoring-thingummy it is, then. Oh yes, sorry, "Internet-connected"-hexapod-servo-stress-monitoring-thingummy.

And here's our preliminary thoughts on this academic field. Despite the use of "meatier" Hi-TEC digital servos, it was clear that they still could not generate sufficient torque to actuate the legs when they found themselves in certain improbable yoga positions (think: "the intoxicated tarantula"), as evidenced by 2 respectable servos meeting their early demise in a (quite literal) blaze of glory. Should we have known better? YES. As we've moaned about before, length and mass of robot limbs significantly influence the amount of torque required to move them. And when their struggle takes place over an extended duration (measured in episodes of EastEnders), the servos starts to binge on electrical current like a uni student at a bar the day they receive their cheque for the student loan. And we know how the story of anyone binging on anything ends... generally not very well for the one doing the binging.

...Which is why we've become determined to build something that allows us to monitor how much work the servos are putting in. Or if we're trying to be technically accurate - which we strive to do on the rare occasion or two - we want to measure their current draw.

You don't want to be the tool without the tooling:

There's a fair number of components being used in this post...

ACS712 is what's called a "linear current sensor", and they are very much how we intend to monitor current draw. We'll use 3 of these babies, and they'll each be cabled in series with the +V connection of the 3 servos - which currently run on 5V. We've opted for the 5A version, as we don't think each servo should be drawing more than 2.5A worst case (or so the "stall torque current" value in the datasheet tells us). Linear current sensors work by representing recorded current (in amps) as a proportional analogue output voltage (in volts). Which is why we also need a:
ADS1115 analogue to digital converter. This is a 16-bit ADC, which means it offers greater precision than what is offered by the ESP8266's built-in ADC (more on this later). This model has 4-channels, not to be confused with Channel 4, which allows us to connect all 3 ACS712s belonging to a single hexapod leg (but crucially, does not allow us to catch up on missed episodes of The IT Crowd). The ADS1115 has an I2C interface, which we'll use to connect to a...
ESP8266 (ESP-12E / NodeMCU). It's back! We're addicted to it. And it will fulfil the unenviable role of hexapod leg guardian (which surely must be a name of an obscure orc race in Warhammer). By interfacing with the ADS1115 using I2C, MicroPython running on the ESP will read voltage on each ADC channel. Rather usefully, there is a MicroPython driver already written for the ADS1115 which does the job perfectly. Finally, we'll convert the voltage readings from each ACS712 into current data (in amps), and publish them using MQTT to a broker running on a...
Raspberry Pi. Not only will the MQTT broker running on the Pi subscribe to incoming current readings, but it will present them to a browser via a web page. We will also use Socket.IO to show this data in near real-time in HTML (because refreshing the browser every second to see new data just isn't cool enough).
The browser will be launched on a PC on the same network as the Pi and ESP. Remember that the PC is also required to access the ESP8266's console using a USB to Serial TTL cable, and the Pi using SSH (Putty).
And if this isn't quite enough, we'll use a couple of resistors, transistors and LEDs to construct warning lights to indicate when "too much" current is being drawn. Now, we're just showing off.
We'll continue to use a PCA9685-based Adafruit PWM / servo controller to control our HiTEC servos. But if you've been following our blogs*, you probably guessed that already (*and thank you for sticking with us. Someday we hope to repay you, with a post about something quite useful).
Don't forget a breadboard power supply to power the entire rig - both 3.3V and 5V

Chequered history:

Building Rosie 2.0 - naturally - assumes that there is a Rosie 1.0. For that reason, casting your eyes over the organised chaos that was Rosie and Rosie Patrol is highly recommended.

And then, there's also been the following episodes of Rosie 2.0:

Bit by byte:

Get to grips with MQTT, which is a lightweight messaging protocol conceived by humans to overwhelm global Internet capacity with meaningless sensor readings (often of the temperature variety). Install both the Mosquitto MQTT broker and client on a Raspberry Pi and give them an uninspiring test drive. Subscribe to a "topic", and publish something to it.
Swiftly move the testing along to the ESP8266 device. Using umqtt, the ESP device should now be able to publish data to the Mosquitto MQTT broker running on the Raspberry Pi, over Wi-Fi. Internet of someThings - don't let us down.
It's all still a bit boring. Let's install Flask-MQTT on the Pi to display incoming MQTT data from the ESP8266 using a simple HTML page. Courtesy of Flask, we can now point a browser at the Raspberry Pi, and view the last reading published by the ESP. A little more interesting, perhaps.
You saw this coming. Wire the ESP8266, 3 × ACS712's and ADS1115 devices together, using a... a bread-roll please... breadboard. Power them appropriately using a breadboard power supply. And - oh yes - don't forget the resistors, transistors and LEDs for the glamorous, Hollywood special effects.
Install Flask-SocketIO, write some additional Python code to transport subscribed MQTT data in real-time to browsers using WebSocket. To top it all off, we'll write a friendly HTML page to continually display the stream of data. This way, we can all stare at a screen that has numbers going up and down.
Are we all set? Connect the +V power cable of each servo to both terminals of the current sensor. Move the servos around, and see the current readings fluctuate on screen.
That's it folks.

You ain't seen nothing yet:

So we appear to have talked ourselves into doing several things that we've never really discussed on our site before. Use of new sensors was always to be expected. But what's with all this new mumbo jumbo software-speak?

When transferring data between devices, we've been using HTTP-based REST APIs up until now. Which is all fine and dandy if we are only occasionally sending data over the network, or executing code remotely. MQTT - on the other hand - is a "publish/subscribe" Messaging Protocol designed for people who are hell-bent on swamping the network with arbitrary data collected from sensors. And that's us. It's designed to be extremely lightweight, and relies on a broker (server) subscribing to a "topic" that it wants to be notified about. The device (client) can then publish data to the "topic". And... oh yeah... that's about it. Here we'll be using a MQTT broker called Mosquitto, because it's named after an insect, just like our hexapod. And we'll install it on our Raspberry Pi, because lately, it is starting to feel left out.

As a result, the broker running on the Pi will be receiving "near" real-time data, in a continuous stream of published messages. Clearly, we could just save what is received in a file or database somewhere, open it up in your favourite, proprietary office spreadsheet product™, and pretend to know what we're doing with a bunch of numbers. But where is our Matrix-style command and control centre display that we can dramatically frown at? And, further still, if we present this information on a webpage using our favourite Python web application framework - Flask - do we have to nonsensically refresh the browser every time to see the latest data? They do not do that on 24.

To this end, we'll also explore the use of WebSockets. Because this way, we can continuously receive the data all the way back to our browser. Using Flask-SocketIO, eventually, this will look like this:

Amidst this excitement, we almost forgot about the hardware...

ACS712 is a "linear current sensor", and outputs a voltage which is proportional to the current is has measured going through it. We'll power the ACS using 5V, which means no current = V_dd / 2 = 2.5V or thereabouts. Any deviation from that figure means it has detected some current in either direction, and using the ACS's sensitivity value, we can work out what that represents in amps. However, for us to work programmatically in Python, we need data to be in digital.

We initially used the ESP8266's built-in ADC but we got bogged down by two issues.

First of all, it only operates in a range of 0-1V (although the latest NodeMCU ESP-12E variants appear to have a converter that accepts 0-3.3V range). This means we'd need a voltage divider circuit to re-factor our 2.5V±2.5V output to a range accepted by the built-in ADC. Resistors? And maybe even an op-amp to buffer the voltage? Nah.

Secondly, with even no voltage detected, the built-in ADC appeared to think there was (i.e. noise). And bounce around a bit. Looking online, it appears to be a common issue. And since every discrepancy results in amplified inaccuracy of measured current, well, the whole exercise becomes rather quite pointless (as if it wasn't already). No thank you.

ADS1115 on the other hand is a dedicated Analogue to Digital Converter (ADC). It is a 16-bit ADC, which means it offers greater precision than what is offered by the ESP (10 bits). It also has 4 channels - which guess what - can conveniently accommodate our 3 ACS712 sensors we need for a hexapod leg. Note that we'll also use 5V to power the ADS1115.

Was there anything else? Yep.

Connect the ADS1115 to our servos, write some Python code, and - fingers crossed - we can display self-updating current readings on a browser somewhere on the network that even Jack Bauer would be proud of (if overworked servos was a national security concern).

...Apologies if we've just wasted 10 minutes of your life. You could have just looked at this diagram.

Detail:

Before we do anything else, and since we can't quite remember the last time we updated the Raspbian OS packages harbouring in our Raspberry Pi, let's do a general update.

sudo apt update
sudo apt upgrade

As you can see, it appears to have updated a whole bunch of long neglected packages, which can only be good for system hygiene, but not so much for personal hygiene if you have just postponed your shower plans to await the completion of the updates. With this minor distraction out the way, let's proceed with swatting (not to be confused with swatting) a Mosquitto.

When we want something. We install it. As we need Mosquitto to be our MQTT broker on the Pi, guess what, we install it.

sudo apt install mosquitto mosquitto-clients python-mosquitto

The Mosquitto broker actually installs as a service in Raspbian OS, which means it runs in the background, listening in on incoming MQTT traffic, by default on port 1883. Let's ensure this is so.

sudo systemctl enable mosquitto.service

Apparently we shouldn't be trusting computers to always do what they are told by us mortals. Here's us checking if the service has in fact started.

mosquitto -v

We now wished we didn't check. It's allegedly common for Mosquitto - immediately after installation - to complain that the port it requires (1883) is already in use. Don't worry, move along, nothing to see here appears to be the general advice. The memory of a mosquito - it turns out - isn't quite like that of an elephant - it has forgotten that it is the one already using the port.

And this is about as exciting as it gets when it comes to installing the MQTT broker as we're not planning to play around with its many configuration options. Where's the encryption? Authentication? Persistence? Super-duper-never-fail-on-me resiliency? Nope. Not interested. Next!

With the broker (and client) now installed, let's try this out. We'll pretend that there is a servo out there dying to send us its earth-shattering "2 A" reading to our broker. On the Pi, we can subscribe to a topic named servoReading in one SSH session, then in another SSH session, we can publish our ever-so-slightly worrying 2 amps to this topic.

In SSH windows 1 (to subscribe):

mosquitto_sub -d -t servoReading

In SSH windows 0 (to publish a value of "2"):

mosquitto_pub -d -t servoReading -m "2"

All quite pointless, of course, since we're just exchanging MQTT payloads on the Pi itself. Nothing very Internet-ty about this IoT experiment. Result: publisher sends "2" to topic "servoReading", subscriber receives "2" on topic "servoReading". Great.

This is where it starts to get a little more interesting. We can now test the same thing from the ESP8266. Connect to the device's console, and in MicroPython, use the umqtt module to publish even more dummy data to the Mosquitto broker running on the Pi.

In reality, once we're happy that everything is working, we should probably graduate to use the "robust" version of umqtt to ensure our setup can tolerate temporary loss of network connectivity, broker being unavailable, etc... But that's for another post.

Note that our Pi has an IP address of 192.168.200.108 when we were testing this out. We need this, because MQTT is now being used across the local network, from the ESP to the Pi. The ESP needs to know where to publish its data.

ip addr show | grep wlan0

from umqtt.simple import MQTTClient
mqtt_client = MQTTClient("test_client", "192.168.200.108")
mqtt_client.connect()
mqtt_client.publish("servoReading", "2")

This is looking quite promising. Data is arriving via MQTT on the Mosquitto broker running on the Pi. The two devices have now formed an unflappable alliance, a "special relationship" if you will; to dominate the network with a swarm of frivolous sensor data. Let's quickly knock up a web page to justify all of this.

We already have Flask installed from many of our previous adventures. If we didn't, we would, erm, need to install it.

What's the special glue that makes Flask and MQTT play nicely together? You'll never guess its name. You won't. It's called Flask-MQTT. And it'll allow us have a Flask web app that can integrate with the MQTT broker.

sudo pip3 install flask-mqtt

Now using a couple of Flask-MQTT decorators, we can effectively configure Flask as a MQTT client that subscribes to and handles incoming data being published, and use that data to pass the latest reading to a Jinja2 HTML template.

Simple code like this would allow us to do just that. This iteration inelegantly uses a global variable - latest_servo_reading - to keep track of the latest servo reading, and to pass this value into our index.html Jinja2 template when render_template() is called. The template then uses this variable as {{ latest_servo_reading }}.

Now to the re-test. We're bored of repeatedly sending 2 amps to the broker. Let's go all out with this next test.

Target the web browser at the Flask web server running on the Pi. We're now using a slightly more meaningful topic of "rosie/sensor/servo/current" to acknowledge the fact that there will be more sensors in the future using MQTT in our rig.

Here's our extremely hilarious ("ha ha") test, using "1 million amps". Only proceed with the remainder of this post if you haven't been hospitalised from laughter.

1 million amps. Nope. The servo, the current sensor, and most likely the curious onlooker, probably didn't survive this event.

Back to seriousness. There's a very clear limitation in this approach (if it's not already apparent). We would have to refresh the browser to render the HTML page each time we want to see the latest reading on the screen. Which probably means we would have missed that 1 million amp event (because we were probably busy watching cat videos on YouTube instead). And it's why we'll invite the cool kid on the block - WebSocket - to the party a little later.

But hang on second. We're actually quite bored of keyboard bashing. We need a little break. Time to whip out our breadboard.

We pretty much summed it all up earlier, and there isn't much else to say about the required circuitry, other than (obviously) they have to be connected up together. Note that the ESP is a 3.3V device, so we'll be connecting it to a 3.3V rail (although latest NodeMCU variants have built-in regulators). The ACS712 and ADS1115 have been connected to a 5.0V rail to ensure we can operate them in the full 0-5V range.

Then the ESP8266 is connected to the ADS1115 using our designated I2C connections.

ESP8266 GPIO	ADS1115 input	...Used for?
GPIO 4	I2C SCL	I2C clock line
GPIO 5	I2C SDA	I2C data line

..And don't forget our showbizzy indicator LEDs via a Common Emitter, NPN transistor setup. This protects our LEDs from drawing too much current from the ESP outputs, and allows us to switch the LEDs on / off directly from the power rail.

ESP8266 GPIO	Connected to	...Used for?
GPIO 12	LED 1	Buffered using voltage amplifier
GPIO 13	LED 2	Buffered using voltage amplifier
GPIO 14	LED 3	Buffered using voltage amplifier

Clearly, the output of each ACS712 current sensor is connected to each input channel of the ADS1115.

The entire setup looks a little like this in pre-school circuitry schematics.

And here's one that is (only) a little more grown up.

That said, in reality, it all looks a bit like this.

Now that everything is (sort of) connected, it's time to upload the ADS1115 driver to the ESP using webrepl_cli.py. The address of our ESP device at time of testing was 192.168.200.107. Note that WebREPL needs to be enabled on the ESP8266 before this is possible.

python webrepl_cli.py ads1x15.py 192.168.200.107:/ads1x15.py

We're now all set to query the ADC's channels to see what voltages they think they are detecting. Thanks to the helpful developer who created this driver, it's extremely simple to do just that.

The ADS module works using I2C, so we need to instantiate an I2C object first, using our SCL / SCA pins (4 / 5), then pass the object when we instantiate an ADS1115 instance. The default address of the ADS1115 appears to be 72, although we understand this is configurable. Hexapods have 6 legs. Connecting additional ADS1115s to the ESP using different I2C addresses might be one way to scale out this setup to cover ALL servos.

import machine
from ads1x15 import ADS1115
i2c = machine.I2C(-1, machine.Pin(4), machine.Pin(5))
adc = ADS1115(i2c, 72)

Ready to read some voltages values?

There's even a method - raw_to_v() - to allow us to convert the raw binary representation that is returned by default when we perform a read(). Here's an example of us obtaining a value for channel 0. 4 appears to be the default sample rate option... and we saw no reason to change this for now.

adc.raw_to_v(adc.read(4, 0))

Cool! Voltage readings are appearing for all of us here to see. And with no current passing the ACS712, the value is pretty close to 2.5V, which is V_dd / 2, as expected. Interestingly, it's not exactly 2.5V - which must mean there is still some noise (perhaps from our shoddy wiring or because we're using "bargain bin" electronic components). We'll just note down what these "baselines" are for now, so that we can use them when we work out the current.

Since the ACS712 5A version has a "sensitivity" value of 0.185V/A, it means for every 185mV deviation from V_dd / 2, it signals a change of 1A. It demonstrates just why we need a fairly accurate ADC setup - and not to resort to using ESP's default ADC functionality - as even a small inaccuracy in the voltage measurement will result in an exaggerated inaccuracy in measured current. Remember, we're only expecting the range to be in the region of 0-2.5A for the servo.

If we, for example, use 2.49532 as the baseline V_dd value:

V_ref = 2.49532
print((adc.raw_to_v(adc.read(4, 0)) - V_dd) / 0.185, "A")

There it is. Current in amps (and it is fairly close to 0A when no current is passing). And all we need to do now is repeat this with the other 2 servos, at an appropriate frequency, and publish these readings back to the MQTT broker. We'll use 3 topics, to represent each one of our servos, which the broker can actually subscribe to using a wildcard.

rosie/sensor/servo/+/current

Where each servo will use:

rosie/sensor/servo/0/current
rosie/sensor/servo/1/current
rosie/sensor/servo/2/current

Now, remember the extremely rubbish HTML webpage we created earlier to display the readings? We're going to Jack Bauer it. We'll rely on the powers of SocketIO for this. Guess what we need to install to integrate Flask with SocketIO. Go on. Guess.

sudo pip3 install flask-socketio

This allows us to use some additional SocketIO decorators in our Flask app to immediately place readings that the broker receives onto a SocketIO channel. The HTML page, now running a simple SocketIO JavaScript, will continuously update that page with the 3 servo readings.

Not a lot different in our Flask code, except we're no longer using global variables to pass data to the template. The moment we receive MQTT data, we're now simply placing it on the SocketIO channel so that the browser can get hold of it.

The MicroPython code on the ESP is also quite simple. It reads our voltage, calculates a current reading, and publishes this via MQTT to the broker.

The index.html file is no longer so interesting.

...Other than it now has a reference to a bit of JavaScript that acts as the SocketIO client, and retrieves data from the server. This is then used to update the certain "div" elements in the HTML page.

We splashed a SVG background graphic of the hexapod's leg, and used crudely assembled CSS to place the cells that display the measurements where they belong (watch out when maximising / minimising the browser - this really isn't that clever). And there it is. A rather intuitive display that shows us how stressed our servos are on one of the hexapod's legs.

We can now move the leg around randomly using the Pi and Adafruit Servo / PWM Controller, and see what happens. We expect the servos to draw the most current, either when moving, or when they are "stuck" trying to move into an instructed position - it's time to re-create the "intoxicated tarantula" pose.

Here it is, together with a video of the leg moving wildly about. The human eye has a hard time decoding what is happening in real-time, and at the frequency at which we are publishing the readings, we might be missing some notable events anyway.

If your belief system prevents you from viewing robot limbs being experimented on, while attached to surviving parts of Ikea furniture, look away now.

So there it is. Aside from it looking visually "quite" appealing, the true use for this setup is likely to be realised as and when we get around to writing more code for this. And it is why we decided to offload the current sensing to the ESP - because technically, with its own I2C interface, the Pi could have been happily taking the readings itself from the ADC. But at times, it is useful to have an independent, dedicated device which is separate from the Pi which can focus on "looking after" the servos, and perhaps even to intervene immediately when it senses danger. It can also operate at a far higher sampling rate, uninterrupted, and respond to events at higher accuracy, and quicker. In other words, while you obliviously play Minecraft on the Pi, your ESP could prevent your hexapod from combusting in a puff of smoke.

So watch the space as the tech described here gets evolved over time to play a larger part in our robot adventures. You might never know - the hexapod might make a ~~blazing~~ flash return.

Go and see the doc:

ESP8266 datasheet by Espressif can be found here:

https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf

The ACS712 linear current sensor datasheet is here:

https://www.allegromicro.com/~/media/files/datasheets/acs712-datasheet.ashx

...And the ADS1115 ADC datasheet here:

http://www.ti.com/lit/ds/symlink/ads1115.pdf

The Flask-MQTT documentation can be found here:

https://flask-mqtt.readthedocs.io/en/latest/

Similarly, the Flask-Socket IO documentation can be found here:

https://flask-socketio.readthedocs.io/en/latest/

We did stumble upon two very helpful sites that explained how Flask and WebSockets work together. They are worth the read if you are planning on working with these two technologies:

And a big shout out to this ADS1115 driver which allows us to take voltage readings using the ESP8266:

https://github.com/robert-hh/ads1x15

...Which we then publish using another ESP8266 MicroPython library:

https://github.com/micropython/micropython-lib/tree/master/umqtt.simple

And if you are really very interested, a copy of the MB v2 power supply module documentation can be found here:

https://opencircuit.shop/ProductInfo/1000154/Breadboard-Power-Supply.pdf

Rosie the Red Robot

Search This Blog