Building Robotic Communities

At our company, we’ve been thinking a lot about building communities of robots, robotics devices, robotic control systems and whatever other related systems and devices make sense. Obviously, the first question to be answered is, what do we mean by “communities” and why is it worth talking about.

To begin to answer the question we first need to be clear about how, within our context, we define a community. Our analogy relies on an admittedly idealistic view of community when viewed in a human context. Our definition of a community might be:

• A community is a group of individuals living, working and/or playing together in a common physical location or now days, as part of a common online community. Each of the individuals in the community are their own, autonomous entity. Gender, religion, orientation, background, income status or any other personal attribute of community members should all be irrelevant in determining the rights, respect and allowed participation of each member in the community.
• Each member of the community should, except in specific circumstances (e.g., behavior harmful to other community members or to the community as a whole), be able to make their own decisions for how to live their day-to-day lives.
• That said, all community members should cooperate in pursuing the community’s common goals and generally work together for the good of the community.
• There can and most often will be members of the community that are considered leaders and who will make decisions for the community at large. But the individual members of the community will still be free to decide for themselves how to respond to those decisions and about what to generally do with their lives.
• There must be policing which includes a set of consequences that come from individuals making decisions that the community decides are unacceptable for whatever reason.
• But the ultimate decision about what action will be taken by an individual at any given time is still left up to that individual unless the community determines it is necessary to rescind that right for them.

Okay, yes that’s all pretty “Kumbaya” when thought about in a human context. But we’ve been thinking about what it might look like for an amorphous group of automated or robotic devices to interact as members of a community built on these principles.

Think about a situation where you might have some sort of existing PLC installation controlled by its set of potential input and output signals and you’d like for it to safely and productively interact with a group of modern robots. Having them exist together using our “ideal community” as the model for how they interact with each other might make for an interesting way to view that interaction.

So, what would that look like?

One of the key ideas here is, the PLC installation and the group of robots all have roles they’re designed to fill. Each presumably has whatever intelligence or programming it takes to fulfill its role safely and productively. For the most part, they need to be left alone to play their roles as they’re designed to do.

But how does it work when you want them to interact with each other to achieve a common goal. This is where the concept of a community leader can come into play. Some voice in the picture must speak for the community as its leader. The leader must:

• Know the common goals of the community,
• Know how to communicate with all the community members,
• Know what the overall rules need to be for the interaction to work safely and productively and,
• Have some means to enforce those rules if needs be.

The scope of a community leader’s authority can be completely arbitrary, depending on the specific roles being filled and the overall goals of the community. It may be that multiple layers of authority are needed, leaving a situation where you could have a community leader with authority over nothing but a group of other community leaders or any mixture of the above. This is what we mean by amorphous groups of devices.

One of the main requirements for the community leader is that they know how to communicate with all the community members. Consider an example where you need to receive constant updates from a LIDAR sensor while, at the same time interpreting and analyzing that data and using it in combination with the output gathered simultaneously from a camera which is sent to a cloud service to perform object-recognition on its images.

It would be up to the community leader to understand how to receive and interpret the data output from all those devices and services and to use that information to navigate or to fulfill whatever the ultimate goal is for the community. This is an example of the community leadership concept being applied to a community of devices on a single robot.

For a macro view, we’ll look at a somewhat fanciful (for now…) example which hopefully, will at least serve to illustrate the idea.

Say you have a standard automated car wash, and somebody designs a modern robotic system that would control groups of ‘bots capable of driving the cars out of the washing area and performing post-washing detail work like vacuuming and polishing the interiors of the cars.

If you could form a community built of the robots and the automated car wash system, a leader for that community would be paying attention to things like:

• Notifying the detailing 'bots when a car is ready for pickup at the washing area,
• Monitoring the progress of each detailing 'bot on its current car,
• Delaying the entrance of cars into the car wash if the detailing 'bots are getting overloaded,
• Monitoring the current status of the car washer as well as each of the detailing 'bots and shutting down any members that show anomalous behavior,
• Etc...

The leader knows what it takes for the community as a whole to function smoothly. It must also know what’s going on with the members and how to cope with issues that might arise from any of them at any time. It has no interest in what it takes to wash a car or to vacuum and polish the interior of a car.

Now, let’s expand our fantasy a little further. Let’s pretend there’s a fleet of autonomous cars that wants to join the community. The fleet is already acting as its own community and has its own leader. The fleet’s leader is paying attention to things like:

• Where are the cars scheduled to go today and who are their riders?
• What is the predicted trip duration for each car?
• What is the current status of each car?
• What is the maintenance schedule for each car?

Obviously, part of the scheduled maintenance for the cars would be getting them cleaned. Answer, have the fleet community interact with the car wash community. Now, pretend there are a number of automotive fleet communities that need to have their vehicles cleaned and, maybe it’s a chain of car washes. The leader for this “macro-community” would be paying attention to:

• How many cars can each of the car washes process per hour?
• How many fleet cars are scheduled for a wash on a given day?
• What is the current status of each of the car washes?
• Etc., etc., etc...

Hopefully the idea is becoming clear. From the communities of devices on the individual car-detailing ‘bots to the community of car washes with its automotive fleet customers, the communities all have the same essential structure. Each has its own set of community members with their own common goals governed by their own community leaders.

This idea of community is one of the most important drivers behind the design of our robotic control software framework.