Over the course of my first year of blogging, I covered a number of the design issues that have to be addressed before any kind of useful ag-robot can be offered to the farming community.
Regarding issues of mechanical design, all but one of the challenges I could foresee were either solved or solvable engineering problems. The one remaining/missing piece of the puzzle, as far as the mechanical side of deployable robotics is concerned, is the invention/discovery of an electro-mechanical equivalent to biological muscle. Once this last hurdle is crossed, the world of field-deployable robotics will expand through the farming industry exponentially. The only concern, then, is: What will society do with the resultant unemployed semiskilled work force?
The programming side of field-deployed robotics is a different issue. Whatever methods are used to program field-deployed robots in the future must be something that the existing workforce already has the competency to do.
So just exactly what does it mean to program a field-deployed robot? And, what exactly is the competency level of the individuals you can already find working in the farm industry?
/***********************/
Regarding the question of workforce competency, when it comes to working with machinery, working with your hands, and getting dirty in the process, I’m afraid that many within the academic world have a prejudice against such individuals. I’ve found there is an ever-present attitude that, unless you have college degrees and are professionally successful, you can’t possibly be intelligent.
Thankfully, life gave me a wonderful lesson in this regard. Over the years I attended Humboldt State University earning my degrees in physics and math, I supported myself working in the woods as a logger. I was blessed with the good fortune to work with many individuals (equipment operators, mechanics, and rigging men) who, if you paid attention to the complexity of the tasks they performed, and their ability to think through solutions, were most certainly above average in intelligence and mechanical ability.
Here’s a nice video showing the rebuilding of the D8 Caterpillar tractor. Pay attention to the complexity of the tasks required for rebuilding such a machine. Hopefully this will give a good appreciation for the technical expertise that can be found within our modern skilled industrial workforce, “CAT D8R Dozer: Full Machine Rebuild”.
To suggest that the existing workforce, that can already be found within the farming industry, is incapable of dealing with the complexities of robot programming is a faulty assumption. The only challenge for the academic engineering community is to create a programming modality that can be adapted to the skill set already existing there.
/***********************/
Now, in order to answer the question, “What does it mean to program a field-deployed robot?” let’s start by asking the question, “How does one currently “program” a crew of field workers?” Field supervisors do not occupy their time creating lists of written instructions for each fieldworker to read and execute. Crew supervisors can assume that individual workers under their direction are already skilled at their assigned tasks. So, as supervisors, they only need to act as task managers, giving instructions verbally in a natural language setting.
This last observation suggests what the proper model for field-deployed robot programming should be. Rather than the compiled source code model of programming you find in languages such as C/C++, Java, Python, and etc., it should be more reminiscent of a scripting language expressed in verbal form.
Robots should arrive for work already programmed with the basic functionality they will need in order to complete the tasks expected of them. Additionally, their internal programming needs to include a learning mode that allows them to adjust their preloaded code to the ever-changing working conditions of the moment. Given this alternate paradigm for programming, the field supervisor “programmer” just continues to do their job exactly as they always have; giving verbal instructions to the deployed worker ag-bots.
Honestly, how can anyone within the engineering community imagine that ag-robot programming should/could be done by someone sitting with a laptop computer, out in the rain and mud or in the hot sun and dust, typing in code before downloading it to some robot? But over the years that I’ve tried to keep up with developments in agricultural robotics, this seems to be an implicit, but unrecognized, assumption underlying a lot of the ideas I see put forth.
/***********************/
The act of programming is really just the act of expressing a list of instructions that will delineate the operation of some intelligent processing system. Our typical association of programming with writing source code in a formal language format stems from the fact that the underlying processing system in these cases are digital micro-processors; with the objects manipulated being bits, bytes, and words of information. In the case of human field workers, though, the underlying processing entity is a person; while the objects being manipulated are tasks to be performed.
The “programming” design challenge, then, is to re-create in field-deployed robots, the same programming modalities that are currently employed with their human counterparts. Taking up this challenge will be the subject of part 4 in this series of posts.
No comments:
Post a Comment