Author Archives: paynterf

ILI9341-Based Digital Clock Project

A while ago, the clock/time display on our microwave started having problems; it’s a 7-segment vacuum-flourescent display, and a couple of the segments a no longer lighting up. Instead of “End”, we now see “Erd”, and the clock is getting harder to read. The microwave itself is still running fine, but because this particular display is our primary time display in the house (aside from our phones), not having a good clock display is annoying.

I investigated getting the appropriate repair part for the display, but that module costs more than the entire microwave did originally, so that didn’t seem like a practical idea. And while I can get a cheap stick-on clock for just a few bucks, what’s the fun in that?

So, I’m in the middle of a design project to build a digital clock to replace the one on the microwave. At first I built up a clock using a Teensy 3.2 and one of my spare Nokia 5110 LCD displays, but that turned out not to be very practical, as the display is basically unreadable from more than just a few feet away, with or without backlighting.

So, I started looking around for better displays, and ran across the ILI9341 TFT display with a touch-sensitive screen. Even better, this was available with Teensy-optimized drivers, as shown here – what a deal! I started thinking that with a touch-sensitive screen, I might be able to implement some on-screen buttons for setting the time, which would be way cool!

So, I ordered two of these displays from PJRC, and started working on the design. Here’s the initial schematic

Here’s my initial breadboard setup:

Teensy 3.2 in foreground, Adafruit DS3231 RTC in background, ILI9341 TFT touch display

I originally used the Arial proportional font provided by the library, but I discovered that it produced bad artifacts after a few hours, as shown below: The only way to avoid these artifacts is to refresh the entire screen on every pass through the 1-second timing loop, which causes a very annoying ‘blink’. Eventually I figured this out, and changed to a non-proportional font, as shown below;

Non-proportional font looks worse, but doesn’t suffer from artifacts

Once I got everything working (well, except for the touch screen stuff that I plan to add later), I fabricated a nice box using Open SCAD and TinkerCad, and made a more permanent version using a half-sized ‘perma-proto’ board, as shown below

Here’s the more-or-less final schematic

7 March 2021 Update:

After a long and somewhat agonizing journey, I finally got the touch-screen stuff working, so I can now adjust the time on my digital clock using on-screen touch-sensitive controls. Here’s the updated schematic:

The only real difference between this one and the previous schematic is the T_IRQ line is no longer connected; the Teensy-optimized XPT2046_Touchscreen.h/cpp library doesn’t use it.

Here’s a short video showing how the touch-screen enabled time/date adjustment feature works:

Although I hope to clean up this code considerably in the future, I include it here in it’s entirety in it’s current state

10 March 2021 Update:

After getting all of the above to work, I decided to re-tackle the proportional fonts issue. In my first attempt, I had used the ‘ILI9341_t3’ version of the ILI9341 Teensy library, and there is a newer ‘ILI9341_t3n‘ version out now. So, I modified one of the example programs (unfortunately still written for the old library) to be compatible and got proportional fonts (well, just the Arial one) working on the display.

After several hours of running this example with no apparent artifacts or problems, I decided to update my complete clock program to use the Arial font. After making the modifications and running it overnight, the time & date displays were still rock-solid the next day, as shown in the following photo – YAY!!

So now all that is left to do is to upload the new Arial-based code (with the time background color switched back to ‘black’) to my ‘working’ clock module, sit back and enjoy the proportional font display.

14 July 2021 Update:

I noticed that my clock had some ‘issues’ with time/date adjustments, so I ‘put it back in the shop’ for some additional TLC. While I was at it, I noticed that the system schematic didn’t include the DS3231 (hard to have a clock without a RTC!), so I updated it as well. Here’s the updated schematic.

The updates made were to make the time/date adjustments more robust. The updated code is included in its entirety below. First the main program:

And then the ‘CustomBox’ class file (no .cpp file – everything is in the .h file)

Stay tuned,

Frank

Wall Tracking Trials Using Office ‘Sandbox’ Part II

Posted 24 January 2021,

Back in November of 2020, I posted about some wall-tracking exercises using my Office ‘sandbox’. Since then I have done some work on the charging station to make it more robust, and on Wall-E2’s ability to home in on and connect to the charging station. The following short video shows Wall-E2 making a complete circuit of the sandbox, ending with a homing run and connection to the charging station.

Wall-E2 makes a complete circuit of the ‘sandbox’, ending up connected to the charging station.

I plan to do quite a bit more work on the charging station homing algorithm, in particular how Wall-E2 reacts when it gets stuck trying to connect (which happens with somewhat disconcerting regularity).

Stay Tuned!

Frank

Wall-E2 Charging Station Update

