HoistInsight - A brain for your crane

Utilizing GPS tracking, point-to-point networking and mobile devices to increase safety and improve efficiency in crane hoist operations.

Similar projects worth following
We have GPS in our cars that tells us how to get where we need to go. It alerts us ahead of time when we must make a turn. Why should the technology in a crane operator's car be more advanced than that in his multi-million dollar crane?

This project aims to bring modern safety and convenience features to crane owners/operators with compelling technology and a price that can't be turned down.

Please ask me any questions you may have about the identified problems or my approach to the solutions.

Picture yourself seated at the controls of a very large crawler crane. You've got a 4,000 lb. steel beam rigged and ready to lift. With your many years of experience, this should be no problem -- right? Wrong!

As you lift the beam and begin to swing toward its intended resting place, your entire view of the scene is obstructed by the walls you erected yesterday. You are now "flying in the blind". Rather than relying on your own sight to help steer your load, you now must rely on a flagman on the ground to give crane signals via two way radio.

Even with the most experienced flagman on the job, there are always communication issues when using two way radios rather than hand signals. It may be too loud for the operator or flagman to hear the other clearly (it is a construction site after all) or the quality of the radios could be poor among other things. Put an unskilled flagman on the radio or a flagman who doesn't speak the signals clearly in the operator's language and you've made a difficult situation that much harder.

With HoistInsight, the crane operator will always be aware of the position and movement of his load, even when flying in the blind! 

With a mobile device in the crane cab paired to the 'Operator' module (more details to come), and the 'Load' module installed above the lifting hook, the operator can use the 'Hoist Manager' software (more details to come) to help plan and execute a lift. He can see the location of his crane and the location of the hook (X, Y and Z), as well as the location of the target (more on this below).

Knowing where the load is and where it needs to go, the operator can now make more sense of the flagman's signals. Also, utilizing an optional wearable 'Flagman' module (essentially a 'Load' module repackaged in wearable form), the crane operator can see the flagman's position and finally make sense of "come towards me 40'".

Using the job's drawing files, the operator can calibrate (details on this later) the drawing with the crane, so when pictured the drawing is scaled and rotated to match the real world (relative to the crane). Now the operator can choose an item from the drawing to set as the target. The software accurately places the target indicator based on the crane's coordinates and the offsets and orientation of the scaled drawing.

