John Deere Tractors and the Right-to-Repair

First, for anyone within the robotics community unfamiliar with this controversy, before reading further, they should enter this section’s title into their favorite search engine and start reading through the information found there. While at this point in time, this Right-to-Repair controversy is only affecting farmers who own John Deere equipment, it is only going to become more acute as robots leave the engineering lab and factory floor and move out into the field.

As a note, while my blog writing focuses on agricultural robotics, and I will be using the term farmer exclusively, the issues discussed here will be common to any/all field-deployed robots, whether that field of operation be farming, logging, mining and/or construction.

Sophisticated electronic systems are now ubiquitous in the cabs of modern farm equipment. That by itself is not the problem. The problem is that equipment manufacturers like John Deere have increasingly integrated the mechanical functioning of their machines with the internal control electronics. Now even a minor mechanical repair requires a factory technician to come out and reset the on-board computer system. For the farmer this turns a two hour and $50 repair job into one dragging out a day or two and costing another $500 to $1000 extra. You can appreciate why the farmers are upset about this situation. And it gets worse. The penalty for not calling in the factory technician to properly reset electronics is that the farm equipment won’t run; effectively John Deere is holding a farmer’s tractor hostage.

What we are seeing played out with the Right-to-Repair controversy is a clash of two incompatible economic models, along with the clash of two different design philosophies. Specifically:

• Every single engineer I’ve encountered and interacted with, who was also involved with robotics, sees a robot as primarily a computational system with mechanical subsystems tacked on to the periphery. But for the farmer, a robot is a mechanical system that has an embedded computer system for its operation.

• Unfortunately, in the high-tech world, engineers see a robot as a design challenge. The more complex the solutions, the more job satisfaction your typical engineer will get. While for the farmer, simplicity and reliability in construction, operation and maintenance is what is of paramount importance.

• For equipment manufacturers, economically speaking, it is to their advantage if they can turn an equipment purchase into an ongoing income stream. This is usually accomplished by some form of service contract servitude.

• For the farmer, the economic situation is the exact contradiction of this. The farmer needs to be as free as possible from any corporate constraints so that they can make proper use of their equipment; use that depends unforgivingly on the ever-changing and unpredictable day-to-day conditions that mother nature and the economy throw at them. For the farmer, with the loss of control over their own equipment, they effectively have lost control over their own farming operation. Less reliance on the original equipment manufacturer and the greater ability to rely on their own resources is the economic model the farmer wants and needs.

/******************/

Farming is an endeavor which, in exchange for uncertain weather and market conditions, the offerings in return are nothing but headaches, along with very low, to sometimes losing, profit margins. The only way for a farmer to function in any kind of economically sustainable fashion is to maintain very tight control over expenses and operations. An engineer in Silicon Valley might not think about it this way, but for the farmer, this Right-to-Repair issue becomes yet another uncontrolled factor, like the weather, that can make or break them economically.

I find myself almost taking it personal sometimes when I encounter the casualness which many within the engineering community approach this problem of not only Right-to-Repair, but most importantly Ability-to-Repair; an ability that for a farmer can be the difference between keeping the family farming operation running and having to sell out to one of the bigger corporate farms.

The way the robotics industry functions now, what is best economically for the engineering designers and manufacturers creating and producing the next generation of field-deployed robots, has become incompatible with the economic realities of what farmers, loggers, miners and construction site foreman need.

There is no solution to this conflict that will make everyone happy. So, each member of the community of engineers devoted to robot design will have to individually make their decision as to which side of this conflict they want to stand on. Will they put their creative effort into making a product that works for the farmer? Or will they devote their creative energies to product design that enables a high-tech corporate domination of the field-deployed robot market?

/******************/

A classic historical analogy was the original IBM PC against Apple and others in the marketplace. While its competitors maintained closed and proprietary designs, the IBM PC’s architecture was open; as such, it provided a universal platform that third-party developers could build their own applications upon. And so, it became the go-to platform for anyone wanting to use a PC as an intelligent controller for whatever their product idea might be. As consumer demand went up, competition in the PC market kicked into gear. Because the IBM PC’s architecture was open, it was easy for third parties to copy it. As the market became big enough, manufacturing went offshore; prices dropped, ultimately forcing IBM out of the PC marketplace.

