RE:Fooderackacycle
Eric Hunting
Yes, this is what I was getting at. Looking at how the functional tasks of food preparation can be broken down into discrete task systems and then dynamically orchestrating them as a collective to carry out recipes.
There's a new robotics/automation paradigm emerging at present that I don't often see people in the formal field of robotics talking about but which I often see touched on in the Open Manufacturing community when we speculate on the future of desktop manufacturing--in this forum particularly; the machine shop as robot collective. The Santa Claus Machine. We look at these desktop machine tools not simply as tools but like the sub-systems in a larger personal computer--a matter computer. And that's because here we're really thinking about the successor to the current dominant industrial automation paradigm; the Jacquard Loom. The rest of the field of robotics seems more focused on the question of autonomy, thinking about the robot as self-contained self-mobile animal, macro-organism, or android. And this frustrates me a bit. It's narrow and tends to result in a predominance of rather hermetic software environments because robotics tends to think about control and intelligence in the old fashioned context of a self-contained on-board 'brain'. We're still on the level of IBM/360 Job Control Language. Everything is Fourth-like. Simplistic threaded interpreted scripting, which isn't bad in itself but rather in the black-box models of control systems it lends itself to. This hampers the development of truly sophisticated systems. There's still nothing in robotics we can call an operating system. Sure, there are things like ROS that call themselves an operating system, but it's not really close to being on the same level as the operating systems a common personal computer uses.
The Fooderackacycle idea is intended to realize a very accessible sort of automated 'machine shop.' The kitchen is a kind of workshop that we all have and work with. So we have a frame or reference and range of activity everyone can relate to. It's also potentially cheaper to work with than even what current desktop manufacturing works with. The materials are all cheap and ubiquitous and the processes don't need high precision. Kitchens already have lots of appliances that can potentially be hacked. It's very well suited to playful tinkering.
I think the 'recipe' is an extremely powerful information metaphor. I started using that term a long time ago to characterize the new form of information that we have been developing in DIY, Maker, Open Manufacturing culture. This is what the form of the information we see on Makezine or Instructibles is; recipes. It's more than 'plans' because it doesn't just present a design. It's not just instructions for operating a particular machine. It describes a whole production process including fabrication, assembly, and specialized technique and is rich in media diversity.
Recipes represent a Taylorization methodology (named for Frederick Taylor, the father of 'scientific management'--and the consequential invention of the Pointy Haired Boss…) that links design to production. And this is very significant in the context of computing for automation. Currently, industrial automation is not dynamic and so it can't deal in on-demand production very well. Programing of factory automation is low-level, crude, non-holistic. Every 'step' in production is an independently programmed workstation. There's no true whole system architecture--just a model of the production line--and no whole data model for the design and production process of a product. No recipes. We characterize 'smartness' in industrial automation in terms of production flexibility and right now that's limited to some forms of optional in-line component substitution in late-stage assembly and the relative speed and ease of 'retooling'; physical and software reconfiguration for fixed-run production. The production system that dynamically routes variable product between adaptive workstations rather than along a static production line doesn't yet exist--and yet we here see it pretty clearly on the horizon.
I think cooking gives us an interesting way to explore that concept. You have this very easy to understand production model with a simple class hierarchy. There are the discrete food handling tasks, the recipe, and the meal/banquet. And you have a lot of 'short order cook' substitution. You have to deal with a lot of on-demand customization. And recipes are very social creative things. People are always customizing them and sharing them. So, as a form of data, they have to be very human-intelligible and portable while people's kitchens often differ greatly in a topological sense. So recipes have to be a higher level of process abstraction that can be interpreted to suit low level control within the specific configuration of any topological variation of a Fooderackacycle. This is pretty much what SKDB is exploring. And then you have to think about a user interface that deals with all this on the user-comprehension level of a home appliance and works with the existing personal computing environments--which brings us to that proposition of a general operating system for automation. It could be a fun way to get into some very deep information and automation science.
Right now I think robotics is chasing some dead-ends. The cutting edge in the field is focused on the android paradigm and this idea that the future of automation is predominately about artificial intelligence, but is that really viable in a general automation sense? Is there really much of a practical role for the android other than a social role? There seems to be this old idea that we go from static production lines to artificial humans crafting in a machine shop. This is how we see the robot typically in SciFi. The universal machine with a big collection of tool accessories if not adapted to human hand-tools--like a carpenter standing at a workbench with all his tools laid out neatly around him. That seems like a really hard thing to make practical because the human way of doing things isn't automatically efficient/better so making a machine to mimic human hand-craft doesn't seem to make a lot of sense. It's the long way around. And if we go the route of the more automated machine shop, where the tools do the processing themselves for sake of better performance with simpler technology, the android becomes redundant because it's reduced to a really over-elaborate transport system between workstations. You're not going that route. You'll constrain the topology and make something simpler. it makes more sense to think of the whole production facility as the robot--or more accurately as a matter processing environment. I think there are a lot of potential robotics paradigms that aren't yet explored because we focus too much on a few quaint concepts of what a robot is supposed to be. Metal men and plastic pets. There's probably a whole lot more than that.
Eric Hunting
erich...@gmail.com
> jude <flexca...@gmail.com> Dec 31 03:00PM -0600
>
> Eric,
>
> I think you're on to something here. I've been interested in this type of
> thing as well. I don't think the technological "ingredients" for it existed
> until now (cue groans).
>
> I think on the hardware side you've got something. On the software side
> I've got a couple suggestions a few that are similar to what I've been
> working on. Basically it's program that lets you create a timeline of
> events that would allow you to trigger functions and handle situations in
> that timeline or even branch into other timelines.
>
> In this case I would suggest that you break the roles of each robot into a
> single (but not limited to) task or function. For scrambled eggs, you'd
> have one who's sole job it was to pick up an egg and break it over a
> certain spot. You'd have another who's job it was to beat the eggs. If you
> keep the parts separate but allow them to be integrated (like plug ins) you
> could break out the work and allow others to add new compatible parts as
> you go. If those used a standard compatible protocol then you would only
> need to string them together.
>
> 10 Request an egg - Egg breaker machine
> 20 Break the egg - Egg breaker machine
> 30 Beat the egg - Egg beater machine
> 40 Fry the egg - Fry master 2000 (accepts "Scrambled eggs instruction")
> 50 etc... and finally
> 100 Eat the egg - you
>
> The timeline / sequence thing would handle all the events or exceptions.
> For example, if there are no eggs, if the shell went into the mix, if it
> was successful, if the egg beater engine is not powerful enough or the
> recipe needs to pause for human interaction. And the important part to this
> timeline software (or any) is to allow it to branch into another sequence
> of functions or events.
>
> In the case of food preparation the high level programs have already been
> written in the form of recipes.
>
> Another thing to consider is that some people would be opposed to
> completely automated / unsupervised food prep. But I think those can be
> addressed. Recently, there have come about sensors that can tell if a food
> is spoiled, http://www.sciencedaily.com/releases/2011/04/110413092837.htm.
>
> Putting myself in the shoes of a potential home or restaurant owner I would
> be interested if it came in different sizes as well such as microwave,
> stove, refrigerator and / or even be integrated into them. I would want it
> to be easy to clean, easy to use and come with adjustable settings. I'm
> thinking of something where I'd only give it the food it needs or any help
> it needs along the way. As long as I'm wishing it would clean itself
> instantly .