Skip to content

Harvest Automation Grape Cart

Harvest Automation, Part 4                 

After trying and, sadly, failing to get our warehouse robot concept adopted by the industry,  Harvest Automation retreated to serving our existing agricultural customers.  Thirty or so nursery and greenhouse businesses across the US, plus a couple in foreign countries, needed spare parts and periodic servicing to keep their fleets of robots moving potted plants.

After the restructuring, a reduced Harvest was left with three employees and a room full of parts that hadn’t yet been assembled into robots.  Service contracts, sales of spare parts, and the occasional customer who wanted a new robot kept some revenue rolling into Harvest and the small number of employees kept costs low.  That made Harvest profitable—of course, at a much lower level than we had planned.

CEO Charlie Grinnell accumulated cash slowly and dreamed of another attempt to build a revolutionary product.  For some time Charlie had been talking with grape growers in California.  There he discovered an application that seemed ripe for robotization.

Grape vines, supported by horizontal wires, are grown in 660-foot-long rows. The aisle between the rows may include weeds, ruts, and rocks. [Photo credit: Harvest Automation]

Harvesting Grapes

The possibility of designing a robot for an agricultural application always depends critically on the details of the task to be done.  Grapes are no exception.  So, some details:  Grapes are grown in long rows.  Wires, supported by regularly spaced poles or trellises, stretch along the row and grapes vines are trained to use the wires for support.   Most grapes are intended for wine or grape juice.  That usage enables the grapes to be harvested mechanically.  Tall, odd-looking machines straddle the vines and employ vibrating elements to shake grapes into a collector mechanism.  Inevitably, the machines bruise and damage some of the fruit, but it matters little as these grapes are destined for the crusher.

Two workers pick grapes into white tubs on a wheelbarrow-like pushcart. [Photo credit: Harvest Automation]
When the picking cart is full, the worker pushes it to the end of the row where the pack station is located. [Photo credit: Harvest Automation]
A “pack station” is positioned at the end of the row. There a worker weighs and packages the bunches of grapes into cartons or bags. [Photo credit: Harvest Automation]
After the grapes have been packed into bags, they are placed in boxes. Periodically a truck drives down the access road and collects the boxes. [Photo credit: Harvest Automation]

But mechanical harvesting isn’t suitable for “table grapes.”  These grapes are intended to be sold in bunches to consumers in grocery stores.  Because they must look good, table grapes are picked by hand.  Something like 95% of table grapes consumed in the US are grown in California.  Most growers there follow a standard—rows are 660 feet long with an access road on either end.  In a typical harvesting operation, workers push a small wheeled, tub-holding cart along the row picking grapes into the tubs.  When the tubs are full, the worker pushes the cart down the row to the access road.  There another worker weighs and packs grapes from the tubs into the bags they’ll be sold in at the grocery store.  The spot where this happens is called the “pack station.”  A truck periodically drives along the road picking up the packed grapes to take to cold storage.

A major inefficiency in this operation is the need for pickers to frequently push heavy carts to the end of the long row.  Wouldn’t it make more sense if a robot carried the grapes?  With no time wasted walking, growers could harvest the rows more quickly.  And, since pickers are paid only for the grapes collected from the pack station—not for the time they spend walking—pickers could also earn money faster.  All that’s needed is an appropriate robot.

Min versus Max Technology

Harvest Automation was not alone is noticing the table grape transport opportunity.  Another company called Burro AI was already developing a solution when we began work on our robot.  But the two companies took opposing approaches to the problem.  

A minimalist design philosophy always attracts me.  When addressing a problem I aim to build the simplest, dumbest mechanism that could possibly solve exactly that problem.  (See Dancing with Roomba, Chapter Two, ‘Tis a Gift to be Simple.)  This lets me design and build less stuff than would be needed were I to take a more expansive view of the problem.  A low-cost, minimal solution means that potential customers are more likely to deem the product affordable.  This reduces the barrier to entry and is especially helpful if the product is the first of its kind.  Customers can’t be sure that such a product will work for them, so keeping the cost of the qualifying experiment low makes them more likely to take a chance.  

The competing maximalist philosophy argues that functionality is the key.  With enough functionality the product will be irresistible to customers.  The product may end up being relatively expensive but the many things it can do will make it worth the price.  A high price can be a positive when pitching the business to investors.  For several reasons, venture capitalists generally see low volume, high priced products as being easier for a startup to pull off compared to high-volume, low-priced ones.

The Harvest cart had exactly one function:  It carried tubs along grape rows.  When it detected a large obstruction within the row, it stopped.  The robot assumed that the obstruction was either the picker or the packer.  When the picker finished picking grapes into the tubs of the waiting robot, he or she pressed a button to send the robot to the end of the row.  When the packer finished removing tubs from the robot, he or she pressed a button to send the robot back to the picker.  

The limited scope of the robot led to low cost.  All that was needed to enable row-following was a few cheap sonar sensors—the sort of sensors you may find mounted on the rear bumper of your car to detect potential collisions.  The Harvest cart’s user interface was also minimalist, consisting of a couple of push buttons. Because there was so little to it, workers could learn to use the robot with essentially no training.  

