Yearly Archives: 2018

Digital Tension Scale, Part IV

Posted 25 December 2018

In my copious free time I have been refining the design for a low power battery operated tensionometer.   In my last post on the subject, I had described the components I had planned to use, and in the ensuing weeks I have been working on implementing this design.   There are several challenges in this project:

Bluetooth Link:

There are a huge number of Bluetooth products out there in the Maker-verse, with varying degrees of Arduino support, and widely varying performance characteristics.   To add to the confusion, there is ‘regular’ Bluetooth and the more recent  ‘BLE’ (Bluetooth Low Energy) which are completely incompatible with each other.   As I now understand it, BLE is synonymous with Bluetooth 4.0+ (the iPhone 4S was the first smartphone to implement the new standard).   However, the most common product in use in the Arduino world seems to be the venerable HC-05 ‘regular’ Bluetooth module, available from your local grocery store (well, not quite, but from almost everywhere else!) for not much more than a few pennies

I had no previous experience with BT modules, so this part of the project took some time, and was the last major part to be accomplished.   After receiving my HC-05 modules from China, I used this tutorial to get started.   The real challenge for this part of the project wasn’t getting the HC-05 hooked up to the microcontroller – it was sorting through all the layers of BT-related settings on my Win 10 laptop to pair with the HC-05 device and determine which serial port did what.

  • In Windows 10, I used the ‘Bluetooth and other devices settings’ panel (Settings -> Devices -> Bluetooth and other devices) to find and pair to the HC-05.   The device shows up as ‘HC-05’ and the default pairing password is “1234”.
  • When the HC-05 is paired it automatically sets up at least two serial ports that show up in device manager as ‘Standard Serial over Bluetooth’ ports, as shown below.   However, only one of these ports is actually usable for two-way communication, and it isn’t clear to me why, or how to tell which is which;   I had to experiment with each available ‘SSoB’ port to figure out which to use  (so far, it seems like the highest-numbered port is the proper one).
  • After the HC-05 is paired and the com ports are set up, then any serial terminal app (I used RealTerm) can be used to communicate between the PC and the microcontroller via the HC-05.
  • On the microcontroller (I used a Teensy 3.2 with multiple hardware serial ports), I wired the HC-05 to Serial1 leaving Serial (Serial0) available for normal communication between the Teensy and my Visual Studio 2017 Community Edition/Visual Micro add-on for Arduino development platform.

Physical Layout:

The original idea behind this project was to create a self-contained battery-operated digital weight scale that could display weight values on a local display, but could also stream the data live to a remote recording station like a laptop or smartphone. The ‘self-contained’ part requires that all the electronics be mounted on the S-shaped load cell assembly itself, and to that end I designed a housing that connects to the two bolts that hold the arms of the load cell.   The idea is that all the electronics save the LCD display and the battery will be mounted to the underside of the box lid so that servicing would be easier.   Also, by mounting everything to the lid, I can make cutouts for the charger and Teensy USB connectors for easy charging and reprogramming.   After several iterations in TinkerCad, I came up with the following design

Looking up at the underside of the box lid, showing all modules except the battery and the LCD display

Showing the top of the lid with the mounting bracket for the load cell

Isometric view with transparent box walls. The LCD display module is under the battery.   Note the cutouts for the charging and programming USB-C connections

Module Integration:

I had previously tested each module individually, but hadn’t had all of them working at the same time.   I had tested the HC-05 with an Arduino Mega, and I had tested the load cell with both a Sparkfun Pro Micro and with a Teensy 3.2, and I had tested the Nokia LCD display with a Teensy 3.2, but I hadn’t put everything together.   So I wired everything up on my half-size ASP plugboard and got it all working together with a simple program (included below) that exercised the LCD Display, the load cell, the BT module, and the battery charger, as shown in the following photos

RealTerm Serial Terminal Program showing load cell readouts collected wirelessly via the Bluetooth HC-05 modules

HC-05 Bluetooth, HX-711 Load Cell Amp, Sparkfun Charger, and Teensy Microcontroller modules integrated together. Note disconnected USB cable showing that the circuit is running on battery power. The scale is currently measuring 1.8 liters of water in the suspended plastic bag (note the ‘1.8 Kg’ reading on the LCD display)

 

Software:

The software used for the above integration tests is a reasonably complete sketch for day-to-day use of the digital weight scale.   It displays the measured weight on the LCD display, and also sends it to the USB serial port for display on a directly connected PC, and to the HC-05 Bluetooth module for display/capture via a BT-connected laptop or smartphone.   This program is shown below:

However, this program depends on the proper calibration of the load cell, which I have been doing with a separate sketch (also included below):

What I need to do now is to combine these two programs into a single sketch with ‘operating’ and ‘calibration’ modes.   My calibration program already does this to some degree, as it waits 5 seconds on startup for the operator to send the ‘y’ key via the direct-connect serial port. If the ‘y’ character is detected within this window, then the program starts the calibration sequence; otherwise it starts taking measurements as normal.   This behavior needs to be expanded somewhat in that it should accept a calibration command either through the direct-connect serial port (Serial) or via the BT port (Serial1).

