The first post of this series begins to reveal, in backdrop, the interplay between several different design constraints and design paradigms for robots.
• The first of these interplays is between the design requirements for stationary floor-mounted robots versus those for mobile field-deployed robots. In the case of a stationary floor-mounted robot, the work comes to the robot, and the work environment is known; the tasks are repeatable and predictable. For a field-deployed robot, the robot needs to travel to the work, and the work environment is neither known, nor repeatable, nor predictable. These two qualitatively different work environments force qualitatively different economic expectations onto the resulting robot’s design. While this blog focuses on agricultural robots, it should be noted that what applies to ag-robots will apply equally to any field-deployed robot, whether the industry is farming, logging, mining, and/or construction.
• The second interplay is the perennial conflict that faces every design engineer between what can be built versus what should be built.
If your interest, dear reader, is in designing robots using existing technologies, then you can stop here.
Otherwise, the assertion being made in this post, is that the only way to make any real progress in agricultural robotics is first, stop trying to build more robots! Focus on the hardware side of ag-robot design and let the hardware tell you what it wants to be. Next, define what actuator technologies will need to be developed before such ag-robot hardware can be built. Finally, the engineering design community needs to focus some of its creative energy on developing those new technologies. For example, there is no electro-mechanical equivalent to biological muscle. If such an actuator already existed, our dream ag-robot would have been a reality years ago.
/***********************/
Starting with my first post on agricultural robotics back in 2011 and following on for the rest of that year’s posts, I tried to address in detail many of the design issues that would have to be tackled before one can make a useful robot replacement for a typical farmworker: “Agricultural Robotics, Design Challenges”.
In the process I coined a few “WID Rules” for robot design: “WID Rules for Robotics”.
• WID Rule: It makes no economic sense to replace a worker with a robot if that robot's total cost-of-ownership is not competitive with the total cost-of-labor for the worker it is going to replace.
• Corollary 1: When designing a robot, it is the worker you want to duplicate, not the worker’s task.
• Corollary 2: Regarding operation, service and maintenance, follow the K.I.S.S. principle (“Keep it simple, stupid!”), since the workers who will be responsible for these jobs in the future will be the same people that now operate, service and maintain the existing farm equipment.
The WID Rule implies that the only way robots will ever leave the engineering lab and move out to the farm field will be when they can finally compete economically with their minimum wage human counterparts. This basic cost of employment puts a severe cost constraint on any AI/robotic system intended for field deployment.
Corollary 1 implies that, for a robot to be a worthwhile investment for the farmer, it must be multipurpose. A farm tractor can be repurposed by just swapping out attachments; something that can be done in under an hour. While human labor, for example, can go straight from picking cauliflower to moving irrigation pipe without any pause for repurposing. Any piece of robotic equipment that cannot be repurposed, in short order, and in similar fashions, will always be a non-starter for any farmer.
Finally, Corollary 2 implies that a field-deployed robot needs to be modular. Its mechanical construction needs to be based on interchangeable subassemblies. And its computational architecture should come in the form of pre-programmed bricks or modules connected together using a single shared serial interface to form a system of distributed intelligence. This form of construction allows for easy manufacture, easy maintenance, and easy service. Programming, in any traditional sense, is not part of this paradigm. If one wants to change some functionality in a robot, just swap in a different module. The upside of this kind of construction is that this is the level of service, maintenance, and rebuild competency that already exists within the workforce currently employed in the industries of farming, construction, logging, and mining.
/***********************/
As a “worked example” of the point I’m trying to make: I touched again on the economics of field-deployed robots in a post on the now-defunct startup Willow Garage: “Willow Garage's Legacy, Blessing or Curse”. What was once a celebrity startup in the field of robotics disappeared into the dustbin of tech history in the space of a few years. The hubris of the developers behind Willow Garage was that they thought that by creating a standardized general-purpose robot, they could then divorce software development from the underlying hardware development. The desire seems to have been to turn robot design into a software developer’s game; and it is the ghost of this desire that still haunts the earth to this day in the form of ROS.
But reality will always bite back hard on any ill-conceived startup venture. It’s the hardware side of a robot's design that connects it to physical reality and, most importantly, to the economic reality of its intended arena of application. By divorcing software development from any underlying hardware development, Willow Garage also divorced itself, in its corporate thinking, from any consideration of the underlying economic factors involved in robot design such as the costs of manufacturing, operation, and maintenance. The foregone result was that the PR2 never became anything more than a vanity purchase for a few dozen financially well-endowed research and academic institutions.
/***********************/
At this point, I’m ready to assert that, in regards to stationary/floor-mounted robots, traditional software development modalities are sufficient. But when it comes to mobile field-deployed robots, some new way of programming needs to be articulated and implemented.
What this last, somewhat fuzzy, statement might mean in practical terms will be the subject of the remaining two parts of this post.
No comments:
Post a Comment