Burro’s cart was more versatile, more complex, and several times more expensive.  Burro used a camera and AI to plan its way along the grape row.  It also employed RTK GPS (a very high accuracy form of GPS).  This let the robot follow complicated paths.  When it reached the end of the row, the cart could turn down the access road if necessary.  It could carry a large payload (about five times as much as the Harvest cart).  Where Harvest’s cart serviced just one row, Burro could collect the grapes picked by workers in several rows.  (Actually, because the cost of the Burro’s robot was so high, it needed to service several rows in order to make sense economically.)  A touch screen mounted on the Burro robot enabled workers to program the path they wanted the robot to follow.

Harvest took in no venture capital and spent less than $1 million developing our grape cart.  Burro has had several rounds of investment and taken in around $50 million.  (To be fair, Burro has developed more than just a grape cart.)

Design and Test

Harvest was at a geographical disadvantage.  Our customers were all in California’s Southern San Joaquin Valley; we were ~3000 miles away in the Boston area.  It was challenging to replicate the vineyard environment as we needed to do in order to refine our sensors and algorithms.  Also, seasonal snow and cold shortened our available testing time.  But we believed in our product, and we worked diligently to understand the needs of our customers and to make the robot work effectively.  

The last iteration of the Harvest Grape Cart had four-wheel drive, held four grape tubs, and used eight sonar sensors. The top cross piece held the buttons workers used to control the robot. [Photo credit: Harvest Automation]

We came up with a design that had four driven wheels mounted on a low chassis.  Inside the chassis were the wheel motors, some of the electronics, and a battery that enabled the robot to operate for a full shift and then recharge overnight.  Above the chassis were a lower and an upper tray.  Together they held four grape tubs, the same number of tubs the workers’ manual carts could hold.  Above the trays was a long cross piece.  On the ends were push buttons that enabled workers to stop the robot or send it down the aisle.  Sonar sensors mounted in various locations provided navigation and obstacle avoidance.   The robot also sported a meter showing how much battery charge remained and a connector that enabled recharging.

That’s all there was.  The Harvest Grape Cart did not have a camera, or GPS, or a display screen, or machine learning, or the ability to be user-programmed.  It just drove up and down the aisle carrying grapes.

Even though our robot was the essence of simplicity, building it was a struggle.  Our development program operated on a shoestring.   Only about half-a-dozen people worked on the project, some of them part time.  Still, we managed to implement a robust device. 

Late in the growing season we completed a build of more than a dozen copies of our robot.  Then  we shipped them off to two large table grape producers in California for trials.  Some of us flew to the test sites to help customers get set up.  Then over the course of about a month, customers used our robots to assist the harvest.  At least one customer kept careful logs.

In the end our results were mixed.  The customer who gathered careful data found a significant boost in worker productivity and the workers loved the machines to the point of complaining when there were not enough for everyone on the crew.  A downside the grower struggled with was that the transport of the robots to and from the fields was a logistical challenge, that added to the overall cost of our solution.   The second customer had no data to share, but was convinced that the robots didn’t help.  Worker productivity was no better with the robots than without.      

Bottom Line

The customer who saw a productivity boost was concerned about the cost of transportation logistics and declined to adopt our solution.  They had made a significant investment in Burro’s machines—that may have contributed to their decision.  

That one customer found no gain in productivity was a disappointing shock, but we didn’t want to give up. There were many reasons why the robots might not have performed as we expected:  Maybe workers realized that the robots enabled them to make the same money while expending less effort.  Maybe managers and workers used the robots in a less efficient way than we had intended.  The robots offered the greatest benefit at peak season when workers have trouble keeping up with the abundance of grapes—but, unhappily, we weren’t able to deliver robots until the waning part of the season.  Despite our rigorous attempts, we weren’t able to discover the reason for the system’s poor performance.

Unfortunately, our resources were almost completely depleted at that point, so the grape cart project had to end.  Thus, Harvest did not manage to revolutionize table grape harvesting.  We were unsure whether Burro’s approach worked significantly better.  Our customer who had tried the Burro robots told us about a social problem that impacted Burro’s method.  

Usually, a crew of three people pick and pack the grapes.  The crew all know and trust each other, often they are members of the same family.  The trio is paid for the grapes they deliver and it’s up to them to distribute the money among themselves.  They can do this equitably because they know each other’s abilities.

Compared to Harvest, Burro’s robots were bigger and carried heavier loads.  Their higher cost meant that they made economic sense only if they serviced more than just a single three-person team.  A ratio of eight workers to one robot worked out best according to Burro’s spreadsheet. 

But that meant that the teammates didn’t necessarily all know and trust each other.  Were they all working equally hard and deserving of the same pay or, was someone bringing down the wages of the group by slacking off?  According to our customer, that bit of social awkwardness made workers uncomfortable with Burro’s bigger-is-better approach.

Whether Burro overcame that problem or not, it illuminates a hard fact about robots: Everything counts.  It’s not just the technical problems that we technologists so enthusiastically focus on.  Poorly understood subtleties of the task domain often frustrate roboticists’ best laid plans.  Complicated interactions social, environmental, business, and technical must converge for the robot to be successful.  That remains a rare occurrence.