The "Secret Santa" Makes a Delivery!

Christmas seems like so long ago, but with a mixture of component shortages and logistics delays, my Secret Santa items only finally arrived this week while I was away interstate! At first, I thought Christmas may have been cancelled, but thanks to danzima for sorting out the logistics and finding it "hiding" inside the mail room after all this time. For this present, I have to thank dubbie for suggesting it in their Secret Santa entry back on 26th November 2021.

The package apparently had to be ordered through their export website meaning that it made its way from UK to USA. Later on, it was then shipped from USA to Australia where I reside - this package has travelled further than I have! The cardboard box was torn on most corners as if someone had wanted to peer inside and figure out what is inside.

Thankfully, it was well packed in bubble wrap, so it managed to make its way safely. The bubble wrap is not the sort that pops satisfyingly, so a few marks off there. (Just kidding!)

The first item was packed inside an anti-static bag. What is it I wonder ...

They're STMicroelectronics VL53L5CX FlightSense evaluation boards, two of them in a pack. These go under the part number of VL53L5CX-SATEL, featuring an 8x8 sensor with a 61 degree Field of View and a 4m maximum range. I've actually been familiar with the VL53L1X and have a few breakouts already - these sensors are pretty awesome as they basically give you a milimeter-resolution range from the front face of the unit (with a small amount of error) without being bulky or requiring all that much in terms of power. They're enabled by using an IR VCSEL and an array of SPADs along with an internal microcontroller running code that does all the heavy lifting. I never knew ST made their own evaluation breakouts - interestingly, their insert does have an error ... vailable rather than available.

The fact we get two breakouts is a nice change from the norm. These look fairly well built although flux residue is apparent. The design of the board has mouse-bite style separation to allow for the full headers and regulator to be broken away leaving a much smaller evaluation board with pads for direct wire connection, which is a nice touch. Why they opted to use SMD resistors to bridge the areas between holes rather than use traces is a bit of a mystery - perhaps they weren't confident the PCB manufacturer would be able to align the trace well-enough between the holes so mounting resistors was the way around it? They wouldn't be strong enough to reassemble the board once broken - that's for sure!

The documentation, however, is very sparse and confusion existed as to whether the PWREN pin is negated or not. In the end, by trial and error, it seems to NOT be, but the part numbers of the regulator used on board is not given (EDIT: As pointed out, it is available elsewhere, just not in the datasheet). The evaluation board is pretty strict on having VDDIO of between 1.8V and 3.3V - there is no level translation on-board whereas other breakouts may have this functionality as well.

To get it going, I decided to use an Adafruit Feather HUZZAH ESP8266-based board that element14 previously sent me, a white USB to microUSB cable from a Maxim Integrated MEMS RTC I previously reviewed, a set of nine Dupont wires and an allocation of pins that hopefully didn't conflict with anything on the board. I chose this board out of convenience, but also because it has a 3.3V I/O which suits the time-of-flight sensor. Code-wise, I had to rely on the efforts of Sparkfun which have a library for this particular chip on their own breakout. It wasn't as simple as building the example and running it - ESP8266 chips are particularly finicky so it wouldn't be a smooth ride.

The first issue is merely the "other" pins which are handled by Sparkfun's breakout but not this one. I ensured that the LPn line is held high, PWREN is also held high to enable the power supply and then toggled the I2C_RST line high then back low before starting. That solved the first issue of not being able to detect the board at all. The next issue was the presence of a software and hardware watchdog timer on the ESP8266 which causes it to reboot as the V53L5CX does not have onboard firmware, instead needing the 90kB or so firmware to be sent via I2C which takes up to 10 seconds! To solve this, I disabled the software watchdog and ensured I2C bus ran at 400kHz - I even tried higher rates of 1MHz with no trouble but I couldn't be sure if the ESP8266 was actually outputting that rate. The watchdog needed to be re-enabled and delays replaced with additional yields, to ensure the watchdog remains fed.

The modified code is as follows:

/*
  Read an 8x8 array of distances from the VL53L5CX
  By: Nathan Seidle
  SparkFun Electronics
  Date: October 26, 2021
  License: MIT. See license file for more information but you can
  basically do whatever you want with this code.

  This example shows how to read all 64 distance readings at once.

  MODIFIED by GOUGH LUI (goughlui.com) for ESP8266 due to WDT Resets,
  for use with ST V53L5CX-SATEL on Adafruit Feather Huzzah ESP8266.

  Board   ESP8266
  AVDD -> USB
  IOVDD -> 3V3
  GND -> GND
  SDA -> 4
  SCL -> 5
  LPn -> 12
  PWREN -> 13
  I2CRST -> 15
  INT -> 16
*/

#include <Wire.h>
#include <SparkFun_VL53L5CX_Library.h> //http://librarymanager/All#SparkFun_VL53L5CX

