DEV Community: Gunjan Giri

ROS – Robot Operating System

Gunjan Giri — Fri, 10 Jun 2022 14:14:25 +0000

What is ROS?

ROS in a nutshell…

As the full name of Robot Operating System suggests, ROS is an operating system for robots. In the same way as operating systems for PCs, servers or standalone devices, ROS is a full operating system for service robotics.

ROS is in fact a meta-operating system, something between an operating system and middleware. It is a set of free open source software libraries that help its users develop robotics applications.

It provides a range of features standard to an operating system:

Hardware abstraction
Contention management
Process management

ROS also provides high-level functionality:

Asynchronous calls
Synchronous calls
Centralized database of data
Robot configuration system

The benefit of an OS for robots

Before robot operating systems, every robot designer and robotics researcher would spend considerable amounts of time designing the embedded software within a robot, as well as the hardware itself. This required skills in mechanical engineering, electronics and embedded programming. Typically, the programs engineered in this way were more akin to embedded programming, similar to electronics, than they were to robotics in the strictest sense, such as we might encounter it nowadays in service robotics. There was considerable re-use of programs, as they were strongly linked to the underlying hardware.

The main idea of a robotics OS is to avoid continuously reinventing the wheel, and to offer standardised functionalities performing hardware abstraction, just like a conventional OS for PCs, hence the analogous name.

ROS is a robotics project facilitator. Researchers or engineers in R&D divisions that use ROS no longer spend time creating a new ecosystem for each new robotics project. This also represents a financial gain.

ROS has an positive impact on R&D by reducing costs and the “time to market”. For structures or departments which goal is launching a new prototype quickly, or who need to reduce a technological gap, it becomes quite attractive.

Another benefit of robot operating systems such as ROS is that of combining expertise from different disciplines. In fact, designing and programming a robot means:

Managing the hardware by writing drivers
Managing memory and processes
Managing concurrency, parallelism and data merging
Providing abstract reasoning algorithms, making great use of artificial intelligence.

Robotics therefore requires very different skills sets, typically beyond the range of a single individual.

ROS lowers the technical level required to work on robotics projects. This can make it easier for many companies to get started in robotics, or to design complex systems more quickly.

The history of ROS

Many robot frameworks exist, produced for a specific reason, for prototyping purposes. ROS was intended to be more general-purpose, although its designers do not believe it to be the ultimate OS able to do everything.

Before 2007, the year of ROS release, robotics engineers did not have a standard embedded software architecture. That’s why ROS is a major leap forward.

ROS is developed and maintained by a Californian company, Willow Garage, formed in 2006 by Scott Hassan, one of Google’s first employees who was involved in the development of search engine technology and who was also behind Yahoo! Groups (eGroups, in fact, which became Yahoo! Groups). The President and CEO of Willow Garage is Steeve Cousins, previously at IBM.

Willow Garage is a private company that maintains close links with Stanford University, which is not far from Willow Garage (in Palo Alto, California).

Willow Garage describes itself as a research laboratory and technology incubator for personal robotics, focused on research more than on profits (at the outset, at least).

Willow Garage develops both software with ROS and hardware with their PR2 and TurtleBot robots. Everything produced is open source (BSD licences). Their idea is that if we want to see robots reach our homes, then research needs to be accelerated by providing solid hardware and software bases that are open source.

It would appear that Willow Garage wishes to build the robotics community rather than robotics in and of itself. Interviewed by business magazine L’Expansion, Scott Hassan said that his objectives are the same as those of Irobot, but that the strategy to achieve them is different.

Programming with ROS

ROS is language-independent. At this time, three main libraries have been defined for ROS, making it possible to program ROS in Python, Lisp or C++. In addition to these three libraries, two experimental libraries are offered, making it possible to program ROS in Java or Lua.

ROS-compatible robots

The list of ROS-compatible robots grows constantly. For a full list, visit the Willow Garage website at http://www.ros.org/wiki/Robots