Posted 17 January 2021,

While doing some ‘local sandbox’ testing with Wall-E2, I noticed that the charging station transmitter was occasionally going offline, even though I hadn’t done anything. After a while I was able to confirm that it simply shut down at some point, for some unknown reason.

After troubleshooting the problem for a bit, I came to realize that the shutdowns were being caused by the NTE960 5V LDO regulator going into over-temp shutdown. Here’s the circuit diagram for the charging station, with the NTE960 highlighted:

After puzzling over this for a bit, I realized why the regulator was going into thermal shutdown. I had stupidly routed the IR LED current through the regulator, so the regulator instead of supplying just the current to the Teensy processor, also had to handle the approximately 1A pulsed IR LED current — oops!

In my defense, this wasn’t actually as stupid as it looks now; the original system design used a 5V power supply to both charge the robot’s battery pack and run the Teensy, so there was no need for a regulator in the system. Later on, the system design changed to use the TP5100 charger, so now the charging station had to supply 12V to the TP5100 and 5V to the Teensy. Adding the 12V supply and the regulator was a non-trivial change to the existing charging station layout, and it just turned out to be MUCH easier to simply place the regulator in-line with the existing +5V power connection, which incidentally also powered the IR LED stack. This worked fine, until I started doing longer runs in my sandbox, giving the regulator more time to heat up and go into thermal overload – oops again.

So, what to do? Well, the obvious answer was to power the IR LED stack directly from 12V. This wouldn’t change the power budget for the 12V supply at all, but would dramatically reduce the power handling requirement for the regulator. However, the current 5Ω 5W current limiting resistor would have to be changed to a 10Ω 10W resistor as it would now be dropping 10V instead of 5V, at the same current. In addition, the current setup had the voltage regulator on a separate terminal strip on one side of the charging station and the IR LED modulation circuit on the other, as shown below.

Teensy 3.2 and IR LED modulation circuitry on left, 12-to-5V regulator on the right

Rather than split the two again, I decided to see if I could put all the circuitry on the left side, next to the Teensy. To do this, I started with two Bakelite terminal strips. In case you aren’t more than about 50 years old, you probably have never seen real Bakelite terminal strips, but they are perfect for this sort of thing. I got mine from a company that specializes in antique electronic items. Here’s a photo of the two-strip layout I devised to accommodate both the regulator and the IR LED modulation circuitry.

Two terminal strips ganged together to accommodate the regulator and the modulation circuitry

