HoistInsight - A brain for your crane

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!

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.

Licenses

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.

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!

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!

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!

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.

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.

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!

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.