However, it is worth mentioning the best-known, namely NAO, Lego Mindstorms NXT, IRobot Roomba, TurtleBot and last but definitely not least, Willow Garage’s iconic PR2.

Basic notions in ROS

The basic principle of a robot operating system is to run a great number of executables in parallel that need to be able to exchange data synchronously or asynchronously. For example, a robotics OS needs to query robot sensors at a set frequency (ultrasound or infra-red distance sensor, pressure sensor, temperature sensor, gyroscope, accelerometer, cameras, microphone, etc.), retrieve this data, process it (carry out what is known as a data merge), pass it to processing algorithms (speech processing, artificial vision, SLAM – simultaneous localisation and mapping, etc.) and lastly control the motors in return. This whole process is carried out continuously and in parallel. Moreover, the robotics OS needs to manage contention to ensure efficient access to robot resources.

The concepts brought together in ROS under the name of “ROS Computation Graph”, enabling these objectives to be reached, are described below. These are concepts used by the system as it is running, whereas the ROS File System described in the previous section is a static concept.

Nodes

ROS addresses this entire issue using some simple basic notions. The first of these is the notion of the node.

In ROS, a node is an instance of an executable. A node may equate to a sensor, motor, processing or monitoring algorithm, and so on. Every node that starts running declares itself to the Master. This comes back to the microkernel architecture, whereby each resource is an independent node.

Thanks to the nodes system, basic functions can be standardized, and technological building blocks can be quickly developed and easily reused, modified, or improved.

Master

The Master is a node declaration and registration service, which makes it possible for nodes to find each other and exchange data. The Master is implemented via XMLRPC.

The Master includes a heavily-used component called the Parameter Server, also implemented in the form of XMLRPC, and which is, as the name implies, a kind of centralised database within which nodes can store data and, in so doing, share system-wide parameters.

Topics

Data is exchanged asynchronously by means of a topic and synchronously via a service.

A topic is a data transport system based on a subscribe/publish system. One or more nodes are able to publish data to a topic, and one or more nodes can read data on that topic. A topic is, in a way, an asynchronous message bus, a little like an RSS feed. This notion of an asynchronous, many-to-many bus is essential in a distributed system situation.

A topic is typed, meaning that the type of data published (the message) is always structured in the same way. Nodes send and receive messages on topics.

Messages

A message is a compound data structure. A message comprises a combination of primitive types (character strings, Booleans, integers, floating point, etc.) and messages (a message is a recursive structure). For example, a node representing a robot servo motor will certainly publish its status on a topic (depending how you programmed it) with a message containing, for instance, an integer representing the motor’s position, a floating point for its temperature, another floating point for its speed, and so on.

The message description is stored in package_name/msg/myMessageType.msg. This file describes the message structure

Services

A topic is an asynchronous communication method used for many-to-many communication. A service meets a different kind of need; that for synchronous communication between two nodes. The idea is similar to that of a remote procedure call.

The service description is stored in package_name/srv/myServiceType.srv. This file describes the data structures for requests and responses.

Bags

Bags are formats for storing and playing back message data. This mechanism makes it possible, for example, to collect data measured by sensors and subsequently play it back as many times as desired to simulate real data. It is also a very useful system for debugging a system after the event.

The rxbag tool can be used to display data saved in bag files in graphical form

URDF

ROS provides other concepts that we will be able to explore in a further article. Mention should nevertheless be made of (another) interesting contribution to robotics from ROS in the shape of URDF (Unified Robot Description Format), an XML format used to describe an entire robot in the form of a standardised file. Robots described in this way can be static or dynamic and the physical and collision properties can be added to it.

Besides the standard, ROS offers several tools used to generate, parse or check this format.

URDF is used by the Gazebo simulator, for example, to represent the robot.

Resources

www.ros.org

Can Robots also do Teamwork with Humans ?

Gunjan Giri — Sat, 23 Oct 2021 14:33:28 +0000

As human interaction with robots and artificial intelligence increases exponentially in areas like healthcare, manufacturing, transportation, space exploration, defence technologies, information about how humans and autonomous systems i.e robots work within teams remains scarce.