In the end, what was best for the consumer turned out to be a losing proposition for IBM. And although IBM ultimately lost in the marketplace, the open architecture it had introduced is the reason home and desktop PCs are so ubiquitous today.

This historical outcome will repeat again for field-deployed robots, provided that some manufacturer makes the bold creative step to give the world a non-proprietary, open and modular architecture that would be simple in construction, reliable in use, and easily manufactured, serviced and repaired. But most importantly, an open architecture that would allow third party, aftermarket additions, modifications and enhancements to be created; thus, becoming a channel for the creative efforts of a much larger field of entrepreneurs. Whichever equipment manufacturer becomes the first to do this, might ultimately lose in the marketplace, but their creative efforts will survive into posterity

/******************/

(*) As a hardware designer, it’s impossible for me to upgrade a part value or an IC specification remotely over the Internet. So as a hardware designer, when my creative work is done, it’s done. The only way to change or upgrade my work is via a product-wide recall costing my corporate employer a major financial hit. But software lends itself to remote upgrades. And because it’s easy to do, the temptation to do so becomes overwhelming. Therefore, software development often devolves from a creative effort to merely a rent-seeking endeavor, turning product purchasers into ongoing income streams via the offer of future software upgrades with the co-commitment mechanism of service contract servitude.

One of the occupational fallouts that will come with a modular form of construction will be that software developers will now be in the same boat that hardware developers currently are; that is, they will have to get it right the first time since, once their coding leaves the factory, they can’t access it again to fix any of the mistakes they made. If the reader senses a bit of Schadenfreude in this attitude, well, they would be correct.

Widjets is Running Again, So what’s next?

For the last three months, life’s complications and health concerns have kept me from getting any writing done. My hope was to be able to post at least once a week. I’ll be trying better as time goes forward.

But despite not getting any writing done, progress on the hardware side has gone forward satisfactorily. All of my old Widjets hardware has been moved from boxes on the shelf and is up and running. I’ve installed new versions of LabVIEW and my Verilog EDA tools.

I’ve produced two new boards for the project; a 4-port hub and an 8-port hub as expansions for my WSB serial bus. I was also able to rework an old stepper motor drive card using the new programming format, so I now have a collection of dual H-bridge driver cards.

The original control board hardware I’m working with dates back to 2009 and used Lattice-Semi XP FPGA parts. These are now obsolete and no longer obtainable, so I also updated the control box design targeting a current FPGA part, generated new revised schematics, and even completed the artwork for a new PCB.

Everything was ready to start building upon, but what’s the next direction to go?

Ultimately the purpose of building any further hardware was for it to act as a showcase for what I’ve come to call the Widjets-concept or the wordier Widjets-design-paradigm; that is, a computational architecture based on a system of distributed processing, built up from task-specific preprogrammed modules, connected together by a common serial interface, and programmable in a verbal manner by users not necessarily computer literate.

As a way to showcase this alternate paradigm for robot construction, I thought that reproducing the functionality of the robots used in the NASA Swarmathon competition would be the best way to go about this. But as I went through the details of such a design effort, I realized I was not going to have the financial resources to finish. Further, I can’t see any way, within my financial resources, that I will be able to build any kind of robot, which would be sufficiently complicated in its functionality, to take advantage of this alternate paradigm of distributed processing. At this point, further progress seems to have come to an end; which has forced me to think about what exactly I’m trying to do with this Widjets-concept.

At this point, I must confess, my ultimate goal is to write a science fiction story. And the underlying motivation for exploring the possibility of my proposed alternate robot design paradigm was to prove to myself that it would actually work in practice.

Though I will not be able to finish the actual building of a system of robots based on this concept, I’ve done enough prototype development so far that I am entirely confident that such a system would work in practice. The next blog post will be exploring how this works out.

But for now, it appears that further work on the Widjets hardware has come to its end. I’m not saying that I will never get back to it again – just not until I win the lottery, or something, and have the financial resources to do so