Low Power Operation:

I have already done some experimentation on low-power operation of the Teensy 3.2, using Colin Duffy’s fine ‘Snooze’ library, and have determined that I can easily drop the Teensy’s operating current from around 20-30 mA to about 1-2 mA by putting it to sleep during periods of load cell inactivity.   Assuming I get the full 2500 mA hours out of the battery, then I can expect something like 1000 hours or about 40 days between recharges.   However, more work needs to be done to get the low power mode fully operational.

 

Stay Tuned!

Frank

 

Digital Tension Scale, Part III

Posted 25 November, 2018

Over the Thanksgiving weekend I had a chance to do some more work on my digital tension scale project.   My wife and I drove to St. Louis to visit our kids and grand-kids, and its a 6-hour drive each way.   I make sure we have an audio book going for my wife, and as a consequence I get 6 hours of (mostly) uninterrupted geek time to work on things like this project.

As I mentioned in Part II, my goal is to construct a battery-operated tensionometer that can be mounted directly on the dual-hook S-shaped tension block, as defined by the features delineated in Part II.   After doing some more web research, I came up with the following possible components for the system:

Display:

Apparently, the Nokia 5110 84×48 pixel monochrome LCD display used in prehistoric times as the display in Nokia cellphones has found a second career as a simple, low power display for battery-operated devices like the one I envision.

 

Nokia 5110 Monochrome LCD display

Battery & Battery Charger:

The LCD display will operate quite nicely from 3.3V, so as long as I can come up with a 3.3V micro-controller (like the Teensy 3.2) and a small, capable LiPo charger, I should be in business.   For this component, I plan to use the Adafruit PowerBoost 1000C and something like the 3.7V 2500 mAh battery as shown below

Adafruit PowerBoost 1000C single-cell LiPo charger

3.7V 2500 mAh LiPo battery

 

I don’t think I’ll need the 5V boosted output from the PB1000C and the entire thing may be a bit of overkill for this project, but I had them hanging around from a previous project, so…

MicroController:

For this I plan to use one of  Paul Stoffregen’s magical Teensy 3.2’s.   Again this is probably  way overkill for the project, but…

Wireless Connection:

This component is the one for which I have the least understanding and confidence.   I currently use a Pololu Wixel for wireless serial comms and programming with my autonomous robot, but I haven’t figured out how to use it with a Teensy, and I thought maybe there were better solutions out there by now anyway.   So, after some more web searching I found that many ‘makers’ are using the HC-05/6 Bluetooth modules for this purpose.   Hopefully with this module I’ll be able to use a Bluetooth connection from the tensionometer to my laptop or even my cellphone to perform calibrations and collect real-time tension data.

Combining all these with the HX-711 load cell amplifier, I came up with the following system schematic.

 

Stay tuned!

Frank

 

Digital Tension Scale, Part II

Posted 17 November 2018

In a previous post on this subject, I described a digital tension scale arrangement using a load cell incorporated into a 2-hook tension measurement setup, interfaced to a common HX711 ADC board, and a Sparkfun Pro Micro ATMega32U4 microcontroller.

After (finally) getting the setup to work and getting some initial real-time tension measurements on our rowing machine, I decided to see if I could improve the usability of the overall system, with the goal of constructing a fully automatic battery powered tension scale, with the ability to communicate wirelessly to my PC for data acquisition and programming.

Desired Features:

  • Easy calibration:   The system should offer a calibration option when connected to a PC/Smartphone, but otherwise should use the last calibration data (stored in EEPROM) for measurements.
  • Battery operated: This implies a low-power mode to extend battery life if using primary batteries, and/or a charging arrangement if using secondary (rechargeable) cells.
  • Local display:   A low power display (LCD?) for local tension measurement display
  • Wireless capability:   A wireless connection to a PC or smartphone for real-time data acquisition.
  • Small size:   I would like to mount the entire system on the 2-hook tension measurement assembly itself.

Easy Calibration:

The calibration procedure associated with my previous post was a PITA, to say the least, so I decided to attack this problem first.   I modified the software to allow the user to skip calibration entirely or to calibrate the tensionometer automatically using any known weight.   The new software is shown below:

When run on my PC, this produced the following output

Here are a couple of photos showing the calibration process with my current setup

‘Tare Weight’ configuration, used to zero out the contribution from the bucket

Calibration configuration. Bucket now contains 1.8L water (1.8 Kg)

After calibrating, I tested the the system by measuring tension vs time with an elastic strap I am using as part of my rotator cuff surgery rehab, as shown in the following short video clip

The data from this experiment was captured on my PC and plotted in Excel, as shown below

Tension vs time for the orange elastic strap shown in the video

Then, at the request of my physical therapist, I measured the real-time tension for single & double orange straps, and single/double green straps, as shown below

Single and double green strap tension vs time

Single and double orange strap tension vs time

 

Stay tuned!

Frank

 

 

Digital Tension Scale

Posted 27 October 2018