First I revised the circuit to bypass the 5V regulator for everything but the Teensy processor, and changed the current limiting resister from 5Ω to 10Ω. When I tested this, everything worked OK, except when I disconnected the modulation signal output from the Teensy to the modulation circuit. To my horror, the IR LED stayed ON! The input to the base of the 2N3904 was pulled low by the 10K pulldown resistor, turning it OFF, which turned the IRF520 MOSFET ON – oops! This was a problem with the original circuit – I had just never noticed it before. This is not a particularly disastrous situation, as the 12V power supply can handle the current, as can the MOSFET and the IR LED’s. However, it just isn’t very good engineering, so I decided to change the 10K resistor to be a pullup rather than a pulldown. As it turns out, this works fine, except now I couldn’t turn the IR LEDs on at all! Some more head-scratching and I figured out that in the pullup configuration, I had formed a voltage divider with the 1K current limiting resistor from the Teensy, and now the LOW signal from the Teensy was being converted to a (mostly) HIGH signal by the voltage divider. Changing the 10K to 100K solved this problem, and now the IR LEDs stay OFF when the modulation is disconnected, and operates properly when the modulation signal is present – YAY! One last ‘gotcha’; when operating from my lab power supply, the Teensy had a tendency to reset when the circuit first went to full load. I cured this with the addition of a 680 uF cap on the +5V line (actually I found that 10 uF would do, but I had more of the 680’s floating around, so…

Here are some photos showing the modified regulation/modulation control circuit

And a scope photo showing the input modulation (yellow) and the IR LED cathode voltage (green), along with the power supply voltage, current, and power values

Input modulation (yellow), IR LED cathode voltage (green), and Power supply output voltage, current and power

Hopefully this will completely solve the intermittent shutdown problem I was seeing in my sandbox trials – we’ll see!

20 January 2021 Update:

After getting everything running, I set up an experiment with a spare IR sensor mounted about 20cm away from the IR flashlight emitter. As shown below, the scope trace in the background is from the IR transistor on the left, in response to the 520Hz square wave transmitted over the IR path from the charging station. Once I got it set up, I let it run most of the afternoon and overnight. The next morning after almost 24 hours, the setup was chugging along beautifully – YAY!

Scope trace shows IR signal received by IR transistor on left. IR Flashlight and charging station electronics shown on right

28 December 2021 Update:

In the process of bringing up my new Wall-E3 robot, I was testing the IR homing module, and discovered that it wasn’t acting correctly – the values being read from the IR homing module were basically zero, even with the charging station IR transmitter less than one meter away. Troubleshooting, I found that the IR transmitter wasn’t transmitting correctly, which I finally tracked down to a (probably) misplaced connection to the Teensy 3.2 waveform generator. However, in the process of doing that, I also discovered that the driving waveform to the IR emitter had a big spike on one transition, which if not really a system problem, sure looked unprofessional.

So, I started looking at the IR transmit module schematic, and decided it could use some TLC. One problem that leapt out at me was the 01/17/21 mod to force the IR transmitter OFF if the connection to the Teensy was lost. This mod involves a 100K resistor pullup to +12V, which, if the 2N3904 transistor base failed ‘OPEN’ would mean putting +12V into the Teensy – probably not a good thing! So, I changed the circuit to route the 100K pullup to +5V instead of +12V. This still works to force the 2N3904 output LOW, which in turn would force the IRF520 OFF. Teensy digital I/O pins are all 5V tolerant, so this is a much better deal.

Chasing around a bit regarding the big spike on the leading edge of the IR transmit pulse, I found that a 0.01 uF cap on the gate lead of the IRF520 did a nice job of killing the big spike, as shown in the photos below:

With these two modifications, the IR transmit block looks pretty solid. Here’s the updated schematic:

The way that I implemented the IR transmit hardware on two parallel terminal strips looks kind of ugly, so I decided to replace that with a perfboard setup and not think of barfing every time I look at it. Here’s the ‘before’

and here is the ‘after’

While I was in the neighborhood, I also decided to modify the IR Beacon transmit code to force all unused Teensy GPIO pins to a known HIGH or LOW state in setup(). This is something I learned about just recently in the Teensy forum, and it sounds like a good idea. I think I’ll write a ‘InitAllGPIOPins()’ function that sets ALL pins to a known state, and follow it with just the necessary changes for functionality. From now on, I plan to do this with all my Teensy projects.

Stay tuned,

Frank

MakerGear MK3-ID BuildTak FlexPlate System Installation

I’ve had my MakerGear MK3-ID for a year or so now, along with a Prusa MK3S. The Prusa MK3S with it’s removable flexible build plate is my ‘go to’ printer for almost everything that can be done with a single extruder. The flexible build plate is wonderful – it makes printing so much easier. Fortunately there is now a comparable option for the MakerGear M3-ID – BuildTak’s 8×10 FlexPlate System. I was able to find the correct size system for my M3-IE at Partsbuilt 3D and it arrived in just a few days (unfortunately with Ohio state tax applied as both the company and I are in the same state). This system makes a HUGE improvement in the ease of printing with the M3-ID, and consequently make it a much more appealing alternative to printing everything on my Prusa. Here’s a photo of the FlexPlate base on my M3-ID.

However, there were a few ‘gotcha’s’ during the installation, necessitating some modifications to the M3-ID.

  • The stock M3-ID comes with a 4mm glass build plate, mounted on top of the heating element, and held down with screw-down rotating clamps at each corner . There’s no need to keep the glass build plate with the BuildTak FlexPlate system, but the resulting 4mm gap means that the stock clamps will no longer hold the build plate down firmly (or at all, for that matter).
  • The FlexPlate system consists of a mounting plate with a number of embedded magnets that is affixed to the flat heating plate with an adhesive film, and a flexible steel build plate onto which the actual build surface (either a BuildTak or PEI sheet) is adhered. The steel build plate attaches magnetically to the mounting plate, and can be easily removed and flexed to pop the print off, a la the Prusa MKS system. However, it turns out that while the mounting plate with embedded magnets mounts quite nicely on the heated base, the 8×10″ steel build plate is just a smidge too large in both dimensions for easy mounting/dismounting. It tends to overhang in one or both dimensions, meaning that one corner rests atop its corner hold-down block, and then the plate isn’t quite flat. This problem could easily be fixed if the steel build plate was just a few millimeters smaller in both dimensions.
  • The Prusa MK3S has a simple and elegant way of achieving excellent physical registration of the flexible build plate when it is placed onto the printer. There are two small protruding posts (3 or 4mm screws, actually) at the rear of the print area, and the flexible plate is notched so that when it is placed against the screws, it lines up perfectly every time. There is no such physical registration feature on the M3-ID, so getting the plate down correctly so it isn’t overlapping one of the corner pieces is a bit of a PITA

So, I needed to make a couple of modifications to the M3-ID corner hold-down system. The idea was to make the build plate fit without binding, and to achieve better physical registration of the build plate when it is re-installed onto the M3-ID after popping off a print.

The first thing I did was simply place a couple of 3mm hex nuts under the hold-down clamp foot at each corner, filling the gap left by the 4mm glass build plate, as shown below.

2ea 3mm hex nuts under the hold-down clamp foot, replacing the thickness of the removed glass build plate

This worked – sorta – but it wasn’t very elegant and didn’t address the other issues, i.e. the flex plate interference, and the problem of physical registration. So, I started designing some alternate hold-down clamp and corner pieces to do a better job. The first effort was a modifed hold-down clamp, as shown below:

Modified hold-down clamp requires only 1ea 3mm hex nut spacer

The thing I love about 3D printing is that you can iterate through several designs rapidly and learning from each version. I usually go through half a dozen versions before getting where I want to go, but it is so cheap and fast that doing it this way is MUCH faster than trying to do a ‘moon-shot’ on-off solution (which generally doesn’t work anyway, due to some unknown unknown).

So, back to the drawing board (TinkerCad) and some more designs. I started with designs to replace the stock corner blocks, and after six revs, had the following final design

MakerGear M3-ID replacement corner blocks – V6A & B are left/right mirror images

and the final design for the hold-down clamp:

MakerGear M3-ID replacement hold-down clamps – left/right mirror images

Both the corner blocks and hold-down clamps were printed with left/right mirror images to match the mirror-image corner requirement.

After getting all the final versions printed up, I installed everything on the M3-ID, as shown below:

Here’s a short video showing me placing the flexplate onto the magnetic base, using the rear corner blocks for physical registration.

Me placing the BuildTak build plate onto the magnetic base

I’ve already made a number of prints with this system (all the corner blocks – about a dozen by the time I was through) and I have to say it’s like night and day compared to the hassle with my stock M3-ID. If you have a MakerGear M3-ID, this is a must-have!

I created a Thingiverse ‘thing’ with the final designs for the corner block and hold-down clamps.

Stay tuned,

Frank

Dewalt DWS713 Miter Saw Dust Port Vacuum Hose Adaptor

My wife got me this really cool Dewalt DWS713 miter saw for Christmas this year, and I have been having fun pimping it out a bit. In a previous post I described how I added a cut shadow line LED light and control box, and this post describes how I added a 3D-printed coupler from the saw’s sawdust exhaust port to a small vacuum I keep in the shop for small cleanup jobs.

My first attempt at a coupler was a straight piece that connected on one side to the exhaust port, and on the other side to the rigid end of the vacuum hose, as shown below:

Unfortunately, I had neglected to consider what was going to happen when I actually tried to use the saw. As soon as I released the downlock and raised the saw, the coupler snapped when the rigid part of the vacuum hose ran up against items on my bench behind the saw – oops!

So, I started over again. I found the TinkerCad ‘bent pipe’ shape generator, and made a few versions that incorporated 45-60 deg bends into the rigid portion of the vacuum hose, but all of these suffered from the same problem with physical interference and cracking when the saw was raised. After some more head-scratching, I discovered I could remove the rigid end of the vacuum hose, leaving just the flexible part. As shown below, this particular vacuum has a detachable end piece that fits inside the flexible hose

Flexible hose connector. Note circular ribs.

So, I decided that I could replace the rigid piece from the end of the vacuum hose with a short coupling piece to connect the sawdust exhaust port directly to the flexible hose. As I normally do with complex projects, I started by printing a test piece – just the portion that couples to the flexible vacuum hose, as shown below:

Short piece to test the flexible hose coupling geometry

Once I had the flexible hose coupling geometry nailed, I did the same thing with the other end, and then connected the two coupling ends with a ‘curved pipe’ shape from TinkerCad, resulting (after a number of revisions) in the piece shown below:

Version 10 – this one worked!

As can be seen in the above screenshot, the final working version was version 10. One of the more wonderful things about 3D printing is the ability to make and discard multiple revisions – all it costs is a little time and a bit of very cheap filament. No need to hyperventilate over mistakes – just throw it away and try again!

The next few photos show the finished coupler installed on the miter saw.

I had uploaded the previous straight-line coupler to Thingiverse here, and I edited it to provide the new design as well

Stay tuned!

Frank

Dewalt DWS713 Miter Saw Cut Line Shadow Mod

My wife got me a brand-new Dewalt DWS713 Miter Saw for Christmas, and boy is it nice! Sure beats the heck out of my old plastic miter box, that’s for sure. After playing with it for a while and making some gorgeous cuts, I decided I wanted to try my hand at adding a cut line shadow modification.

After doing some web research, I found this post, of a guy who added a cut line shadow system to Bosch miter saw, and this Thingiverse design for a LED mounting shroud. So, I ordered an LED lamp similar to the one used in the video, and downloaded the Thingiverse shroud design so I could print one here on my 3D printer.

The LED lamp comes with a small cylindrical control module containing an ON/OFF switch and an AC/CD converter, as shown here

ON/OFF switch and AC/DC converter are housed in the magnetic base

As described in the video showing how to mount a cut line shadow LED to a Bosch miter saw, the gooseneck part of the LED lamp wasn’t long enough to allow full travel of the blade guard. So I cut the gooseneck away from the magnetic base, and fabricated a new housing for the AC/DC converter and (because I managed to screw up the original one) a new, larger ON/OFF switch.

3D printed enclosure for ON/OFF switch and AC/DC converter.

With the added length gained by replacing the original cylindrical enclosure, I was able to mount the LED at the front end of the blade housing and still allow full travel of the retractable blade guard. However, I discovered that I needed to reduce the height of the LED lamp housing slightly, to allow more clearance for the retractable blade guard travel, as shown

Here is a photo of the LED assembly temporarily attached to the miter saw, with the retractable blade guard removed

This temporary setup produced a nice cut line shadow as shown below

The photo below shows the completed assembly, with the gooseneck attached to the blade housing via a 3D-printed gooseneck retainer clip and two 3mm machine screws (the blade housing was drilled & tapped for 3mm), and the control housing mounted to the rear of the blade housing.

The final product seems to work fairly well, as demonstrated in the following photo

Here is a photo of the 3D-printed gooseneck retainer clip

I used hot glue to temporarily attach the clip to the blade housing, and then drilled through the clip and into the housing with a 3mm tap drill. Then I removed the clip, tapped the housing for a 3mm screw, and then re-drilled the clip for a 3mm clearance hole, then re-assembled using 2ea 3mm x 6mm machine screws.

Here is a screenshot showing the rounded-corner enclosure I designed to hold the ON/OFF switch and the AC/DC converter

Because I managed to screw up the original ON/OFF switch, I used this switch I had in my parts bin, from an earlier project

All the 3-D printable parts are on Thingiverse here.

27 October 2021 Update:

While changing blades the other day, I noticed that the front LED lamp holder had come loose from the top of the blade guard – the hot glue attachment of the holder had detached from the metal. So, I printed up a new lamp holder with longer sides and this time attached it with 3mm screws to 3mm tapped holes in the blade guard, as shown in the following photo:

New front LED lamp hold, this time attached with two 3mm screws

Basketball Shot Make/Miss Recorder

Posted 27 November 2020

After my recent right shoulder surgery, I have been looking for ways to get back into BBall shooting practice. However, the combination of Covid-19 lockdowns and the oncoming winter weather has drastically reduced my options for shooting practice. Not to be dissuaded from BBall practice, I figured out a way of moving my practice area from my driveway outside the garage inside the garage. As it turns out, our earth-sheltered house boasts an attached earth-sheltered two-car garage with a 12′ interior ceiling and no vertical support beams (I insisted on this in the design, and paid the extra cost, knowing from prior experience that interior support columns in a two-car garage was a bad thing.

Still not quite perfect, as even a 12′ ceiling isn’t quite enough room for a 10′ high BBall rim and enough headroom for practical shooting practice. So, I decided to mount my new practice rim at 9′ vs 10′, leaving 3′ of headroom. Obviously this isn’t ideal, but I figured a lot of practice on a 9′ rim was much better than no practice on a 10′ rim ;-).

As I started to shoot in my new practice gym, I realized I also now needed a way to record hits and misses so I could keep a running ‘made shots’ percentage. My short-term memory degradation due to being an old fart has made it almost impossible to do this in my head, and besides, what could be better than being able to combine my love of BBall, my love of programming, and my love for hardware/software projects? That’s at least a trifecta if not a quadfecta (and that is actually a word!). So, I programmed up a Windows program in C# to display ‘Hits’, ‘Attempts’, and ‘Hit Percentage’, and used an Arduino microcontroller to interface to two push-buttons – one for a hit, and the other for a miss. The arduino talks to the Windows program via a serial port over the USB cable, and the Windows program displays everything in a readily visible way. My idea was to use foot switches for the input so it would be easy to provided the needed hit/miss inputs without having to break out of a shooting rhythm. So, I jumped up on Thingiverse and found a neat, rugged footswitch by ‘vandenmar’. I needed two switches, so I modified vandenmar’s design by adding an additional cable routing trench out to the other side of the switch (so the switch cable can be routed in from the left or right-hand side of the switch).

My very own indoor basketball court (with a few minor restrictions…)
Nice, rugged footswitch design by vandenmar on Thingiverse
The 12 mm switch used here is available from Adafruit

Here’s a photo of the Arduino switch contoller

After getting all the pieces together, this is how it looks in my garage. The red footswitch is for ‘makes’ and the blue one is for ‘misses’.

red/blue footswitches, with cable to UNO and laptop in the background

This setup worked pretty well, but it still wasn’t quite ready for prime time. The UNO & breadboard were, well, breadboards, and not very mechanically robust. I was afraid I would spend more time repairing the breadboard than I would actually shooting, so I decided I needed to move from a breadboard to a more finished project. In addition, the Windows program I was using to display stats needed some work, so both sides (Windows and Arduino) needed some TLC.

I happened to have a Sparkfun Pro Micro module laying around in my parts bin, so I decided I would change out the UNO for the much smaller Pro Micro. With only two pushbutton switches and a Red/Green LED, the Pro Micro has plenty of I/O for the project. Here’s the Pro Micro version of the hardware layout.

So then I opened up my trusty Open SCAD ’rounded box with lid’ script and printed up a translucent enclosure, shown below

Sparkfun Pro Micro translucent enclosure. Photo above shows the ‘Make’ green LED illuminated

Next I updated the Windows program to show Makes, Misses, Percentage makes, and number of shots made in a row, along with the longest run of made shots for this session, as shown below

And here is the ‘final’ setup in my garage:

The two footswitches are shown at bottom left, with the Pro Micro enclosure hanging down from the laptop.

Here’s the schematic for the Sparkfun Pro Micro setup

And here is a short video showing the system in action.

At 0:43 into the above video you can see the green ‘Make’ LED illuminate in the background when I pressed the red ‘Make’ footswitch, and at 1:25 you can see me pressing the blue ‘Miss’ footswitch.

Stay tuned!

Frank

Solving the Teensy VL53L0X Array Controller Reset Problem

Posted 16 November 2020

Back in May of this year, I converted Wall-E2, my autonomous wall-following robot, from using HC-SR04 ultrasonic ‘ping’ sensors to VL53L0X infrared time-of-flight sensors for left & right (and now rear) distance measurement and obstacle detection, as described in this and follow-on posts. Since then, I have been successfully integrating the new sensing capability into Wall-E2’s wall-tracking and obstacle avoidance algorithms, as described in this post among others.

In recent ‘sandbox’ runs, however, I started to notice that the VL53L0X controller (a Teensy 3.5) wasn’t always providing proper distance measurements. Sometimes it would return ‘-1’ for some or all seven measurements. Eventually I figured out that the problem only occurred when I restarted the main controller via the wireless serial connection; when I restarted by cycling the power, VL53L0X measurements were always proper. After looking into this a bit, I realized that the problem occurred because the VL53L0X array controller wasn’t being restarted when the main controller was, except when everything was power cycled.

So, I needed a way to ensure that the VL53L0X array controller got restarted, even with a serial-port reset of the main controller. The Teensy 3.5 actually has a RESET function exposed on a pin pad (although internal to the PCB, not on the periphery) so I added a pin to this pad, and connected it to the wire formerly used as the ‘left ping’ control line. Then I modified the setup code to pull this line LOW for a few 10’s of milliseconds and then back HIGH again, to restart the Teensy.

To test the modification, I modified the main controller code to send a HIGH to an unused digital pin as the first instruction in setup() and set that pin back LOW again as the last instruction. Immediately after setting this pin high, the RESET signal is sent to the Teensy. The Teensy program was modified to set an unused pin HIGH at the start of it’s setup() program, and LOW at the end. By monitoring these two pins with my wondrous Hanmatek DOS1102 DSO (see below) I was able to definitively confirm that the Teensy restarts every time the main controller does – yay!

Yellow trace is main controller setup() timing, blue is Teensy VL53L0X array controller setup() timing

In the above scope photo, the horizontal scale is 1 sec/div. The yellow trace shows the main controller setup() function timing, and the blue is the Teensy VL53L0X array controller setup() function timing. The Teensy gets reset about 500 mSec after the main controller setup() function starts, and it ends about 5.5 Sec later, about 500 mSec before the main controller setup() function ends. The relative timing shown above is the same whether the main controller is restarted via a power switch cycle or a serial port re-open restart.

Stay Tuned,

Frank

Wall Tracking Trials Using Office ‘Sandbox’ Part I

Posted 12 November 2020

Back in October I added a TIMER5 timer interrupt to my autonomous wall-following robot (WAll-E2) code to manage sensor updates. Since then I have made the timer interrupt the sole timing source for all sensor and tracking updates, and upped the update rate from 5Hz to 10Hz. In addition, I’ve been making some improvements to Wall-E2’s obstacle detection/response abilities, and this post describes the results of these enhancements.

Wall-E2’s job is to autonomously track walls forever. This implies the ability not only track walls, but to deal with obstacles as they occur, and recharge its batteries at one or more provided charging stations as needed. Wall-tracking per se has been the subject of several previous posts, and is now reasonably well managed using the ‘find parallel’ technique described here. This post deals with the effort to detect and respond to obstacles as they occur. Here’s a recent run in my office ‘sandbox’

In the above telemetry printout, the first obstacle encounter occurs at 7.65 sec, corresponding to about 4 sec into the video. The obstacle is recognized at 18 cm, well inside the desired offset distance of 30 cm. I believe this occurred because the robot had just started turning back toward the near wall with a target steering value of -WALL_OFFSET_TRACK_SETPOINT_LIMIT (-0.3, the maximum toward-wall steering value) which meant that the normal forward obstacle detection limit of WALL_OFFSET_TGTDIST_CM (30cm in this case) wasn’t in force and the backup limit of MIN_FRONT_OBSTACLE_DIST_CM (20cm in this case) triggered instead. This causes the following code block to execute:

As can be seen in the above code snippet, this causes the robot to make a 90º ‘spin turn’ to the right, and then restart wall tracking.

At about 12.6 sec (about 10 sec into the movie) we see it detect the upcoming wall at about 30 cm (due to a bug in the code, the printed values are incorrect). This causes the following code block to execute:

This code executes a 90º ‘step turn’ (identical to a ‘spin turn’) to the right, and drops back into wall tracking mode.

At about 16 sec into the movie and 20 sec after program start, the robot again detects an upcoming obstacle at about 30cm, and again executes a 90º ‘step turn’ to the right to follow the new wall.

About 1.5 sec later, the robot detects one of the chair legs (I think it was the one nearest the wall in the movie) and tries to get away using another 90º ‘spin turn’, but then exhibits some abnormal behavior. When it attempts to find the parallel orientation to the new (non-existent) wall, it exits RotateToParallelOrientation(Left) with SteeringVal = -79.86, a very strange result. I believe this is because Wall-E2 detected the ‘stuck’ condition while it was attempting to complete the parallel orientation procedure, in this ‘while’ loop

So, it exited abnormally, thus the odd SteeringVal number, and then re-detected it in the main tracking loop because the front distance history array isn’t re-initialized after the first detection. This, apparently, is a ‘feature’, not a bug – who knew! ;-).

