There is a lot of text below, so I’ll summarize the project up here. Duluth has a bridge that raises and lowers for shipping traffic, but there is no way of knowing when, exactly, this occurs except to see it happen. My solution to this is a model of the bridge that moves in real time; when the bridge goes up, the models go up — anywhere in the world. I accomplished this with machine learning (tensorflow), IoT devices, and a considerable amount of failure.

If your time is short, there are a number of images that show the general process, otherwise there are details on most of the important aspects that might be interesting.

Thanks for looking!

Intro

The Aerial Lift Bridge is an iconic landmark in the city of Duluth, Minnesota and is the only way drive to or from the Park Point sandbar. The bridge also spans a canal that sees a high volume of shipping traffic and goes up to allow ships to pass at unpredictable times throughout the day, leaving many people trapped and waiting for the roughly 10 minute cycle time to conclude. Getting “bridged” has become local (and frequently used) term for getting stuck on either side when the bridge goes up – there are even people who sell shirts while you wait with the term on it.

While eating at a local restaurant that features the bridge in their logo, I had the idea to make a working model of it that could operate in sync with the real one. This model may be used simply to communicating the status of the bridge to those who may be affected or possibly as an eye-catching display on the walls of local businesses. However, there were and are a number of technical and manufacturing challenges to overcome to complete this project.

R&D

This section should really be called “A Series of Costly, Time-Consuming Attempts”. To summarize, using image recognition on a live webcam feed failed because of the inability to adequately account for all potential parameter changes like lighting and fog, LIDAR (a laser range finder) failed because permission from the city to install the sensor beneath the bridge was refused, and audio recognition (the final solution) proved to be a difficult egg to crack.

The primary issue concerning this project is that, currently, there is no way to know the status of the bridge at a given time, meaning that there is no signal I could send to the bridge model to communicate when it should move. The one exception to this that I could find is a public webcam hosted by the Lake Superior Marine Museum that streams a live view of the bridge. Initially, I thought that I would be able to use the webcam feed and the computer vision library OpenCV to track the bridge and therefore generate the signal, however this posed a couple of problems.

The first issue is that the webcam is out of my control. This means that any changes made to the camera such as position, imaging settings, IP address, etc. would have the potential to cause errors that could render the bridge models inoperable. The administrator at the museum in charge of the webcam liked my idea, but was unable to grant access to the direct video feed. That being said, I did write and test a program in Python that successfully tracked a section of the bridge based on recordings made of the webcam stream.

The second issue is that the lighting conditions and weather vary so much that creating parameters adaptable enough to accommodate all or most conditions seemed unlikely.

The LIDAR route involved an Arduino-based microcontroller called the Particle Electron that integrates a laser range finder (Lidar Lite V3), wireless communication via GSM (cellular), and thermal management devices and would be installed directly beneath the bridge. For over two months, I waited for a response from the city about permission to install my electronics enclosure. About a month in, I decided to chance it and purchase the necessary components for developing this system only to find out later that an installation of this type wouldn’t be permitted. It was a discouraging response, but I decided to move on quickly to finding an alternative route.

Solution

The solution I decided on is uses many of the same components as the LIDAR option including the modified enclosure, power supply, and thermal management devices but replaces the LIDAR with a microphone and adds the processing power of a Raspberry Pi. Instead of “watching” the bridge, this solution listens and assesses the state of the bridge by the distinctive bell that rings only when the bridge is in motion.

To accomplish this, a convolutional neural network (CNN) was trained on hundreds of short audio samples taken from recordings of the bridge. The CNN was created by Karol J. Piczak (github) to detect and classify common environmental noises and was adapted with his help to meet the requirements of this project. Once properly trained, the relatively small training files were loaded onto the Raspberry Pi for remote use.

An Arduino, connected to the Raspberry Pi, is equipped with GSM capabilities allowing the sending and receiving of SMS messages. When the state of the bridge changes, a text message is sent to the cloud and an “event” is created. The model bridges will be subscribed to these events and will be notified as they occur. This communication process takes around 3 seconds to complete, resulting in approximately 5 seconds of delay between real bridge motion and model motion.

Model Design

The bridge structure is made primarily from .080″ thick 6061-T6 aluminum with 1.300″ thick plates for the Arduino/motor housings. With the exception of the sheaves (pulleys), all aluminum parts are designed to be cut on a waterjet with minimal secondary operations like drilling and grinding. I have decided to use universal head pull-through rivets as the primary fastener due to cost, aesthetic, and short assembly time. The rivets are permanent once installed, so flush-head machine screws will be used on the rear motor housing access plate for maintenance and electronics installation. The intent of the model design was to make it as close to the real bridge as possible. Because of this, I wanted to have two motors located on either side of the moving central section of the bridge, however that raised the issue of how to route the power supply. The stepper motor and Arduino have been moved to the static bridge frame and the cable routing has been changed to allow a single motor to drive the bridge motion.

The stepper motor is an inexpensive 15BY45-100 motor found in many printers and office appliances. It has 18 degree steps meaning 20 steps/revolution. The bridge takes approximately a minute to both raise and lower, so the 5.5 inches of travel is designed to take around 120 steps to increase the smoothness (think analog clock that has 1-second increments vs. constant motion.) This can be achieved by decreasing the drive pulley diameter to .292″.

The model counterweight is practical and will aid the bridge motion, reducing the motor power needed. Despite this, the torque rating of the motor is capable of operating the bridge without the counterweights if necessary.

One interesting element of the lift bridge is the large chain suspended between the frame and counterweight. This chain actually acts as a variable counterweight to offset the mass of the cabling as the bridge changes location. When down, the bulk of the cable mass is located on the bridge side of the sheaves and therefore requires additional mass on the frame side to balance. As the bridge raises, less cable is bridge-side and more of the chain mass is supported by the frame. Although the effect of this variable counterweight is diminished by the scale of my model, I wanted to incorporate it into the design because it is an interesting feature, both from an engineering and artistic perspective. After not finding roller chain at the correct scale dimension, I decided to use a 1 mm box chain necklace that resembles the appearance of roller chain. Jewelry fasteners will be used to attach the chain to both the counterweight and the frame.

To acquire more information, I reached out to the Minnesota National Archives in Minneapolis, MN with the hopes that they might have more documentation on the bridge. Fortunately, a woman there was able to provide schematics from a bridge restoration project in 2001 that provided enough detail to feel comfortable using it for the model design. Additionally, many reference photos, taken both by others and myself, were used to incorporate smaller details not shown in the MN Archive schematics.

The first bridge has been sold! The Duluth Grill now features my bridge on their wall.