I recently underwent rotator cuff repair surgery on my left (dominant) shoulder, and am now starting the rehab process.   My PT person was adamant that I not re-start my normal rowing routine for at least six weeks post-op, due to the possibility that I could re-tear the tendon.   This made me curious as to what the tension really was on my arms when rowing, so I decided to try and build a digital dynamic tension sensor, capable of plotting rowing strap tension in real time.

To start, I had to educate myself on the world of strain gauges and load cells, and what the differences are.   As I came to understand, what I wanted was a  load cell configured for tension measurement, with a  strain gauge as the active sensing element in the load cell.   So, I started searching for load cells, and was immediately inundated with ‘too much information’.   This deluge is certainly better than the old days where I had to search through paper (really, no internet!) magazines and catalogs, but at least you didn’t have to worry about overload headaches! ;-).

Anyway, I found this item ‘Degraw 40Kg Tension Load Cell and HX711 Combo Pack Kit‘, as shown in the screenshot below

Amazon catalog item for Degraw load cell

This looked perfect for my intended use, as I could hook one end onto my rowing machine strap, and connect some sort of handle to the other end.   Now all I had to do was figure out how to hook the thing up and get it to work.   Fortunately Degraw also provided a sketch of the hookup using an Arduino Uno, so that part was pretty easy.

Degraw-provided hookup diagram

After a bit more research, I found a nice HX711 library by bogde and some example programs, and got the whole thing to work using an Arduino Mega 2560.   Once I got a program running with some preliminary (but believable) results, I started thinking about how I was going to manage the physical aspects of hooking this assemblage to the rowing machine and recording dynamic tension.   I couldn’t really just let the HX711 board hang by the strain gauge wires while connected with jumpers to the Mega board, as the #28 strain gauge leads would surely break.   So, I came up with the idea of somehow attaching the HX711 board and a small microcontroller to the load cell assembly, and then connecting the whole thing to my laptop with a USB cable.   Hopefully the USB cable would be long enough to allow full extension of the rowing machine strap so I could collect full rowing cycle data.

After some digging around in my parts cabinets, I came up with two candidates for the ‘small microcontroller’ part of the plan; a 3.3V Teensy 3.2, and a 5V/16MHz Sparkfun Pro Micro.   I tried the Pro Micro at first, and almost immediately went down the rabbit hole (my term for getting lost in some technical wonderland without a clue how to get back) trying to figure out how to program the device – a challenge due to the way it handles com ports through the USB connector (it actually implements two different ones, depending on whether the boot loader or the user firmware is running – yowie!).   After climbing my way out of the rabbit hole, I decided to try the Teensy 3.2 instead, as I familiar with it from several other projects.   With the Teensy, I got a test program running and started taking data with known weights attached to the load cell. The way I did this was to suspend a plastic bucket from the load cell, and poured water into the bucket one liter (1Kg) at a time while recording data.   This was successful because I got good data, but unsuccessful because the data didn’t make much sense, as shown in the plot below

Results of pouring 1L (1Kg) water at a time into bucket suspended from load cell, using a 3.3VTeensy 3.2

As can be seen, the data was anything but the stairstep function I was expecting to see.   At this point I wasn’t sure if I had a hardware problem or a software problem, or something else entirely, so I sent an email to Degraw Product support with the above plot attached, asking if they had any insight into the problem.   Amazingly, they replied almost immediately, and offered to send me another load cell unit gratis so I could eliminate their hardware as the cause of the problem.   Although I was quite pleased with their offer of support, I thought maybe the 3.3V supply of the Teensy 3.2 might be causing the non-linearity (the HX711 advertises 2.7-5V operation but the lower voltage might be causing output linearity problems).   So, I tried again with the Sparkfun Pro Micro, and this time I managed to make the programming magic work. Then when I did the same test as above with the 5V Pro Micro instead of the 3.3V Teensy, I got the plot shown below.

Tension vs time plot created by pouring 1L (1Kg) of water at a time into bucket suspended from load cell, using Sparkfun 5V Pro Micro

So, now that I had the software and microcontroller problems solved, I started working on the mounting issue.   After a few minutes in TinkerCad and some quality time with my PowerSpec 3D PRO 3D printer, I had a mounting platform that clipped onto the two vertical rods in the ‘S-shaped’ tension load cell, as shown in the images below.

Reverse side of assembly, showing mounting plate clips attached to load cell vertical members

Sparkfun Pro Micro and HX711 board mounted on load cell

After getting all this set up, it was time to take some real data. Since I was still in the ‘no rowing’ zone after my surgery, I enlisted my lovely wife to do the honors while I recorded the data.   We have an Avari magnetic rowing machine, which thankfully doesn’t make much noise.   I recorded a total of 12 rowing cycles on two different ‘wave’ settings (I’m still not sure what the different ‘wave’ settings mean) at the lowest tension level, with the results shown below

As shown in the above plot, the peak tension reading was around 18Kg (about 40 lbs).    I’ve included a short video of the test below.

State memory for Wall-E2 – writing telemetry packets to FRAM

posted 28 September 2018

In previous posts, I have described my effort to give time, memory and relative heading super-powers to Wall-E2, my autonomous wall-following robot.   This posts describes a helper class I created to allow Wall-E2 to periodically write its current operating state to FRAM memory, for later readout by his human master(s), and a small test program to verify proper operation of the helper class.