After the second ‘stuck’ condition detection, the robot attempts to disengage using the ExecuteStuckRecoveryManeuver(), which, in this case tries to back up and then execute an ‘end-around’ maneuver to get past the chair leg. It finished the backup portion of the maneuver successfully with 23cm remaining rearward, and then executed a 90º ‘spin turn’. Then it went forward 21cm using the front distance sensor (not shown in the video), and halted when I took over manual control.

All in all, this was a very successful ‘sandbox’ run. Lots of good data with clear indications of where things are working well and where things need to be modified/fixed.

  • A bug in the telemetry display code for the ‘Wall Offset Limit’ detection printout (fixed).
  • In the situation at 7.65 sec where the obstacle detection occurred at 18cm vs 30cm, the robot should recognize that it needs to back up to the wall offset target before making the spin turn (done).
  • And, of course, porting all this new stuff to the right-side tracking sections

16 November 2020 Update:

Tonight I got the first cut done at porting the TRACKNG_LEFT algorithms over to the TRACKING_RIGHT case, and made what appears to be a successful right-side sandbox run, as shown in the following short video

And here is the telemetry from the run:

Here’s an Excel plot of the Right side center distance and L/R motor speeds vs time.

Comparing the times from the video and the telemetry, it appears the video time is about 3-3.5 sec lower than the telemetry values. In the video, Wall-E2 detects the first upcoming wall at about 9 sec, and this corresponds with the telemetry at 12.358 where the wall is detected with front distance of 19cm. The reason the wall didn’t get detected earlier is the robot was currently tracking back toward the wall with a steering value of -0.3, and this causes the wall detection value to be reduced to suppress false positives.

