Perpetual Computing and AI Autonomous Cars
By Lance Eliot, the AI Trends Insider
The bookstore manager looked at me and said that the computer program that I had developed to analyze the books database was going to run “perpetually” and he was quite steamed about how long it was taking to execute.
Well, hold on, let’s start this story at the beginning so you’ll have some context about what was happening.
Back in my college days, I was a gun-for-hire in terms of a willingness to whip together off-the-cuff computer programs for anyone that needed a quick-and-dirty programmable task done, doing so to earn a few extra bucks for those large pepperoni pizzas and kegs of beer that I kept ordering with my classmates.
The college bookstore manager had asked me to craft a program that would generate some reports for him.
Without taking much time to analyze the situation (that’s when I was young and headstrong), I wrote a brute force algorithm that would sort the voluminous data and produce the reports.
On a Monday morning, I launched the program and let it fly.
In that era, the amount of data involved was considered rather large since it was data for all 30,000+ students and included their classes, the books required for their classes, etc.
When the bookstore manager asked me how long it would take for the program to run, I hedged and said it would take about a day.
In my mind, I was thinking it was around four to eight hours to run, and so I said “a day” meaning a workday, though a day might of course also mean a 24-hour period.
The next morning, I got an angry call from the store manager.
He told me that the program was still running and it had been “a day” since I started it.
I was thankful that I hadn’t said it would be four to eight hours since I would have really been off-target. I assured him that the program was going to finish soon and not to get concerned. Having done the program with little attention to any kind of debugging or testing, I hadn’t even included aspects that would readily allow me to check on the progress of the code.
It was pretty much a wait-and-see situation.
I went to my college classes for the day and assumed that since the bookstore manager had not tried to contact me again that the program had successfully completed and presumed that he had his desired reports.
No need to put any added energy or thought towards that sketchy program.
Sure, it had used one of the most inefficient sorting algorithms known to mankind, but hey it was running uninterruptedly and how long would it take to get the job done?
By Tuesday evening, I was chowing down on more pizza and pleased with having presumably gotten the bookstore manager what he had wanted.
Wednesday morning was a real wake-up call, literally.
I got an urgent call from the bookstore manager at sunrise, which I admit was not my normal waking time in college, and he was yammering away about how my program was running and running, eating up the main computer system for the store, and still there was no sign of any reports being produced.
It had now been running non-stop for 48 hours and had not yet completed.
With great embarrassment and chagrin, I promised to rush over to the computer center and dig into what was going on with the program.
Looking like I had been on a drunken spree the night before (I had not!), I scurried to campus and sprinted into the computer center to have an under-the-hood look at the execution of my program.
The good news was that it was working as intended.
I was sure that it would ultimately produce the reports.
The bad news was that I had not considered the run-time speed, and nor had I considered how the data was structured and nor the nature of the disk drives that were being used, nor the amount of memory in RAM, etc.
It was a handy lesson about what can happen when you do sloppy programming.
I vowed to not let this kind of mess happen again and that I would be more “software engineering minded” henceforth.
In case you are wondering what eventually happened, believe it or not the darned thing kept running and running, and the manager asserted that I had written a program that would run perpetually (that brings us full loop to the “start” of my story).
From his viewpoint, he hadn’t yet seen any results and so it was all invisible run-time and no actual visible reports.
Finally, on Sunday, the program completed and produced the needed reports.
It had taken nearly seven days, which the store manager pointed out that the entire earth could have been created in that length of time (depending perhaps upon your beliefs).
Anyway, this story highlights the notion of having a computer that might run perpetually.
Not by accident or happenstance, but by purposeful design.
It is commonly referred to as perpetual computing.
Perpetual Computing Arising
Perpetual computing. It’s a new and upcoming area that we’ll be all thinking about in the next several years.
Imagine a computer that could run perpetually.
In fact, when you consider the matter, what is it that usually would stop a computer from running perpetually?
Other than the notion that it might breakdown from wear-and-tear or exhaustion, the other factor would most likely be electrical power. A computer that runs all of the time will need electrical power all of the time. Electrical power is typically a scarce and costly resource.
I’m betting that if you have a desktop computer, it is plugged into an electrical socket and thus you rarely consider how much electrical power it needs (when it is plugged in, your computer is considered “tethered” since it is physically connected with the electrical socket).
If you have a laptop, I’d wager that you do pay attention to electrical power and have found yourself scrambling to find a place to plug-in your laptop before it runs out of power. For your smartphone, you certainly have experienced the same kind of anxiety about watching how much power is left and clamoring to find a way to recharge the battery that is in the cell phone.
Consider the world once the Internet of Things (IoT) has really taken off.
There are going to be tons and tons of small IoT devices that will be attached to walls, attached to doors, attached to appliances in your home, and all over the place. Some analysts claim that by the year 2020 there will be around 200 billion IoT devices and by the year 2030 a total of perhaps 1 trillion IoT devices. This already vast trillion number could increase to 10 trillion by the year 2040.
For my article about IoT, see: https://aitrends.com/ai-insider/internet-of-things-iot-and-ai-self-driving-cars/
For my article about electrical power consumption, see: https://aitrends.com/selfdrivingcars/power-consumption-vital-for-ai-self-driving-cars/
Let’s assume that most of those IoT devices are powered by a battery.
Have you ever been annoyed at having to change the batteries in your home smoke alarm?
You usually only have a few of those devices in your home. Pretend that you have dozens, maybe hundreds of small-scale IoT devices in your home, all of which are powered by tiny batteries. How often will you need to be changing those batteries? It could almost become a full-time job of each day walking around your house and changing batteries. Maybe we’ll christen a new job for homes and businesses that provides employment for people that will change the batteries in your IoT devices.
There must be a better way to attend to the power needs of all of these ubiquitous IoT devices.
By the way, having a vast number of IoT devices is often referred to as ubiquitous computing, meaning that it is computer related devices that are all around us and everywhere.
Another way to describe this trend is to call it pervasive computing.
Pervasive in this context means the same thing as ubiquitous.
Don’t confuse though pervasive computing with perpetual computing.
Pervasive just means there are a lot of computing devices, while perpetual computing means that there are some computing devices will be able to run perpetually without stopping.
Though these always-on tiny devices will hopefully be beneficial, it is important to also consider the privacy concerns that they raise, along with the security related apprehensions.
Harvesting Energy To Satisfy Perpetual Computing
How can we provide electrical power to these ubiquitous untethered computer devices and do so without the hassle and logistical nightmare of having to walk around and change their batteries?
We might instead undertake energy harvesting.
If possible, an untethered computing device might try to scavenge energy from its surroundings.
One obvious means is the use of solar energy.
If the computing device is outfitted with a mini-solar panel, this might provide sufficient energy to keep the device going perpetually. You need to always consider the amount of effort required to get the energy and thus make sure that the energy harvesting is “profitable” (if it takes more energy to snatch energy, you end-up with a net negative that does you little good).
There are some promising research efforts that provide a multitude of other ways to harvest energy from the environment in which the computing device resides.
You might be able to use thermal gradients and the differences in air temperature to provide power to a computing device.
You might be able to use magnetic fields to power a computing device.
The WiFi that you are using in your home or office for making electronic communications can become a power source by having computing devices that rake in the RF waves and turn those into electrical power.
It is anticipated that via miniaturization, we’ll see that IoT devices keep getting smaller and smaller in size, and are able to rely entirely on energy harvesting via nearby vibrations, sound waves, chemical reactions, light waves, motion elements, and the like.
Smart Dust Coming Your Way
These tiny and always-on IoT devices will be so small and so prevalent that some say we will refer to them as “smart dust.”
Another consideration involves how much storage capacity the computing device has for the storage of the energy collected.
Does the computing device have enough energy storage capacity to survive during times when there is insufficient energy to be harvested nearby?
If the computing device has essentially no energy storage capacity, it means that it “lives” off the energy harvesting and needs to be harvesting continually and hope that there is energy there to be harvested.
The ambient energy sources might be unpredictable. Here in sunny Southern California, you would assume that any kind of solar powered device would always have plenty of sunshine to draw power from. Unfortunately, I’ve gone on hikes in the woods with some of my hiking gear dependent upon solar power and they’ve gotten depleted during a hike, regrettably due to not enough sun energy striking the solar panels to keep the units powered. I’m sure it’s worse in climates that don’t have the kind of always-on sunshine like we do.
When you first deploy any kind of IoT device, it usually comes pre-charged up.
What you don’t necessarily know is how long will that initial charge last?
There is an initial energy allotment when the device is first deployed and depending on how the computing device functions, it might last a long time on that initial supply or it might run out quickly.
You’ve maybe found out from time-to-time that when you buy a child’s toy that comes with a battery included, sometimes the toy maker will include a super-cheap battery that holds almost no charge at all. This keeps down their costs in terms of what is included into the toy and allows that it will at least work the moment you get home. Pretty soon though, after taking the toy out of the box and having your child play with it, the next thing you know it has run out of power and you need to replace the cheapo batteries with more robust ones.
For some of the IoT makers, they might do the same thing. They might include a low-end super-cheap battery so that the IoT computing device works for a short while, and then it runs out. If the computing device is one that is trying to make use of perpetual computing, it would switch right away into a mode of harvesting energy and not need to dip into the initial charge, or it might be able to recharge the initial charge, doing so on its own while harvesting.
If we don’t find ways to achieve perpetual computing, it implies that you might eventually end-up with IoT devices all around your home and work that are just sitting there and doing nothing at all, because they’ve run out of power and it is too troublesome to try and replace their batteries. That’s likely a sad waste of those devices, and it also creates a clutter.
Some are especially worried that there will become a mindset of simply throwing away IoT devices that run out of power. Consider the millions and billions of IoT devices that might get discarded, fouling up our reclamation capabilities and likely polluting our waters and earth. If the IoT was able to harvest power, presumably people would be more likely to hang onto it and make use of it.
At conferences, I often discuss perpetual computing and some people seem to think that perpetual computing equates with having perpetual motion machines.
Nope, that’s a misnomer.
I don’t think anyone of a reasonable mind would consider a computing device that can run “perpetually” due to harvesting power from its environment is the same as a perpetual motion machine. A perpetual motion machine is one that once set into motion will continue in motion, forever, and does so without adding any additional energy into it. In the case of perpetual computing, we are straight out saying that the device will be adding energy to it, doing so in at times clever ways from its environment, but nonetheless it is not a free ride akin to what a perpetual motion machine promises.
We also need to be practical and consider that eventually these computing devices are going to wear out.
The word “perpetual” needs to be taken with a grain of salt. Assuming that the perpetual computing device can really always glean sufficient energy from its surroundings, one way or another that device is ultimately going to falter or fail due to some kind of mechanical breakdown. The device might last many years, but it won’t last until the end of time (well, unless you are predicting the end of time is coming sooner than I hope it will!).
AI Autonomous Cars And Perpetual Computing
What does this have to do with AI self-driving cars?
At the Cybernetic AI Self-Driving Car Institute, we are developing AI software for self-driving cars. It will be interesting to see how perpetual computing comes to play regarding the advent of AI self-driving cars.
Allow me to elaborate.
I’d like to first clarify and introduce the notion that there are varying levels of AI self-driving cars. The topmost level is considered Level 5. A Level 5 self-driving car is one that is being driven by the AI and there is no human driver involved. For the design of Level 5 self-driving cars, the automakers are even removing the gas pedal, brake pedal, and steering wheel, since those are contraptions used by human drivers. The Level 5 self-driving car is not being driven by a human and nor is there an expectation that a human driver will be present in the self-driving car. It’s all on the shoulders of the AI to drive the car. The Level 4 is akin to a Level 5 but with self-imposed scope constraints.
For self-driving cars less than a Level 4, there must be a human driver present in the car. The human driver is currently considered the responsible party for the acts of the car. The AI and the human driver are co-sharing the driving task. In spite of this co-sharing, the human is supposed to remain fully immersed into the driving task and be ready at all times to perform the driving task. I’ve repeatedly warned about the dangers of this co-sharing arrangement and predicted it will produce many untoward results.
For my overall framework about AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/
For the levels of self-driving cars, see my article: https://aitrends.com/selfdrivingcars/richter-scale-levels-self-driving-cars/
For why AI Level 5 self-driving cars are like a moonshot, see my article: https://aitrends.com/selfdrivingcars/self-driving-car-mother-ai-projects-moonshot/
For the dangers of co-sharing the driving task, see my article: https://aitrends.com/selfdrivingcars/human-back-up-drivers-for-ai-self-driving-cars/
Let’s focus herein on the Level 4 and Level 5.
Many of the comments apply to the less than Level 4 self-driving cars too, but the fully autonomous AI self-driving car will receive the most attention in this discussion.
Here’s the usual steps involved in the AI driving task:
- Sensor data collection and interpretation
- Sensor fusion
- Virtual world model updating
- AI action planning
- Car controls command issuance
Another key aspect of AI self-driving cars is that they will be driving on our roadways in the midst of human driven cars too. There are some pundits of AI self-driving cars that continually refer to a utopian world in which there are only AI self-driving cars on public roads. Currently there are about 250+ million conventional cars in the United States alone, and those cars are not going to magically disappear or become true Level 4 or Level 5 AI self-driving cars overnight.
Indeed, the use of human driven cars will last for many years, likely many decades, and the advent of AI self-driving cars will occur while there are still human driven cars on the roads. This is a crucial point since this means that the AI of self-driving cars needs to be able to contend with not just other AI self-driving cars, but also contend with human driven cars. It is easy to envision a simplistic and rather unrealistic world in which all AI self-driving cars are politely interacting with each other and being civil about roadway interactions. That’s not what is going to be happening for the foreseeable future. AI self-driving cars and human driven cars will need to be able to cope with each other.
For my article about the grand convergence that has led us to this moment in time, see: https://aitrends.com/selfdrivingcars/grand-convergence-explains-rise-self-driving-cars/
See my article about the ethical dilemmas facing AI self-driving cars: https://aitrends.com/selfdrivingcars/ethically-ambiguous-self-driving-cars/
For potential regulations about AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/assessing-federal-regulations-self-driving-cars-house-bill-passed/
For my predictions about AI self-driving cars for the 2020s, 2030s, and 2040s, see my article: https://aitrends.com/selfdrivingcars/gen-z-and-the-fate-of-ai-self-driving-cars/
Returning to the topic of perpetual computing, let’s consider how the advent of these new innovations in energy production might impact AI self-driving cars.
Harvesting Energy To Power The AI Of Autonomous Cars
First, it certainly would be tremendous if somehow the self-driving car itself could harvest energy from its surroundings, thus no longer being “tethered” to having to go to a gasoline station for a refill and not needing to be connected to a charger for an EV (Electrical Vehicle).
One means of providing energy consists of solar panels on a self-driving car.
Right now, the energy derived would be insufficient to fully run the self-driving car. You also need to take into account the size of the solar panels and their weight, which then impacts the car design and shape. As per my earlier comments, even if this could be perfected you would then still have the unpredictable nature of the solar energy that might be available and also in some parts of the world you would barely have use for this approach for most of the year.
I am not counting out the solar route and just saying that until there are more breakthroughs in terms of their size, shape, and energy harvesting capability, it is unlikely to do much for self-driving cars other than to act as a mild add-on for potentially providing some limited amount of energy generation.
Another means to gain energy would be via regenerative braking.
Your car brakes can be used to convert kinetic energy into electrical power. In essence, you are recovering energy that would otherwise be tossed away by the brakes as heat. Instead, you take the friction and put it to a more useful purpose, namely helping to power the self-driving car.
Similar to the issue about the solar panels, right now the use of regenerative braking can only supply a rather small amount of electrical power. It is not going to be enough to run the self-driving car. In any case, it is something to be watched and will ultimately likely be a handy contributor to the power needs of the self-driving car.
Akin to the conversion of kinetic energy with the brakes, you can also make tires that are embedded with nanogenerators and have those specialized tires generate electrical power from the roadway friction. Right now, your tires are creating friction as they come in contact with the roadway surface, but your car is just tossing away that potential energy. Harvesting it will help provide some energy to the self-driving car, though again a rather minor amount and be insufficient to truly power-up the self-driving car.
There are lots of other ideas out there about this matter.
Maybe we would have along our roadways various magnetic generator boxes that the self-driving car could grab energy from as it whooshes past the boxes on the highway. Perhaps the self-driving car could make use of temperature gradients to try to harvest energy. And so on.
For now, I’ll say that you cannot hold your breath that any of these approaches will in the near-term arise sufficiently to be able to fully power an AI self-driving car.
They will each be handy supplemental sources of energy, but not “the” source.
Consider The Sensors As Perpetual Computing Devices
We ought to then return to the notion that perpetual computing will likely consist of very small IoT devices that have a built-in energy harvester.
The energy harvest has to be tiny too, since otherwise it would bulk-up the IoT device. The weight of the energy harvester element also has to be relatively low, since it would make the IoT device hefty and heavy.
This could be handy for the sensors of the AI self-driving car.
Right now, we are assuming that the sensory devices on an AI self-driving car will all be powered by the AI self-driving car per se.
Suppose though that some of the sensors could provide their own power?
This would then cause less of a drain on the self-driving car and reduce its need to generate the tremendous amount of power required to run all of the sensory devices (of which there will be many included onto and into a self-driving car).
You might then more readily be able to add more sensors to the AI self-driving car too.
Knowing that they can harvest their own energy means that it relieves the self-driving car of having to do so. Of course, the downside involves the chance that the sensor is not able to harvest energy when needed and the sensor goes blank, such as if the self-driving car is doing 80 miles per hour on the freeway and the sensor is supposed to be providing key readings to the AI system on-board the self-driving car but runs out of power.
One approach would be to tie the perpetual computing devices into the electrical power of the AI self-driving car, and yet only have those devices draw power from the self-driving car when they otherwise are not able to grab sufficient energy from their surroundings on their own. Indeed, you could have a two-way flow, involving the perpetual computing devices not only drawing energy from the self-driving car when needed, but also possibly pouring energy into the AI self-driving car if the device is able to grab more energy than itself needs to function.
Another aspect of self-driving cars will be the number and variety of IoT devices included in the self-driving car by the automaker, along with the numerous IoT devices that passengers will bring with them into an AI self-driving car. These IoT devices might need to tap into the electrical reserves of the self-driving car to be able to run. On the other hand, if they are able to be perpetual computing devices, they might be able to harvest energy on their own and not bother using up the power of the self-driving car (plus, possibly even be able to contribute their “excess” energy to the self-driving car).
For ridesharing and AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/ridesharing-services-and-ai-self-driving-cars-notably-uber-in-or-uber-out/
For the non-stop use of AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/non-stop-ai-self-driving-cars-truths-and-consequences/
For start-ups making innovative devices for AI self-driving cars, see my article: https://aitrends.com/selfdrivingcars/how-to-best-pitch-your-startup/
V2X Electronic Communications Importance
Some have speculated that perhaps via V2V (vehicle-to-vehicle communications) there will be an opportunity for self-driving cars to not only share electronic communications but also share energy.
While your AI self-driving car is on the highway, it might be immersed in heavy traffic and other self-driving cars nearby are sharing roadway traffic info via V2V with your self-driving car. At the same time, it could be that the V2V allows your self-driving car to grab some of the excess energy generated via the V2V, and the energy can be plowed back into the electrical power reserves of the self-driving car.
This could likewise potentially be the case with V2I (vehicle-to-infrastructure communications). V2I consists of the roadway infrastructure sending electronic communications to your AI self-driving car. An upcoming bridge might electronically warn your self-driving car that the bridge is blocked and not usable at this time. A street up ahead might forewarn your self-driving car that there is a big pothole in the road and it should be avoided. In the process of making those V2I communications, energy might be harvested from the excess of those communications.
Perpetual computing can be in the small and in the large.
Currently, the focus is primarily on the small, mainly the IoT devices that we are going to be using in the billions and someday trillions of them. It would be a boon to society if those IoT devices could harvest their own energy and work around the clock, as needed, without having to plug them in (tether them) and nor having to replace their batteries.
Say, excuse me for a moment as I have to go change the batteries in my outdoor portable lights – which I hope soon to be able to never say again, namely, I’d like to eliminate the phrase “go change the batteries.”
Let’s aim for that.
Copyright 2019 Dr. Lance Eliot
This content is originally posted on AI Trends.
[Ed. Note: For reader’s interested in Dr. Eliot’s ongoing business analyses about the advent of self-driving cars, see his online Forbes column: https://forbes.com/sites/lanceeliot/]