My current conception of Wall-E2’s operational state consists of the current time/date, its tracking mode and submode, and the current left, right, and forward distances, and the current battery voltage. These parameters have been encapsulated in a CFramStatePacket class with methods for writing state packets to FRAM and reading them back out again.   The complete code for this class is shown below. Note that all the class code is contained in just one file – FramPacket.h.   There is no associated .cpp file, as I didn’t think that was necessary.

To test my new CFRAMStatePacket class, I created a small test program that periodically writes simulated state packets to FRAM using the helper class methods, and optionally (if the user creates an interrupt by grounding the appropriate pin) reads them back out again.   This program is designed to run on an Arduino Mega 2560.   If a Uno is used, the interrupt pin number would have to be changed.

The test code also looks for a low on the  CLEAR_FRAM_PIN (Pin 3) on startup.   If it finds one, it will clear  NUM_FRAM_BYTES_TO_CLEAR (currently 2000) FRAM bytes and then read them back out again, byte-by-byte.   Otherwise, the program will continue storing state packets where it left off the last time it was powered up.   Here’s the test code:

And here’s some output from a typical run:

And here is an Excel plot showing the simulated values

Plot of the simulated values generated by the test program

 

So now I have a way for Wall-E2 to write a minute-by-minute diary of its operating state to non-volatile storage, but I don’t yet have a good way to read it all back out again.   That’s the next step – stay tuned!

01 October Update:

I created a small program to read back telemetry packets from FRAM.   When I want to see what  Wall-E2 has been up to, I will replace his normal operating firmware with this sketch, which will allow me to read out all or parts of FRAM contents.   The sketch is included below:

and a typical output run is shown below.   Note that this program decodes the stored 4-byte unix time value into human-readable date/time format.   And yes, I know it’s in that funny ‘American’ mm/dd/yyyy format, but I’m an American, so … ;-).

 

 

Frank

 

Integrating Time, Memory, and Heading Capability, Part VIII

Posted 13 September 2018

Now that I have worked out most of the problems associated with the MPU6050 6DOF IMU module, it was time to integrate the new heading-based turn algorithm into the main Wall-E2 operating system.   As I have done in many past projects over the last half-century or so, I started this process by documenting the entire OS, with particular emphasis on how Wall-E2 currently navigates around his world.   When I started doing this in the 1970’s, the medium I used was an MIT Engineering notebook, hand-written in ink.   Over the ensuing decades the medium has changed, but not the basic idea – the process of putting coherent sentences and paragraphs onto paper (or screen) forces me to think through what is – and is not – important/true.   I have solved many a seemingly intractable problem not with an oscilloscope or debugging tool, but by simply writing things down.   In the current iteration of this process, I use Microsoft Word (not for any particular reason, except that it is available and familiar)   initially, and then dump the results into a post like this one – see below ;-).

 

Description of FourWD_WallE2_V1 Navigation Algorithm

09/04/18