When an acceptable drawing file is not available, a member of the ground crew can use the optional 'Flagman' module to manually set the target location. They accomplish this simply by placing the module near the center of the target and pressing the appropriate button on the outside of the module. With these coordinates automatically relayed to the 'Operator' module, the lift can then proceed smoothly.

  • Schematic

    salokcin08/21/2014 at 06:50 0 comments

    I'm finally getting my feet wet with Eagle for designing the schematic. It shouldn't be much longer before I can post v1 of the schematic to the GitHub. I will work on the board design after I've spent a little more time understanding the enclosure restrictions. The good news is that all the hardware, firmware and software is working together happily!

  • Final (hopefully) THP requirements

    salokcin08/21/2014 at 06:45 1 comment

    HoistInsight System Design

    There are two main modules comprising HoistInsight -- the Operator module and the Load module.

    Both are very similar, except the Operator module connects to a smart/mobile device running the Hoist Manager software (the brains).

    Operator Module

    This module contains an EM-406 GPS device, an XBee-PRO 900 radio, an Arduino Pro Mini 328 and a mobile device of the operator's choosing. The XBee radio receives transmissions from the Load module that tell the operator where the load is in real time.

    Load Module

    The load module contains the same GPS, XBee and Arduino, but has no need to connect to a mobile device. It simply relays it's position (from the GPS unit) back to the Operator module.

    Mobile Device

    All of the "heavy lifting" is done in software running on the mobile device. Given the location of the Operator module and the Load module, the software can create lift plans and provide audible warnings when the load strays outside of the appropriate boundaries.


    Currently the only licensed items are the Arduino librarys an 'Xaml Map' (used in the client application). I will strive to use the most open software available. My software, hardware and firmware will be released under the most permissive license available (haven't done the research at this point to determine what that is).

    I would like to see this device on every crane operating at least in America. It WILL save lives and it WILL improve efficiency substantially. I would like for anyone interested in helping with this project to feel free to do just that. Everything I do will be 100% open.

    Open items

    I still need to design and fabricate the enclosures for both modules. I need to research and prototype sufficient rechargeable battery solutions that will last at least one shift.

    I've already figured out all of the math and I've already figured out how to scale and orient structural drawings such that they are a huge benefit to the crane operators.

  • PoC Success!

    salokcin08/21/2014 at 06:26 0 comments

    I now have an independent "Operator Module" and "Load Module" communicating with each other via the XBee-900 Pro radios. The Load module is sending its positional information (decoded from the GPS module's NMEA sentences) to the Operator module. The operator module is doing very little crunching of the data, then sending it along to my mobile device where the maps are updated to show the new location.

    I walked down the street about 30 yards just to prove it worked outside of a 5' range. I was pleasantly surprised! (Not that I really expected any different).

    In its current state, acting as a crane operator I can see my location and the location of my "load" as it moves in real time. 

    I have a crane company ready to get their hands on it YESTERDAY, so this is very exciting!

  • Safety "for free" and free money!

    salokcin08/20/2014 at 16:50 0 comments

    With a crane already equipped with the HoistInsight package, it should be no problem at all for the operator to cordon off "no fly zones" around the working radius of his crane. 

    • Is there a street you aren't allowed to swing over?
    • Are there difficult to see power lines hanging near your pick up location?
    • Are you absolutely, positively not allowed to fly ANYTHING over that playground to the East?

    With all the existing hardware in HoistInsight, it's simply a matter of geo-fencing areas to be avoided. This geo-fencing is not limited to strictly two dimensions either. While you definitely can't fly a load 30' off the ground over those power lines, there's no problem flying 120' above the same power lines.

    While there may be commercial solutions to handle this aspect of safety, they are extremely expensive -- to the point that crane owners will only purchase one when required by law.

    The HoistInsight solution will not be able to block operator controls as the load nears a "no fly zone", but it will sound audible alarms and flash on-screen warnings that are sure to get the operator's attention.

    HoistInsight accounts for these "no fly zones" when presenting an optimized lift plan to the operator. For example, the operator may be presented with the following choices for his lift plan:

    • Plan 1:
      • Raise load by 140'
      • While swinging right by 30°, trolley out (for tower cranes) by 55'
        • If the operator chooses not to trolley out (or fully) during this maneuver, the trolley instruction (or remainder is added to the next instruction)
      • While lowering load by 60', swing right by 25°, trolley out 20'
        • 20' is what remains from his previous trolley operation to get him to the full 55' necessary
      • Target is underneath
    • Plan 2:
      • While raising load by 80', swing left by 305°, trolley out 55'
      • Target is underneath

    In the first Plan, the operator must raise the load 140' above some known obstruction before beginning his swing. At height, the swing can begin for a full 30 degrees -- this clears the load of the obstruction. The operator can trolley out to the desired radius during this maneuver, during the next maneuver or combined in both. Now the operator can begin his final move of swinging the remaining 25° and lowering by 60'

    In the second Plan, the operator can bypass the obstructions in the first plan by simply swinging left instead of right. Any skilled operator can raise the load, swing the boom and trolley out all at the same time. This lift plan is MUCH simpler, though depending on circumstances it may take much more time to swing 305° than it does to complete the more involved maneuvers of Plan 1.

    The beautiful thing about HoistInsight is that it tracks and learns from the operator's performance and habits. If the operator consistently performs operations in series (i.e. he will only lift, or swing, or boom down/trolley at a single time, but no combination of those), it will suggest lift plans that are more effective based on his historical performance and habits.

    Additionally, with each and every lift data logged, it's possible to play back lifts in four dimensions to help management structure better training programs for operational efficiency and safety awareness.

    To sum it up: this solution warns operators before they get too close to pre-defined no fly zones, helping avoid costly accidents and it also provides meaningful metrics about crane operator performance so small improvements can be made to save companies time and money. This all accomplished with software updates and no hardware or firmware modifications!

  • In before "But GPS resolution is only <xyz>..."

    salokcin08/20/2014 at 05:29 0 comments

    Look, I understand that the resolution of civilian GPS systems is no where near the capabilities of military systems, but I think that's just okay! We aren't asking the crane operators to place a load with pinpoint accuracy without any help from the ground grew. We are asking the crane operators to identify the target and more quickly move the load into a position roughly above the target area.

    If a crane operator can move 4,000 load to within 4 meters of its intended target, that allows the flagman to concentrate on the pieces that actually matter rather.

    Imagine driving a fully-loaded semi-truck, blindfolded, up to a stop sign. Your passenger (flagman) is responsible for telling you when to stop so you don't blow through the stop sign. What if your passenger waited until you were AT the stop sign to tell you to stop? You will lock up the brakes and slide well through the stop sign. The difference for a crane lift is that once you miss the "stop sign" you have to wait for the load to stop swinging then back it up to where it should've been.

    What if your passenger (flagman) is more skilled than that? He knows to warn you ahead of time that you are nearing the stop sign. What he doesn't know is just how heavy your truck (load) is, so he doesn't know how early you should start hitting the brakes. He could tell you "100 yards away", in order to make you start slowing, but if the next thing he says is "10 feet away", unless you've already come to a crawl you will again blow through the stop sign.

    Perhaps he's a little more cautious and tells you every 10 yards closer you get to the stop sign. That helps... a little. If his signals are right on time and you can somehow gauge your approach rate, you may be able to stop the truck fairly close to the stop sign. More often than not, though, in this scenarios your truck ends up fully stopped well before the stop sign, then you begin creeping forward under the instructions of "another 30 feet, another 25 feet..." and so on.

    Now instead imagine driving that truck to the stop sign using a display that shows the position of the stop sign, position of your truck, distance between truck and stop sign, speed of your truck and time to target (stop sign). Include in that an acoustic tone (for the driver) whose frequency increases as the truck nears the stop sign.

    Again, this is still a difficult situation, but we've just provided tools to make it so much easier to handle!

  • Functional diagram

    salokcin08/20/2014 at 05:13 1 comment

    Hopefully the functional diagram picture I just added (below) is clear enough for most folks to understand:

    There are two main modules -- 'Operator' and 'Load'.

    The 'Operator' module is placed in the cab of the crane and interfaces with a mobile device (tablet, convertible PC, etc). It consist of 

    • a GPS device (to know where the center of the axis of rotation is roughly 
    • an XBee RF module to communicating remotely with the 'Load' module 
    • an Arduino Mini Pro for orchestrating the communications of the GPS and RF modules and finally
    • a mobile device for visualizing all the data and providing alerts.

    It should be clear that the GPS device simply sends data to the Arduino (as NMEA sentences). The Arduino then parses the sentences and extracts only the pertinent information. That information is then passed to the mobile device for viewing. Of course, viewing where the cab of your crane is in real time isn't all that helpful if you don't know the position of your load!

    The 'Load' module is very similar to the 'Operator' module except that it doesn't need to pair with a mobile device. This module is physically clamped to the hoist line directly above the headache ball. The Arduino parses the data from the GPS module and sends it via RF (the XBee-PRO module) back to the 'Operator' module. All of this data is ultimately presented to the 'HoistManager' application to aid the crane operator in make more informed decisions about his hoist.

    While I still have not yet nailed down the exact specifications around battery requirements, I envision this system will notify the operator when the battery level of the 'Operator' or 'Load' modules drops below an acceptable level, at which point the respective batteries must be recharged/replaced to continue optimal service.

  • Safety? That's for Hackaday trolls!

    salokcin08/20/2014 at 04:39 0 comments

    I'd like to start with a little anecdote about a recent near-incident my father (the crane operator) encountered.

    My father was nearing completion on a job for NASA in New Orleans, LA. He was flying handrails (for stairs) in the blind. His flagman radioed to him that the load was in position above the target, it was time to start lowering the load.

    The conversation with the flagman (over the radio) went something like this:

    Flagman: "Cable down"

    Dad: <Starts slowly cabling down...>

    Flagman: "More... more... more..."

    Dad: <Continues cabling down...>

    Flagman: "Cable down!"

    Dad: <Cables down a little bit more, then stops>

    Dad: [Realizing he's cabled down enough to put the load on the floor when it's going up on the 2nd floor stairs] "That should be enough!"

    Flagman: <Grabs on the tagline attached to the handrail and begins to pull.> 

    At this point the handrail releases and falls nearly 60' straight vertical before crashing into the ground, still with slack on the cable. I'll leave it to someone else to calculate the force involved with a ~100 lb. handrail falling 60' unimpeded. Suffice it to say that anyone caught by that handrail on the way down would likely no longer be among the living.

    You see, what the flagman failed to realize is that the handrail had become snagged on some other structures higher up. The flagman continued to tell the crane operator (my father) to lower the load, apparently thinking he was being ignored. At the same time, the operator continued to lower the load, thinking he was perhaps off on his estimates of how low the load needed to be placed.

    It wasn't until the operator looked over at the cable spool beside him and saw it completely slacked that he knew there was a serious issue -- the crane was no longer supporting the weight of the load! At the time he radioed the flagman to inform him of the situation, the flagman was tugging on the tagline to move the load.

    While the crew was lucky enough to escape tragedy this time, it could be only a matter of time before this situation ends much worse than it did!

    With the intuitive interface of HoistInsight, it will be VERY apparent to the operator that as he's cabling out his load is not descending. This very scenario could have been caught with only a couple feet of slack on the line versus 60'+ slack on the line -- potentially meaning the difference between someone making it home for dinner or perhaps not making it home at all.

  • A little background

    salokcin08/20/2014 at 04:21 0 comments

    My father has been a crane operator most of his years. He's worked jobs all around the country. He's seen some pretty amazing things and some pretty stupid things. One thing that consistently frustrates him is relying on unskilled flagmen for crane signaling -- visual and audible signaling alike.

    He originally approached me with this problem about a year ago. Of course I immediately designed a solution in my head, but with my own geographical relocation underway it was difficult to make much progress. Things have settled down for me now personally, so I've fired this project up again!

    My father has done the leg work within his crane company and with several crane manufacturing and service professionals to determine that this solution will solve a real world problem in the business of operating cranes.

    He has the cranes and jobs ready to test the solution when a hardened version is ready. This contest is just the extra motivation I needed to make that version a reality!


    I've been in software for a long time, but I've always tinkered on the firmware side. I've created several other projects that I seriously considered submitting to TheHackadayPrize, but I decided to focus on just one. Based on my experience I don't anticipate many technological hurdles in completing this project.

    I'd like to keep the price tag low on the final product so that crane owners and/or operators can't say no to using this solution. I feel so strongly about the safety aspects of this project that I want there to be no reason why every crane isn't equipped with this package!

  • Progress #1

    salokcin08/20/2014 at 03:52 0 comments

    So I had a proof of concept working several months ago and only recently started working on this project again (thanks THP!). I started back on the project using the same components I used previously, but I've since ordered and received a few new components. My immediate goal is to get the PoC back up and working with these new components.

    Nothing that big: My son ate (or more likely misplaced) some of my 900mhz duck antennas and U.FL to RP-SMA adapters. Sparkfun regurgitated those for me quickly. Also, I'm trying to shrink the ultimate packaging in parallel with the PoC, so I'm switching out my Arduino Mega's to the Arduino Pro Mini 328's. 

    The main problem I see with going from Arduino Mega to Arduino Pro Mini 328 is with the GPS interface and XBee module working in harmony. I was using the two hardware UART's on the Mega (one for GPS-to-Arduino and one for Arduino-to-XBee (or Arduino-to-PC)). One of these will now have to be a software UART -- but which? If any kind readers can advise I'd appreciate it. Just as a complete shot in the dark, I'd guess that the higher baud rate RF module should be a hardware UART while the 4800 baud GPS link should be software, but that's just a guess!

    I'll be posting the components list in the designated section of the project page, so please look there for the current, high-level list of components used.

View all 9 project logs

Enjoy this project?



tlankford01 wrote 09/11/2014 at 22:16 point
you can get NTRIP Client on Android. Without the RTK solutions though the GPS performance is only good for 1-3 meter lateral accuracy and 4-10 meters vertically. A 35 foot difference in where the load is and the ground is rather significant. If you would rather forgo the RTK then it would seem that proximity sensors such as lidar or sonar would be necessary. I think the project overall is a great idea and should be implememented not just by crane operators but other operators of heavy machinery as well.

  Are you sure? yes | no

salokcin wrote 08/20/2014 at 05:16 point
I'm trying to piece together a schematic tonight/tomorrow that will shed more light on how everything fits together. Stay tuned!

  Are you sure? yes | no

salokcin wrote 08/20/2014 at 04:06 point
Should I really bother keeping the GPS device in the 'Operator' module or just rely on GPS in the operator's mobile device? I feel more comfortable with embedding a GPS device in the 'Operator' module. Sure, it's more expensive, but then I can expect the same performance from both 'Operator' and 'Load' modules and not have to fuss with all different types of GPS hardware in the mobile devices.
I know, I know, the GPS hardware is abstracted in the mobile devices, but what if there are some mobile devices that have severely limited GPS hardware. What if some mobile devices make it harder to access GPS data? If the mobile app only knows about one piece of hardware (mine), it seems to simplify things.


  Are you sure? yes | no

PointyOintment wrote 08/23/2014 at 04:29 point
My phone's GPS is unreliable due to poor contact with the antennas. The crane operator's could be the same way. They also might want to use a tablet for the larger screen, and lots of tablets don't have GPS. Therefore, I say include your own. Also, if you decide to do RTK, I think you might need the same type of receiver at both locations, and, even if not, I know of no phones that support it.

Also, in case it didn't show up in your feed—I don't know if they've fixed it yet—I commented on a couple of your log entries.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates