Is your robot a jerk?

How many times have you seen a video of a robot that moves in a jerky motion? This is probably due to an on/off approach to speed control. This is an easy trap when controlling a servo. You have to move from A to B. One second you are setting it to position A and the next you set it to position B. The servo responds with a jack-rabbit start and gets to the new position as quickly as possible.

A better approach is to accelerate slowly till you reach full speed and then decelerate to stop. The need for this was first illustrated when a motor being controlled jumped and fell off my table. Since then, the speed profile has been tested by keeping the motor on its own on a flat surface. If it falls over, it has failed the test.

Serial Multi-drop on an ESP8266

My servo controller is being moved from a PIC to an ESP module. Each servo motor has its own controller connected to a bus. The bus is a TTL serial line. In order to connect multiple controllers on the same bus, the transmit line of each slave controller has to be floated. They are pulled up at the host and a slave controller enables it only when it is ready to respond to a host request. This ensures that only one slave is transmitting at any given time.

I am, for now, using the Arduino framework. This puts a couple of layers between my code and the hardware. This blog looks at how to implement a floating transmit line on an ESP. To test the prototype I have the line set to half the power supply voltage of 3.3V using a couple of resistors. This helps me check if the output is floating or not. In the trace below, you can see a floating line starting to transmit a response.

Driving a WS2812B with an ESP8266 (Arduino)

With most PIC chips disappearing from the market as part of the semiconductor shortage, I looked around for options for my smart servo controller. I finally settled on the ESP8266 module - specifically ESP-01F. One of the features I had in mind was to use a WS2812B RGB LED to indicate the various states. I already have a servo control loop that is executed once every 20ms. It made sense to squirt out the data for the RGB LED as part of this service routine.

There are many ways to drive a WS2812B from an ESP8266 in an Arduino environment. This is yet another way. This drives a single WS2812B using a bit-banging approach.

Oxeye - A daisy chain servo controller

I finally decided to try out a robot arm. I have been looking at getting one (either that or one of those biped robots) for a while. I was also looking forward to building a controller for it from scratch.

One interesting problem is how to control several servos. Most solutions end up with this octopus like controller where wires from all the servo motors snake to a single controller board. This board has multiple servo outputs. But never enough. A much better way would be to use a bus structure.

Each servo will have its own little controller. Each controller will have an input and output port. Or the other way around – it is just a bus. Each controller is connected to the next one in a daisy chain. The first one is connected to the controller and the last one has one port unused. Depending on ease of wiring, in some cases a Y cable can connect multiple controllers to a single one. This should make the wiring a lot simpler – no tangle of connections to a single controller. It also simplifies the controller - there is only one port. This is roughly how smart servos work as well.

Enphase Production/Consumption Metering

In the last blog, we looked at Panel Level Monitoring based on the thecomputerperson blog. Further down in the comments, is another useful URL.

The URL is http://[ip address]/stream/meter. Like Panel Level Monitoring, it prompts you for the user id and password. But the usual envoy/serial no. does not work this time. The user id is installer and the password is not obvious. Fortunately, thecomputerperson has a blog describing an app to derive this password. Once you enter the credentials, you get a continuous stream of data with more arriving every 1 second. Each batch of data looks like this.

data: {
  "production":{
    "ph-a":{"p":2412.766,"q":195.631,"s":2419.61,"v":243.321,"i":9.95,"pf":1.0,"f":50.12},
    "ph-b":{"p":2216.147,"q":171.409,"s":2220.896,"v":245.239,"i":9.068,"pf":1.0,"f":50.12},
    "ph-c":{"p":2176.172,"q":178.79,"s":2178.513,"v":239.326,"i":9.112,"pf":1.0,"f":50.12}
  },
  "net-consumption":{
    "ph-a":{"p":-2275.016,"q":-312.015,"s":2293.029,"v":243.378,"i":9.421,"pf":-0.99,"f":50.12},
    "ph-b":{"p":-2014.286,"q":-212.405,"s":2023.73,"v":245.4,"i":8.257,"pf":-1.0,"f":50.12},
    "ph-c":{"p":-2151.988,"q":-342.735,"s":2171.025,"v":239.412,"i":9.078,"pf":-0.99,"f":50.12}
  },
  "total-consumption":{
    "ph-a":{"p":137.75,"q":-507.647,"s":128.826,"v":243.349,"i":0.529,"pf":1.0,"f":50.12},
    "ph-b":{"p":201.861,"q":-383.814,"s":199.012,"v":245.319,"i":0.811,"pf":1.0,"f":50.12},
    "ph-c":{"p":24.184,"q":-521.524,"s":7.95,"v":239.369,"i":0.033,"pf":1.0,"f":50.12}
  }
}

Enphase Panel Level Monitoring

No sooner had the Enphase Envoy been installed, I started exploring the web server installed on it. The Enphase Envoy uses your home wireless to send its data back to the cloud. You should be able to see the device on your router and find out its IP address. Connect to it using a browser to see the web pages that it serves up.

The normal pages have some basic info but the interesting stuff has been described in thecomputerperson blog. Have a look and do go past the blog into the comments. That is where some of the most interesting information lies.

One gold nugget was the call to get panel level information. The URL is http://[ip address]/api/v1/production/inverters. If you try that on a browser, you are prompted for a user id and password. The user id is envoy and the password is the last 6 digits of the serial number for the Enphase Envoy. The response is a JSON document listing each panel and their outputs. The values are the serial number of the panel (serialNumber), the timestamp this information was last updated (lastReportDate), the device type (devType) which is always 1, the power last reported (lastReportWatts) and maximum power ever reported (maxReportWatts) - not sure how far back it goes - since last power up?

[
  {
    "serialNumber": "121XXXXXXXXX",
    "lastReportDate": 1555658860,
    "devType": 1,
    "lastReportWatts": 1,
    "maxReportWatts": 297
  },
  {
    "serialNumber": "121XXXXXXXXX",
    "lastReportDate": 1555658777,
    "devType": 1,
    "lastReportWatts": 0,
    "maxReportWatts": 297
  },
  ...
]

Going Solar - Post-installation

Part VI - Post-installation

My service provider was and is AGL. I had trouble getting them to do anything before the installation. But after, getting on to the account portal, I got a pleasant surprise. Plenty of details on my usage!