At the start of each pass through loop(), the software determines the current OPMODE given the current environment and the immediately previous OPMODE.   The existing OPMODEs are NONE, CHARGING, IRHOMING, WALLFOLLOW, and DEADBATTERY

  • NONE: Default OPMODE when no other mode can be found to apply to the situation.   As of this writing, the only use for this OPMODE is to initialize the PrevOpMode and CurrentOpMode loop variables in Setings()
  • CHARGING: set in GetOpMode() if the charger is physically connected (CHG_CONNECT_PIN goes HIGH) and the CHG_SIG_PIN is active (LOW). In the CurrentOpMode Switch the PrevOpMode is also set to CHARGING (so that both prev and current op modes are CHARGING), the motors are stopped, and MonitorChargeUntilDone() is called.
    • MonitorChargeUntilDone() blocks until charging is complete, or the BATT_CHG_TIMEOUT value is reached or the charger is physically disconnected (manually pulled out for some reason).
  • IRHOMING: Set in GetOpMode() when the call to IRBeamAvail() (checks IR beacon signal strength) returns TRUE.   In the CurrentOpMode Switch the PrevOpMode is also set to IRHOMING (so that both prev and current op modes are IRHOMING).   A blocking call is made to IRHomeToChgStn() with an Avoidance Distance’ of 0 for hungry’ or 30cm (for full- no need to charge’. The idea here is that in the full’ case, the robot will continue to home until near the charging station, and then break off.
    • IRHomeToChgStn(): sets up a PID and enters a loop, exited only when either the charger connects, or the robot gets stuck or it gets too close to the charging station (this can only happen in the full’ case).   Is Stuck’ is determined in IsStuck() if the front distance variance gets too small (i.e. the front distance isn’t changing).
  • WALLFOLLOW: This is the OpMode that is assigned by GetOpMode() when none of the other mode conditions apply. IOW, this is what the robot does when it isn’t doing anything else.   In the WALLFOLLOW Case section of the CurrentOpMode Switch, the wall-following operation is further broken down into a TrackingCase Switch, with   TRACKING_LEFT, TRACKING_RIGHT, TRACKING_NEITHER sub-modes, with state mode variables maintained for both the current and previous tracking modes.   Each time through the loop(), the various tracking cases make one adjustment to the left/right motor speeds. there are no blocking calls at all in the entire WALLFOLLOW section, with the exception of the BackupAndTurn()’ calls in the TRACKING_LEFT and TRACKING_RIGHT cases when an obstruction or the stuck’ condition is detected.
    • BackupAndTurn( bool bIsLeft, int motor_speed): The idea here is for the robot to back up and do a course change to extract itself from some situation. Up until now, this has been accomplished by making a timed turn one way or the other, but this hasn’t worked well because the correct time for turning on carpet is wildly different than the correct time on hard flooring.   The new heading sensor is intended to solve this problem.
    • Now that Wall-E2 can make accurate turns, the question becomes “what’s the best way to do obstruction-avoidance or stuck-recovery turns?”. If Wall-E2 is following a wall when it gets stuck, maybe it should back up slightly and try to go around, or maybe it should just turn around and go back the way it came.   Maybe a simple obstruction should be treated one way, but a stuck’ condition treated another?   The go back the way I came’ model is simple enough but might result in an uninteresting ping-pong’ shuttle track where it stays until it runs out of battery.   A more complex response might allow the robot to go around obstacles and continue its journey?   Maybe it backs up slightly (wall-following in reverse, maybe?), and then makes an X degree turn away from the wall, runs straight for a second, and then starts wall following again.

09/05/18

The current BackupAndTurn()’ routine takes bIsLeft, a Boolean representing the current tracking direction (left or right) and a motor speed.   All it does is call RollingTurnRev(bIsLeft, 1500), where 1500 is the time in millisecond to run the motors.

RollingTurnRev() just calls RunBothMotorsMsec() with the motor speed on one side set to MAX and on the other to OFF (we know this won’t work on Wall-E2, because the wheelbase is too wide – he just locks up.

RollingTurnRev() is called in two places; ExecDiscManeuver() and   BackupAndTurn(). BackupAndTurn() is called from 4 places;   TRACKING_NEITHER/RIGHT/LEFT, and IRHomeToChgStn().   In all these cases, the robot knows which (if any) wall is closer, so it can execute the proper rolling turn

From what I see so far, it appears all these cases can be handled by a turn routine that does the following:

  1. Moves straight backward for just a second or so (or maybe even less)
  2. Makes a 45 ° forward rolling turn away from the nearest wall. If there is no nearest wall, go opposite the way it went last time (requires a global Boolean to save this value)
  3. Makes another 45 turn in the opposite direction to the first one.   This will have the effect of a side-step maneuver, as shown in this post.

After this review, it was clear that all I had to do to integrate the new heading-based turn capability into Wall-E2’s OS was to replace the RollingTurnRev() function with a new ‘RollingTurn()’ function that takes flags for FWD/REV and for CCW/CW, and a parameter for the number of degrees to turn.   Since I had already demonstrated all the code blocks in stand-alone test programs, all I had to do was copy the appropriate code pieces into the appropriate spots in Wall-E2’s OS, and then spiff things up a bit here and there.   When I was done, I had a single function that could facilitate a range of maneuvers.

To test the newly integrated capability, I added some code to Wall-E2’s setup() function to perform a series of S-turns, each of which demonstrates a typical avoidance maneuver. For convenience, I told Wall-E2 to execute a ‘K-turn’ reversal and then S-turn his way back to me.   As can be seen in the following short video, this worked fairly well!

Now that I have the basic heading-based turn capability integrated into Wall-E2, the next step will be to demonstrate that Wall-E2 can use its new superpowers to avoid obstacles in ‘the real world’ (as real as it gets for Wall-E2, anyway).

Stay tuned!

Frank

 

Integrating Time, Memory, and Heading Capability, Part VII

Posted 29 August 2018

In my last post on this subject, I demonstrated Wall-E2’s new found ability to make heading-based turns instead of timing-based ones, making the turns much more terrain-independent.   Unfortunately, as I continued to test this capability, it became clear that Wall-E2’s heading superpower wasn’t quite ready for prime time.   Sometimes he turned 45 deg or even 180 deg when asked to do 90 – oops!

So, I went back to my small test setup – a spare Mega and a small solderless breadboard, as shown below, and started going through the problem slowly and methodically.   Eventually I figured out that most of the problem was caused by the way I was retrieving yaw data from the Inversense MPU6050 (I have the DFRobots version).   I had the module set up to produce interrupts at 20Hz, and the code was trying to keep up with that (unsuccessfully, as it turned out).   Once I figured that out, I backed the code off to where it only checks for heading changes at a 10Hz rate, and things started working much better.

Arduino Mega and small plugboard test setup for robot turn management

I also figured out that the algorithm I was using for detecting the desired heading was fatally flawed.   I was trying to watch for the case where the current heading passed the target heading, but with all the special cases (both directions, the -180 – to – +180 cut, etc) I kept getting it wrong.   I finally found this post that describes a very simple formula for comparing two compass headings.   The formula assumes both values are in degrees in the range 0-360.   Mine are in degrees but in the range -180 to +180, but I took care of that by adding 360 to negative headings.   After some experimentation I settled on a match ratio of about 0.90 for the ‘slow down’ threshold, and 0.98 for ‘match’.   The 0.98 threshold provides about a 6 degree error margin, which with 10 measurements/sec means that the robot would have to rotate more than 60 deg/sec to get through 6 deg between measurements.   Experiments show that a 90 deg turn takes about 3 sec, meaning 30 deg/sec.   So there should always be at least 2 measurements at 0.1sec/measurement in the 0.2 sec it takes the robot to rotate 6 deg – a 2/1 safety margin.

The short video clip below shows the robot doing a series of 180 deg K-turns, simulating an avoidance maneuver.

 

So, at this point I think I’m pretty much done with adding turn management capability to Wall-E2’s superpower repertoire; however, I still have to update Wall-E2’s operating system software to replace the current timed-turn routines with the new heading-based turn routines.

08 September 2018 Update:

In my current Wall-E2 OS, when the robot gets stuck or runs into an obstacle, it backs straight up, and makes a timed turn away from the nearest wall if there is one, otherwise it turns the opposite way it did from the last time it was in a similar situation.   This is all fine and good, but  now that Wall-E2 has heading-aware turn capability, he should be able to respond a little more intelligently.   As indicated in the diagram below, the idea is that Wall-E2 could back straight up from an obstacle, and then go around it by making two linked 45-90 º turns one way or the other (away from the nearest wall if there is one.

New avoidance maneuver made possible by Wall-E2’s new heading superpowers

As an experiment, I programmed this maneuver into Wall-E2 using linked 45 º degree turns, just to see how it would work out.   As the following short video shows, it seems to work very well.

Stay tuned!

Frank

 

Mid-2018 Wall-E2 Project Status

Posted 26 August 2018

It’s been a year and a half since I last described the status and challenges in my ongoing campaign to create Wall-E2, an autonomous wall-following robot.   The name ‘Wall-E’ was taken from the 2006 movie of the same name.   In the movie, Wall-E was an autonomous trash-compactor robot that had all sorts of adventures, and my Wall-E2 autonomous wall-following robot certainly fills that bill!

From the previous system status report in early 2017, I described the following tasks:

Its been a year and a half since I updated the status of my ongoing campaign to create an autonomous wall-following robot.   The robot system consists of the following main subsystems:

  • Battery and charging subsystem
  • Drive subsystem (wheels, motors and motor drivers)
  • IR homing subsystem for charging station
  • LIDAR for front ranging and ultrasonic SONAR for left/right ranging
  • I2C Sensor subsystem (MPU6050 6DOF IMU, FRAM, RTC)
  • Operating system

Battery and charging subsystem:

Since the last update, the battery and charging system has been updated from dual 1-Amp single-cell Adafruit PB1000C chargers utilizing a 5V source to a TP-5100 2-amp dual-cell charger utilizing a 12V source.   This significantly simplified the entire system, as now the battery pack doesn’t have to be switched between series and parallel operation. Also, now the charging and supply leads are independent so the supply leads to the rest of the robot were upgraded to lower gauge wire to reduce the IR drops when supplying motor drive currents.   See this post for details.

Drive subsystem (wheels, motors and motor drivers):

The motors were upgraded to provide a better gear ratio, although this was done before I realized that most of the traction issues were caused by IR drops in the battery wiring.   The motor driver modules are unchanged, but I may later swap them out for more modern 3V-capable drivers so that I can swap in an Arduino Due microcontroller for the Mega (the Due has the same footprint/IO as the Mega, but has a much faster CPU and more memory)

 IR homing subsystem for charging station:

The IR homing subsystem utilizes a pulsed IR beacon on the charging station coupled with dual IR sensors in a flared sunshade housing, backed by a Teensy 3.5 CPU configured as a null pattern matched-filter.   The Teensy reports left/right homing error as a value between -1 and 1 over an I2C bus to the main microcontroller, which drives the motors to null out the signal.   As the system stands today, the operating system can successfully home in on the charging station and connect to the charger. The robot knows its current battery voltage (charge condition) and therefore can decide to connect to the charger or to avoid it.

LIDAR for front ranging and ultrasonic SONAR for left/right ranging:

The front/left/right ranging subsystem is one of the most mature subsystems on the robot.   The subsystem can successfully follow walls, and detect/recover from stuck’ conditions.   The only thing this subsystem lacks is the ability to make consistent turns on different terrain, due to the lack of heading information (this will be supplied by the new tri-sensor module)

I2C Sensor subsystem (MPU6050 6DOF IMU, FRAM, RTC):

The I2C sensor subsystem is a new addition since the last update, and has yet to be fully integrated into he system.   The subsystem consists of a Inversense MPU6050 6DOF solid-state accelerometer, and Adafruit FRAM (Ferromagnetic RAM) and RTC (Real-Time Clock) modules.   The MPU6050 gives the robot the ability to sense relative heading changes, which makes it capable of executing consistent N-degree turns on both hard flooring like the kitchen and atrium areas and the carpet in the rest of the house. The FRAM and RTC units should allow the robot to remember its charge/discharge history, even through power ON/OFF cycles.

The relative heading capability has been tested off-line from the main operating system, but has not yet been integrated into the OS. Same for the FRAM/RTC modules.   Integration of this subsystem was stalled for quite a while due to problems with the Arduino I2C (Wire) library, but these problem were just recently resolved by switching to a more robust I2C library (SBWire).   See this post for details.

 

Operating system:

The operating system has evolved quite a bit over the course of this adventure, but its current state seems pretty stable.   The OS is implemented as a set of modes, as follows:

  • MODE_CHARGING: Occurs when the robot is physically connected to a charging station
  • MODE_IRHOMING: Occurs when a charging station beacon signal is detected
  • MODE_WALLFOLLOW: Occurs when the robot isn’t in any other mode.
  • MODE_DEADBATTERY: Occurs when the sensed battery voltage falls below DEAD_BATT_THRESH_VOLTS volts

 

 

Future Work Plans:

  • Complete the integration of the tri-sensor module: This entails adding the hardware and software required to sense loss of power so that the current date/time stamp can be written to the FRAM, along with the complementary ability to read out the last power cycle date/time stamp from the FRAM on power-up.   In addition, the current timed turn routines need to be replaced by the new heading-sensitive turn algorithms.
  • Investigate the idea of multiple charging stations with different IR beacon frequencies. The current matched filter algorithm forms a very narrow-band filter, to discriminate the desired IR beacon signal from unwanted flooding’ from overhead lighting sources and sunlight.   The center frequency of the filter is set in software on the Teensy microcontroller, so it should be possible to have the Teensy routinely check for beacon signals at other signals, as long as the frequencies are far enough apart to prevent overlap.   The current filter center freq was more or less arbitrarily set to 520Hz. high enough to be well away from, and not a multiple of, 60Hz, but low enough for the Teensy processing rate.   Something like 435Hz (60*7.25) would probably work just as well, and is far enough away from 520Hz to be well outside the filter bandwidth (about +/- 10Hz IIRC).

Complete the implementation of the fixed charging station.

This task has been completed, and along the way the charging voltage was changed from 5V to 12V, to accommodate the new 12V on-board battery charging system.   See this post for details

Integrate the IR homing software from the 3-wheel robot into Wall-E2’s code base:

This task has also been accomplished.   See this post for details.

Integrating Time, Memory, and Heading Capability, Part VI

Posted 25 August 2018

In my previous posts, I have been describing my efforts to give Wall-E2, my autonomous wall-following robot, relative heading sensing ability using the DFRobots MPU6050 6DOF module.   As I went through this process, I discovered that the ‘standard’ Arduino Wire library was seriously defective, and the problem had been known, but not fixed for almost a decade!   Once I figured this out, I was able to fix my local copies of Wire.c/h and twi_c/h and all my hangup problems went away.   Subsequently I found another Wire library (SBWire by Shuning (Steve) Bian that also incorporates the necessary fixes, so I started using his library instead of my own local fixes.

Anyway, after all the I2C drama, I finally got the damned thing working, and ran some tests to demonstrate Wall-E2’s new-found ability to make reasonably precise and consistent turns.   In the first test I had Wall-E2 make a series of 90-deg (ish) turns, and in the second one I had him make some 180-deg (ish) K-turns to simulate what he might want to do after disconnecting from (or avoiding) a charging station.

Known defect in Arduino I2C code causes hangup problems

Posted 20 August 2018

06 July 2020 Update

Miracle of miracles!  Arduino finally got off their collective asses and decided to do something about the well-known, well-documented, and long-ignored I2C hangup bug.  Thanks to Grey Christoforo of Oxford, England for submitting the pull request that started the ball rolling.  See https://github.com/arduino/ArduinoCore-avr/pull/107 for all the gory details.  However, in a bizarre outcome, the implementation of the needed timeouts isn’t implemented by default! You have to modify your code to add a call to a new function, like the following:

Note that you have to explicitly add a timeout value (1000 in my example above) or the timeout feature will still not be enabled! The ‘true’ parameter tells the library to reset the I2C bus if a timeout is detected – surely something you will want to do.

I’m currently working on a ‘before/after’ post to demonstrate that the new timeout feature actually works with real hardware scenarios.  However, due to the intermittent nature of the I2C hangup bug, it takes a while (hours/days) to grind through enough iterations to excite the bug reliably, so it may be a while before I have a good demonstration

One last thing; at some point the examples in C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire\examples (on my Win 10 machine) will probably be updated/expanded to show how to properly implement the new timeout feature, but this has not happened yet AFAICT.

Stay tuned!

In my continuing quest to add relative heading sensing to Wall-E2, my autonomous wall-following robot, I have been trying to make the Invensense MPU-6050 module sold by DFRobots work on my robot.

In my last post on this topic, I had finally figured out that the program lockup problems I had been experiencing were due to a well-known-but-never-fixed bug in twi.c the low-level code associated with the Arduino I2C library.   This utility program has a number of while() loops used to send and receive bytes across the I2C bus, and every one of them is prone to deadlock when the device(s) on the other end of the bus misbehaves at all.   Then the while() loop never exits, and whatever program is running dies a horrible death.

The weird thing about this problem is that it has been known for at least a decade (yep – 10 years!!!), and has actually been fixed multiple times by multiple people over this period, but the fixes have never made it into the ‘official’ Arduino Wire library.   This makes  NO SENSE, as the Wire library code is open-source, and is available on GitHub.   I thought the whole idea behind open-source code and GitHub was that others could contribute code fixes in a reliable revision-tracked way, so that when someone finds a bug, it can be fixed quickly and then propagated out to all users.   Apparently the guys at Arduino never got the memo, because I found it impossible to get a ‘Pull Request’ containing the bug fix through the code-maintainer’s gauntlet.

Thinking this was just a logistics problem that I could solve with just a few hours of elbow grease, and would be a good training exercise for other open-source collaboration projects, I decided to take a swing at this problem myself – how hard could it be?

  • I thoroughly researched the technical issues, made the changes to my local copies of Wire.cpp/h and twi.c/h, and verified that they indeed fully solved the hangup problems
  • Found the releveant Arduino Wire library source tree on GitHub
  • Forked the Arduino Wire library source tree to my own GitHub Account
  • Cloned my fork of the Arduino Wire Library to my PC
  • Made all the relevant changes to my local repo, tested the result, and pushed the changes to my GitHub repo.
  • Created a ‘Pull Request’ with all the changes, with a descriptive note

By this time, I had expended a LOT of time, but that was OK as I had learned a lot that would pay off in future efforts, and besides I was finished – I thought!

Then I got a very nice email from the Arduino maintainer of the Wire library, listing all the things I had done wrong, and making it clear that the changes wouldn’t be merged into the ‘official’ Wire library until all was correct to their satisfaction.   When I looked at the list of problems, I realized most of it was about ‘whitespace’ mismatches between my submission and the official version.   Now, I don’t know about you, but I stopped thinking about whitespace a decade or so ago, when it became clear that whitespace was just a figment of the programmer’s mind, and had NOTHING WHATSOEVER to do with how well or poorly the code actually worked.   Now I was being asked to manually correct all the literally hundreds/thousands of places where my code had 2 spaces and the ‘official’ code had 3!   So, if I wanted this bugfix to get into the main distribution, I was going to   have to spend a HUGE amount of time dealing with nit-picking aesthetics that have nothing whatsoever to do with anything but somebody’s misplaced idea of right and wrong with respect to whitespace, for source files that are rarely, if ever, viewed by 99% of the Arduino programming community.   I mean, this would be like refusing to make a small, but important change to the maintenance manual for a car because the shop technician’s penmanship wasn’t up to par!   What is penmanship going to matter when known defects aren’t corrected?

So, I thought about that some more, and I came to realize why this I2C hangup bug has been around for so long – nobody’s pull request has ever made it through the ‘penmanship contest’ gauntlet; the Arduino maintainers are more interested in penmanship than in fixing clearly defective code that has (and still is) causing grief for anyone who tries to use the I2C bus.   My personal response to this problem was “screw them – I’m not going to spend all that effort just to please someone’s weird affection for whitespace, especially since my local copy of these files has already been fixed.

With just a little bit of searching, I found Steve Bian’s ‘SBWire’ library with timeouts added to all the while() loops in twi.c, and was quickly able to ascertain that Steve’s library did indeed solve my hangup problems.   Moreover, Steve actually answered my emails, and is undoubtedly much more open to open-source collaboration than the guys at Arduino.

The sad thing about all this is that Arduino is not doing themselves any favors by making themselves part of the problem rather than part of the solution. If they aren’t going to actively maintain their baseline code distribution, it (and Arduino) will become irrelevant as users find other ways around the obstacles.

Frank

25 August update:

So, I did the same thing with Shuning (Steve) Bain’s SBWire library that I had done with Arduino’s Wire library.   Forked his repo, cloned it to my PC, made the small changes I wanted, pushed to my repo, and created a pull request.    Two Days later, Shuning had merged my changes into the library.   Now I do realize that SBWire isn’t ARduino Wire, so maybe a ‘higher standard’ might be justified for the ‘gold standard’ I2C library.   However, I think we could all agree that EIGHT FRIGGIN’ YEARS  of known defects is probably a bit much!

So, my advice, if you’ve been having problems with I2C hangups, is to throw the Arduino Wire library in the nearest trashcan and use Shuning’s SBWire library

26 August Update:

I have been running SBWire on a little I2C test board, and I left it running over the weekend while my wife and I were away on a trip.   When I came back, some 95 hours later, the board was still running merrily.   I did note that the ‘lockup counter’ (the number of times the standard Wire library code would have locked up) stood at 14, or about once every 7 hours or so.   Actually I’m a bit surprised by this number, as in my personal experience the Wire library never lasted more than about 2 hours before locking up.

Just another reason to dump the Arduino Wire library and use something useful like SBWire ;-).