The Great Programming Fallacy

Continuing the discussion from The Myth: We Can/Should Make Building Robots Easy:

What I am calling “The Great Programming Fallacy” is based on a few, perhaps not-so-obvious things depending on the person and the situation.

  1. “Easy” is in the eye of the beholder.
  • In essence, what might be “easy” for you might not be that “easy” for me.
     
  1. “Programing” means different things to different people.
  • What do you consider “real” programming?
    • C++/C#?
    • Bare Metal assembly language?
    • Python?
    • Bloxter/Scratch/Squeak?
       
  • And what about the IDE?
    • Visual Studio Code over SSH?
    • Or maybe just an on-line make:code “blockly-like” coding site?
       
  1. Programming can have different objectives.
  • What is the definition of “success”?
  • Is there a specific requirement for the process or language used?
  • Is there a specific dependency on a particular piece of hardware?
  • Are there any other requirements or dependencies?
     
  1. In the case of robotics, what do you consider to be a “robot”?
  • A simple toy-like device with a tether?
  • A R/C version of the above that is hardware/firmware limited to a restricted range of actions based on the handler’s control?
  • A R/C and/or WiFi controlled device that is under the handler’s exclusive and strict control, but can be programmed to do other things in different situations?  (i.e. A GoPiGo being controlled as a FPV via a web page, but isn’t limited to that activity.)
  • A remotely controlled device capable of some independent action?  (i.e. Refusing to proceed if it detects an obstacle.)
  • A completely autonomous device that cannot be controlled or guided after being started?
  • An autonomous device capable of detecting and recognizing its surroundings and behaving based on that knowledge?
  • . . . and only if it can bring you a cold beer from the 'fridge on command?

 
The result of all this is that programming in general and robotics in particular is a vast, virtually unbounded domain of expertise.

As a consequence, I would like to postulate the following:

  1. A “robot” is a subjective thing.
  • A child’s “robot” toy may qualify as a “robot” to the child but would fail miserably as the subject of a Ph.D. thesis.
  • A remote controlled bomb robot or a device designed to work in extremely hazardous environments, (Chernobyl anyone?), could be considered a robot despite the fact that it is under the handler’s strict control and may not be capable of independent action.  This can be especially true in technically complex environments like defusing a bomb where it’s not reasonably possible to substitute programming for an experienced human’s judgement.
  • Is an autonomous robot a “robot” if it cannot function autonomously?  (i.e. Carl and Dave’s limited independent actions when un-docked.)
    * A device, no matter how simplistic, that can wander around and can detect/avoid obstacles?

 
2. “Programming” is also extremely subjective.

  • Your concept of programming may not be reasonable or valid for someone in a different situation.

 
3. The conjunction of these two indeterminate things is also indeterminate.

  • And no, L’Hopital’s Rule won’t help you here.  :wink:

What say ye?

2 Likes

For which we lament our:

But ROS may… The navigation-god Steve Macenski just released the ROS 2 Jazzy Nav2 navigation package with “Open Docking” that purports to enable your robot to use vision of April tags to find and engage its dock.

His byline is “Chief Navigator @ Open Navigation, LLC. But really I just break things in increasingly complex ways.”

1 Like