Recent findings from research demonstrate that human-autonomy teaming comes with interaction limitations that can leave these teams less efficient than all-human teams.

Existing knowledge about teamwork primarily is based on human-to-human or human-to-automation interaction, which positions humans as supervisors of automated partners.

But as autonomy has increasingly developed decision-making skills based on spontaneous situation assessments, it can become a teammate rather than a servant. These shared decision interactions are identified as human-autonomy teaming, or HAT.

Nancy Cooke a cognitive psychologist and professor of human systems engineering at Arizona State University (ASU). She explored how an artificial intelligence agent can contribute to team communications failure, and how it can improve those interactions, in her discussion at the annual meeting of the American Association for the Advancement of Science (AAAS).

"One of the key aspects of being on a team is interacting with team members, and a lot of that on human teams happens by communicating in natural language, which is a bit of a sticking point for AI and robots," Cooke said.

Her discussion addressed a study in which teams of two humans and an AI, or "synthetic teammate," fly an unmanned aerial vehicle (UAV). The AI was the pilot, while the people served as a sensor operator and navigator.

The AI, developed by the Air Force Research Laboratory, communicated with the people via text chat.

"The team could function pretty well with the agent as long as nothing went wrong. As soon as things get tough or the team has to be a little adaptive, things start falling apart, because the agent isn't a very good team member."

The AI was unable to anticipate its teammates' needs the way humans do. As a result, it didn't provide critical information until asked—it doesn't give a "heads up."

"The whole team kind of fell apart," Cooke said. "The humans would say, 'OK, you aren't going to give me any information proactively, I'm not going to give you any either.' It's everybody for themselves."

This was what Professor Cookie said and she made a bit clear that Robots can be a Ideal Teammate unless and until a long breaking mishaps occur.

And even I do think Robots can be Good Team Partner supposingly we give instructions and calibrate them perfectly.

What you people think ? Do let me know in the Comment Section.

Till then,
Happy Learning !!!

Who makes better decisions : Humans or Robots ?

Gunjan Giri — Wed, 21 Apr 2021 15:28:51 +0000

Admit it. You rely on navigation apps to help you get around almost every day, whether you drive, take the bus or train, walk, or hike from point A to B.

In foreign cities, People depend on apps such as Waze and Google Maps to help them discover new places. At home, we use these apps to beat the rush-hour traffic and find the quickest routes to school, colleges, work, and other places we frequently go.

But sometimes, we doubt a suggested turn; we question a re-route; we suspect an arrival-time estimate.

Maybe it's because we're in a hurry. Maybe we just trust our own instincts better. Whatever the reason, there are situations that compel us to turn off the app, and go rogue, so to speak.

But, what exactly is going on in our head when we make decisions that override suggestions or recommendations made by automated systems? Yael Karlinsky-Shichor, a recently appointed assistant professor of marketing at Northeastern University, is on a quest to find out.

Karlinsky-Shichor's research focuses on the automation of decision-making and its application to marketing. She also studies the psychological aspects of using automation and artificial intelligence models. Wait, automation and marketing? Absolutely, says Karlinsky-Shichor. The two domains intersect more than you might think. She is really Great to Come up with these ideas.

"Many of the topics that we investigate in marketing today you can also find in information systems," she says. It was really nice and Interesting for me to broaden my view on those topics and look at them from a marketing perspective, but also to continue to look at the topics that involve technology and user interaction with technology.

Here's a case in point: Karlinsky-Shichor and her research colleagues ran a field experiment in which they tried to assess who could generate a higher profit for a business-to-business company that sells aluminum—humans or machines? They did this by creating an automated system that learned and reapplied every salesperson's pricing decisions.

They found that when the salespeople used the prices recommended by the automated system, that generated more money for the company. But interestingly, they learned that if the system were to be used in tandem with a high-performing sales representative, that would yield even better results.