The robot then takes 2 sec to back up to 33 cm and turn 90 deg CCW, and then it starts tracking the right-side wall again. It detects the next wall at 17.1 sec (14 sec in video) and 30 cm (the steering value at that point was 0.10, so no reduction in upcoming obstacle detection distance). Because the detection occurred at 30 cm, the robot doesn’t need to back up; it just makes another 90 deg spin turn CCW and starts tracking the right-side wall again. The last segment clearly shows that Wall-E2 is capable of tracking to and capturing the desired offset of 30 cm.

All in all, a very successful right-side sandbox run.

Stay tuned!

Frank

Adafruit DS3231 Module vs generic ZS-042 Module

Posted 30 October 2020,

Back in May of 2018, well over 2 years ago, I posted about adding an Adafruit DS3231 RTC module to Wall-E2, my autonomous wall-following robot project. This addition went swimmingly until about 6 months later in September of 2018 when I posted to the Adafruit support forum, saying that I was having trouble with the ‘lostPower()’ function return values; it seems like it was returning FALSE (no power loss) even though I had removed the battery and turned off the power to the system. As described in the post, I eventually gave up on this in February of 2019after discovering that I was getting radically different results when I used a different Arduino Mega and two different Adafruit DS3231 modules. Eventually I wound up in the situation where both DS3231 modules appeared to work correctly no matter what I did – strange!