SparkFun_VL53L5CX myImager;
VL53L5CX_ResultsData measurementData; // Result data class structure, 1356 byes of RAM
int imageResolution = 0; //Used to pretty print output
int imageWidth = 0; //Used to pretty print output

void setup() {
  ESP.wdtDisable();
  pinMode(12,OUTPUT); // LPn
  pinMode(13,OUTPUT); // PWREN
  pinMode(15,OUTPUT); // I2CRST
  pinMode(16,INPUT);  // INT
  digitalWrite(12,HIGH);
  digitalWrite(13,HIGH);
  digitalWrite(15,HIGH);
  delay(100);
  digitalWrite(15,LOW); // Reset I2C
  Serial.begin(115200);
  delay(1000);

  Serial.println(""); // Extra blank line to clear garbage
  Serial.println("SparkFun VL53L5CX Imager Example");
  
  Wire.begin(); //This resets to 100kHz I2C
  Wire.setClock(400000); // 400kHz
  
  Serial.println("Initializing sensor board. This can take up to 10s. Please wait.");
  yield();
  if (myImager.begin() == false) {
    Serial.println(F("Sensor not found - check your wiring. Freezing"));
    while (1) ;
  }
  yield();
  myImager.setResolution(8*8); //Enable all 64 pads
  
  imageResolution = myImager.getResolution(); //Query sensor for current resolution - either 4x4 or 8x8
  imageWidth = sqrt(imageResolution); //Calculate printing width

  myImager.startRanging();
  ESP.wdtEnable(5000);
}

void loop() { //Poll sensor for new data
  if (myImager.isDataReady() == true) {
    if (myImager.getRangingData(&measurementData)) { //Read distance data into array
      //The ST library returns the data transposed from zone mapping shown in datasheet
      //Pretty-print data with increasing y, decreasing x to reflect reality
      for (int y = 0 ; y <= imageWidth * (imageWidth - 1) ; y += imageWidth) {
        for (int x = imageWidth - 1 ; x >= 0 ; x--) {
          Serial.print("\t");
          Serial.print(measurementData.distance_mm[x + y]);
        }
        Serial.println();
      }
      Serial.println();
    }
  }
  yield();
}

Pointed at the ceiling, the readings are relatively consistent, which is good to see!

The second part of the gift was the big and heavy part -

It was a DFRobot Mobile Platform! I've never had any robots in my house, so this would be a welcome addition. Sounds like a nice thing to tinker with.

This one seems to be the Pirate 4WD Mobile Platform, without Romeo ... which means no controller. I suppose for the price, it's what we expect, but without a controller, I'll have to either order some parts or build my own to make it move. This one seems to have been made right at the tail end of 2019 ... or is about as old as COVID-19 is. A sobering thought.

Flipping the lid open, we are greeted by four wheels with soft hollow tires.

The full complement of parts is pretty extensive, so thankfully there is a manual that guides you through the mechanical construction (only). It's like building a kit, except that it is more mechanical than electrical, the latter of which I am used to. Working slowly, I was able to assemble the bottom section first ...

... this went relatively smoothly but the design does leave me wondering why one would want to disassemble the robot to replace the batteries. Without the electronics, the wires are just sitting around for now.

I was able to assemble the platform above, but not before noticing an error with the IR bracket holder instructions where they don't mention that nuts are required for each of the screws. I worked that one out just fine in the end. I found the threaded brass rods that go into the top plate don't seem to screw in so well - some of those threaded holes in the steel plate seem to have stripped in the process of construction which is not ideal. I suppose that's not too bad considering the price and the fact that most users will probably customise this anyway. It seems designed for their sensors and boards - but that won't be what I'll be fitting eventually. I did make a mistake though - the power switch and power jack should be at the rear and not the front ... whoops!

Usually left-over parts after construction would be a concern, but in this case, it seems to be provided for attaching the controller and sensors. The wires would be for wiring the jack and power switches which I did not solder in.

At this time, I haven't yet made the platform move under its own steam yet - given there are four motors and those in robotics know that motors are likely not to be "perfectly" in sync when operated in open loop, I wondered just what sort of controller I would eventually build to drive it. Would I need four H-bridges so each wheel can be driven independently in both directions? That might be nice but without encoders, it may not be so useful. Looking at the Romeo series of boards, they seem to have two H-bridge channels - so I presume they connect both wheels on one side in parallel to each channel? That would be okay I suppose although speed offsets could lead to continuous wear of the tyres, but given that none of the wheels articulate, such a platform is likely to "scrub" the wheels whenever attempting a turn as well. Perhaps I'm overcomplicating things for such a low-cost platform ...

Anyhow, thanks again to element14 and dubbie for suggesting this Secret Santa prize. I guess I'll have plenty of work ahead of me (when time permits) to make the rover move ...