"We use machine learning to automatically decide who should make the pricing decision—the salesperson or the model," Karlinsky-Shichor says. "What we find is that a hybrid structure that lets the model price most of the quotes that comes into the company but lets the expert salesperson take those cases that are more unique or out of the ordinary actually performs even better."

Here's why the reason is all about. Humans are unpredictable and fickle, but they are also more adapt at handling unpredictability. They have the advantage when it comes to meeting new clients, for example, gauging a client's needs and willingness to pay. However, machines have a lag up on humans in more technical, repetitive, and scalable tasks, and they get to avoid the different behavioral inconsistencies that people often display. Together, they're an unbeatable duo.

"In many cases, people think that AI models are going to replace human jobs," says Karlinsky-Shichor. What I find—and it's insight that comes up in many domains—is that instead of replacing humans, AI will complement them. And this is what it's gonna be in my opinion.

Two things happened after the researchers completed their case study. The company went forward with implementing the pricing process recommended by the automated system. And, the company's chief executive officer came back to Karlinsky-Shichor and her colleagues with an interesting offer.

"He said, 'well, why don't you go and take my best salesperson and create a model based on that salesperson? That model is going to give us the best results,'" she says. "But actually, we found that this is not the case. Even the best salesperson did not necessarily have an expertise that applied to every single case in this company."

The researchers found that, in fact, pooling the expertise of different experts generated a better outcome for the company's bottom line than using the highest-performing salesperson. So now they are working on an automation approach that will combine the wisdom of the crowds with individual expertise, she says.

Karlinsky-Shichor is also tackling a different, but related problem: How do you get people to faithfully follow suggestions or recommendations made by automated models? This issue of compliance is a challenge regularly faced by companies that use such systems, she says.

Again, she points to the business-to-business pricing scheme.

"What we see is that salespeople generally take the price recommended by the model when they either anticipate a low risk in the change, or it seems like there's a big difference in the price when going with the model," she says. "So one of my conjectures is that if they're very confident, or when they have no clue, they use the model's recommendation."

And when I read this intertwined field of marketing and artificial intelligence with Robots it did blew my mind off. And I guess this is one of the most Interesting topic to work upon.

What are your opinions in it ??
Do shoot in the Comment Section.

PID Control with its use in Robots and Real-life with Code and Verification

Gunjan Giri — Sun, 24 Jan 2021 15:16:41 +0000

Hello Everyone,
After a long period of time, I am here again to write something in Algorithms and it's use in Real Life. So, let's begin with PID Controllers.

PID controllers are the workforce of the controls world. PID controllers have the goal of taking some error in your system and reducing it to 0. While there are many other control strategies out there PID is probably the most common (unless you count human control) outside of just setting a setpoint. There are many advanced control strategies out there but in most cases, they will do similar or worse than a PID and be much more complex. When the other methods do better it will often only be by a small amount. One exception is if you have a model of the device and its operating conditions you can create a feed-forward controller (good for Robotics students) that performs better. However, in many cases using reactive control with a PID is the easiest and fastest approach to implement.

When we talk about PID control you should remember that each of the letters represents a different mode of the controller. The P is for the proportional element, the I is for the integral element, and the D is for the derivative element. Each element has a “term”, that gets multiplied with those elements. We use K to be a generic constant value, so the constant terms (or gains) are KP, KI, and KD respectively. Depending on your application you may or may not have all three of the terms. In many applications, you will have just PD or PI terms.

There are many forms of the PID controller. But here are the two that most people will care about:

Note: e and e(t) are the error terms, this is defined as: e = desired_value – actual_value. Often the actual_value is coming from some sensor that you have to detect the current value.

The first is in continuous time:

The second is in discrete time, which is what is more commonly used in computer-controlled applications:

And here is some code for the PID controller:

While the discrete approach is more useful from an implementation perspective. When it comes to understanding and tuning your controller the continuous approach is important for you to understand.

Also while you usually do not see the bias term added to the filter, I like to put it in just in case everything else sums to 0 and you still need motion, I will not have a 0 as the output. This is not strictly needed but it is nice to have in many cases. For example, if a wheel needs to continuously be rotating and the PID is just to maintain a given velocity.

The Terms:-

So now we know the form of this controller we can look at what each term does.

Proportional Term (KP)-
The proportional term is your primary term for controlling the error. This directly scales your error, so with a small KP the controller will make small attempts to minimize the error, and with a large KP, the controller will make a larger attempt. If the KP is too small you might never minimize the error (unless you are using D and I terms) and not be able to respond to changes affecting your system, and if KP is too large you can have unstable (ie. weird oscillations) filter that severely overshoots the desired value.

Integral Term (KI)-
The integral term lets the controller handle errors that are accumulating over time. This is good when you need to handle errors steady-state errors. The problem is that if you have a large KI you are trying to correct error over time so it can interfere with your response for dealing with current changes. This term is often the cause of instability in your PID controller.

Derivative Term (KD)-
The derivative term is looking at how your system is behaving between time intervals. This helps dampen your system to improve stability. Many motor controllers will only let you configure a PI controller. In some cases, this can be negative.

Which permutations of P, I, & D do I need?

In many applications, you will not use all 3 terms. So why not just always use all 3 terms? The fewer terms you use the easier the controller is to understand and implement. Also as you will soon see some modes can cause instability (ex. extreme vibrations) in the controls.

Just about every filter will have the P term. So let's just assume that KP is in our filter. Now the question is do I want to add just I, just D, or both into my filter.

If you want you can only have a P term. This is the simplest type of controller to tune since you only are playing with one value. The downside is that your controller will not smoothly correct itself for sudden and sustained error.

If you add a D term you will be more susceptible to noise and random values. So if you have very noisy data or random impulses that your sensors measure, you might want to leave the D term out. The downside of leaving the D term out is that you are not responding to those random values that might be legitimate, so you will have a slower response time. An example of this is if your motor hits a rock it will take longer to increase your commanded value since you are not looking at how the error is changing with time. However, if you are working on a robotic arm you might want the D term so you can quickly respond to changing forces.

The I term gets tricky. In many cases, you will want the I term so you can recover from an error that is slowly accumulating. The downside is that the I term is slow to respond. This slowness can lead to instability in your control.

How to tune your filter?

Tuning a filter can be difficult since a device (say a motor) might need to respond to different conditions. For example, if you tune your motor with no load it might not perform optimally with a load, and if you change the load you might need a different set of values to get optimal control. So often you are trying to find a set of parameters that works best in all cases and not necessarily optimal for any given case. There is another approach where you get different constants (the K values) to use in the filter and you choose which set to use based on the actual values in the system.

There are many ways to tune a PID controller. The two best ways that I know are manual (I know people don’t like manual things that rely on having an expert around) and Ziegler–Nichols method. With that said I have found that I can get better results by manually tuning a system, however, you can use the Ziegler–Nichols method as a starting point.

Manual Tuning

If the system is online, one tuning method is to first set KI and KD values to zero. Increase the KP until the output of the loop oscillates (or just performs well), then the KP should be set to approximately half of that value for a “quarter amplitude decay” type response. Then increase KI until any offset is corrected insufficient time for the process. However, too much KI will cause instability. Finally, increase KD, if required, until the overshooting is minimized. However, too much KD will cause slow responses and sluggishness. A fast PID loop tuning usually overshoots slightly to reach the setpoint more quickly; however, some systems cannot accept overshoot, in which case an over-damped closed-loop system is required, which will require a KP setting significantly less than half that of the KP setting that was causing oscillation.

Ziegler–Nichols

Another heuristic tuning method is formally known as the Ziegler–Nichols method, introduced by John G. Ziegler and Nathaniel B. Nichols in the 1940s. As in the method above, the KI and KD gains are first set to zero. The proportional gain is increased until it reaches the ultimate gain, KU, at which the output of the loop starts to oscillate. KU and the oscillation period PU are used to set the gains as shown:

So, this was all about PID Controllers and my working in the same for Various Projects. I hope you like it and if you have any doubts do comment down below.

Happy Learning !!!