Fast-forward to the present. In the process of adding a rear distance sensor to Wall-E2, I once again ran across the same anomalous behavior by the Adafruit DS3231 RTC module; The ‘lostPower()’ function stubbornly refused to declare a loss of power, even with the battery removed and the main power turned off. After a lot more investigation, including a dedicated test program and some more back-and-forth on the Adafruit forum, I (and the Adafruit support guys) still was unable to resolve the issue.

In desperation, I fished a generic ‘ZS-042’ DS3231 RTC module out of my parts bin and started working with it, thinking maybe I could use it to get a clue why the Adafruit modules were failing. As it turned out, the ZS-042 module worked perfectly from the get-go with the Adafruit RTC library, and the ‘lostPower()’ function correctly returned TRUE when main power was lost with the battery removed, and FALSE when power was lost but the battery was in place.

Here are some photos of the Adafruit and ZS-042 modules:

As can be readily seen, the ZS-042 module is considerably larger, due almost entirely to the decision to use the LIR-2032 Li-ion rechargeable cell instead of the smaller non-rechargeable CR1220 type. Other differences:

  • The ZS-042 module includes a power LED. This LED illuminates when main power is available on the VCC pin, but not when the RTC module is running from the battery
  • The Adafruit module exposes the RST (reset) line. If you need this, the ZS-042 won’t work for you.
  • When used with the supplied LIR2032, the battery is recharged and/or float-charged from VCC through a 1N4148 diode. This works fine if VCC is 5V, but doesn’t work at all if VCC is 3.3V.
  • The 32KHz output is open-drain, without a pullup on both the Adafruit module, but the ZS-042 module has a pullup to VCC. What this means in practice is you can’t easily monitor this output when operating off the battery, so it is hard to tell if the RTC module is still running. My solution to that was to attach a completely separate power supply to the 32KHz output via a 10K pullup resistor. The Adafruit module needs this to see the 32KHz output for both battery power and mains power. The ZS-042 module only needs it for battery power.