Technology Will Erase Jobs- But also make everything Cheap or Free ...

Gunjan Giri — Fri, 31 Jul 2020 16:18:09 +0000

At a talk about how technology is shaping the future of money, it seems counterintuitive to talk about a future where technology has mostly done away with the need for money to live.

But that’s the future Peter Diamandis envisions.
Peter Diamandis is a Greek American Engineer and
CEO of the Zero Gravity Corporation.

It’s no secret that technology is threatening to take away jobs. For all the talk about robots working alongside humans rather than replacing them altogether, automation’s higher efficiency, lower costs, and increasing capability mean eventually workers will be removed from the equation in many jobs.

No one wants to be replaced by a machine, but there’s a silver lining.

The counterbalance to technological unemployment, Diamandis said, is the demonetization of living—in other words, pretty much everything we need and do in our day-to-day lives is becoming radically cheaper, if not free, and technology’s making it happen.

The most obvious and tangible example of this phenomenon is, of course, the smartphone. 20 years ago, we had a bunch of different things that each performed a single function: a camera took pictures, a flashlight lit up the dark, a TV was for watching shows, a VCR played movies, a boom box played music, and so on.

Now we have all that and more in the palm of our hands. More significantly, though, we got most of it for far less than in the past. If Diamandis said, you add up the cost of all that hardware 20 years ago, you’re looking at thousands of dollars—now reduced to a few hundred. Similarly, the average smartphone being micro financed for $50 in developing nations holds millions of dollars’ worth of software.

After digitization but before democratization, taking money out of the equation for a given product or service is a key part of making that product or service available to everyone.

Below are just a few of the examples Diamandis gave of demonetization he sees across various industries.

Communications

If you don’t have a smartphone or computer, you can’t have your data collected—and companies want your data. They want it so badly that they’ll soon be giving smartphones away, specifically in the areas of the world where the vast majority of would-be consumers aren’t online yet.

Entertainment

We used to drive to Blockbuster and pay a few Rupees to rent one movie. Now we can pay a low flat rate and watch as many movies and shows as we want each month. Or we can watch stuff for free; YouTube streams millions of hours of free video per day.

Energy

The poorest countries in the world are the sunniest countries in the world, and solar power is becoming cheaper than coal. That means ultra-cheap electricity in developing nations.

Transportation

When you own a car you have to pay for fuel, parking, insurance, tolls, and maintenance—not to mention buying the car itself. On-demand ride apps like Ola and Uber are changing the way people get around and making it cheaper for them to do so. Why pay all that money for your own car when there’s a service to get you from point A to point B at a fraction of the cost? Electric autonomous cars will disrupt transportation even more.

Housing

Self-driving cars will change the housing market by enabling people to commute from farther away more easily. The housing itself will get cheaper thanks to large-scale 3D printing.

Education

BYJU's foundation recently launched its Global Learning. Participants are tasked with creating a software package that can take a group of illiterate kids to full literacy in 18 months. This sort of software will bring high-quality education to areas that currently lack it—and it will be delivered in kids’ native language, in a context that fits their culture, at little to no cost to them. And a lot of Education Platforms as well.

Healthcare

Of all the industries listed, healthcare is the one most urgently in need of demonetization all over the World. It’s happening through AI-fueled diagnosis and personalization of care. Deep learning algorithms can now identify skin cancer as accurately as dermatologists can. IBM’s Watson was able to diagnose a rare form of leukemia that no physician could diagnose by analyzing data from 20 million other diagnoses. Genome sequencing will transition healthcare from being reactive to proactive, keeping people from getting sick in the first place.

A world where life’s necessities are all cheap or free will be very different from the world we live in today. What will motivate people to work or be productive if they don’t need money for the basics? What kinds of new innovations will spring up from people for whom these resources used to be cost-prohibitive? How will social constructs build around wealth and class shift?

These are all questions we’ll need to contemplate as technology continues to demonetize our lives. As the old saying goes, the best things in life are free, we’ll have to figure out which of the free things in life are best.