Adafruit module with temporary 10K pullup resistor installed. Note clock scope trace in background
ZS-042 module with main power applied to USB connector. 32KHz output is present even without an external pullup
Same setup but with USB connector removed. Now need a 10K external pullup to an external supply to monitor 32KHz clock

So, there you have it. The Adafruit module is smaller, has an additional output (RST) and uses a smaller, non-rechargeable CR2210 button cell. However, in my testing and use over a two-year period, I came to distrust its ability to reliably detect and report on complete power loss situations that would require a forced date/time update.

The ZS-042 module is significantly larger due to its use of the rechargeable Li-ion LIR2032 button cell, and doesn’t have the RST output. It is also considerably cheaper and widely available. Lastly, it appears to more reliably report complete power loss occurrences, allowing proper date/time updates.

For my money, I have replaced the Adafruit DS3231 module in my system with the ZS-042 module. In practice, complete RTC power failure events are very rare, so in all probability there would be no appreciable difference between the two choices. However, for those applications (like mine) where you really do want to know if the RTC loses its sense of time, I don’t feel comfortable with the Adafruit module.

If anyone has a better understanding of the Adafruit module, please feel free to comment.

30 October 2020 Update

I replaced the Adafruit DS3231 RTC module on my Wall-E2 autonomous wall-following robot with the ZS-042 DS3231 RTC module. As shown in the following photos, I had to re-arrange the I2C FRAM and I2C MPU6050 IMU modules in order to make room for the significantly larger ZS-042 module.

Original layout. Adafruit RTC module on left, MPU6050 IMU in center, FRAM on right
Straight replacement not going to work – oops!
After re-arrangement

Stay tuned,

Frank