By Lance Eliot, the AI Trends Insider
Eli Whitney is well-known for his invention of the cotton gin and for using the budding approach of interchangeable parts to produce his ingenious device. Until the emergence of interchangeable parts as a means of production, most devices and systems were typically crafted by-hand and varied significantly in terms of the size and the fitting of the various parts involved. Variations in size and fit meant that key elements could not just be snapped together, and nor could you readily do repairs and replacements since it required idiosyncratic by-hand one-off manufacturing.
You might not be aware that Eli Whitney was actually more successful at applying the interchangeable parts approach to the making of guns. In the case of the cotton gin, he ultimately made very little money from the remarkable invention, mainly due to those that openly violated his patent and copied his same designs, doing so en masse and his lawsuits were generally unable to stop the stealing of his approach. Nonetheless, he started a wave toward interchangeable parts as a prudent and successful form of production. We can all be thankful for that impetus.
Eli leveraged his notoriety of the cotton gin to win a massive federal government contract to make 10,000 muskets in preparation for the United States going to war with France. He vowed that he could produce the unheard-of volume by exploiting the interchangeable parts approach and won the contract by claiming he could get the project done in less than two years. Most doubted the possibility of his doing so.
The doubters turned out to be right and after two years had passed, he was still desperately trying to put together his production line and do so with the interchangeable parts method of building and assembly. Congress along with incoming president Thomas Jefferson and outgoing president John Adams demanded to know what Eli was doing and wanted to know when the government would receive its sorely needed muskets. Apparently, Eli went to Washington D.C. and did quite an act of showmanship to buy himself more time.
Standing in front of an assembled group of top dignitaries that included the two presidents, Eli supposedly laid out an array of musket parts, strewn on top of a large table top. He then proceeded to seemingly randomly select a part, and then randomly select another part into which it was to fit, and readily plugged them together. The crowd was stunned and elated.
Keep in mind that when making a musket at this time period in history, each part would be handcrafted and have to be shaped to fit properly to another also handcrafted part. This would take many hours to do and be extremely laborious. Plus, no two such parts could be used on another musket per se, unless you handcrafted them over again. Eli’s bold demonstration that you could just pick-up any one of the parts and snap them together was unfathomable to most and was as impressive as any breathtaking magic trick, such as pulling a rabbit out of a hat or making an elephant disappear on a stage.
As a result of the vivid demonstration, he kept the massive contract and he gained even more federal work. Some allege that he pulled a fast one on the onlookers and had actually discretely marked the parts beforehand, allowing him to know which ones would actually fit to which other ones. Notably, it was he that actually “randomly” selected the parts from the table and not someone else, thus, presumably, it was possible to appear as though just any part would fit with any other part. Devious? Contrived? Or simply a good magician. You decide.
In any case, Thomas Jefferson was later to credit the dawning of the machine age to Eli Whitney. Though Eli took several more years to produce the ordered muskets, they were considered of greater quality and more readily serviceable due to the interchangeable parts method. And, after finally getting his production line into shape, a subsequent order of 15,000 additional muskets was completed in record time and at a lower cost than if they had been made via the traditional individually handcrafted methods.
We now know that interchangeable parts is crucial to any kind of mass production. Sure, it might take longer to get your ducks aligned, having to design the parts to fit properly and devise a production line and manufacturing effort to achieve the needed precision, but in the end, you’ll be able to more cheaply make the product. Not only is the cost ultimately lower per finished device or system, you can churn them out faster, and for maintenance and repairs the cost and effort is lessened.
There are circumstances whereby aiming to leverage an interchangeable parts approach might not be savvy. It’s not a cure-all. If the number of needed units is low, or if the amount of time allowed to make the units is low, you might be better off jumping into the handcrafted method instead. There is a lot of overhead in making use of an interchangeable parts approach and therefore you need to ascertain for any given circumstance what the appropriate and most beneficial method is to be used.
A close brethen of interchangeable parts is the concept of modularization.
It makes sense to structure or architect your device or system into a series of modules when you are considering using an interchangeable parts approach. By decomposing something into various components or modules, you then can devise them so that they fit together well. Thus, you can then mass produce these smaller components or modules, and when piecing the whole thing together they will by-design snap together.
Modularity has other handy benefits too, beyond the notion of mass production. Presumably, you can focus on getting each module right, in a divide-and-conquer way, rather than having to try and get the entire system right all at once. Also, when things go awry, you can hopefully narrow down more readily where the problem lies, since you can progressively rule-in and rule-out the modules until you find the culprit within a particular module that is causing the problem.
In the software field, any software engineer worth their salt knows that modularity is vital to developing software. This is especially the case when the software is large-scale in size. The odds are that you’ll have a team or many teams of software developers working on the system and trying to do so with one massive monolith is bound to be problematic. Instead, by architecting the system into modules, you can parcel out the effort to various teams or sub-teams and bring the system together as a whole when needed to do a wholescale system test of the numerous units or modules.
The development of AI systems is likewise usually benefited by structuring the system into modules. You are bound to have parts of the AI system that are leveraging AI techniques and capabilities, meanwhile there are likely other parts that are more conventional in their approach. You can architect the overall system into those modules that are AI specific and those that are more conventional. Of course, you don’t need to modularize the system on that basis and might do so for other purposes such as based on functionality or other uses.
If you did subdivide an AI system into two overarching halves or layers, consisting of a half that had the AI and the other half that had more traditional elements, it would be a type of cleaving that might be handy. Presumably, at a later date, you might discover newer AI techniques and could then focus on embodying those into the AI half, possibly being able to leave the traditional element layer untouched. You might also want to port the system over to another platform, and if the half with the more traditional elements was handling those aspects, you could potentially switch out the traditional elements as a module and possibly not need to upset or change the AI layer.
Interchangeable Parts, Modularization and Cars
Let’s consider for a moment how the concepts of interchangeable parts and of modularization are related to cars.
By-and-large most automobiles are devised of interchangeable parts. You might have an engine that is one overall module and it contains a multitude of parts, all of which are made in an interchangeable way, allowing you to assemble an engine by snapping in the appropriate parts in the appropriate places.
The engine is likely able to be popped into the rest of the car and allow you to make the engines without having to do so as tailored to the particular car body and other car elements. It is all modularly devised and done so with interchangeable aspects, meaning too that you need to upfront get everything well figured out so they will fit together without difficulty.
At times, cars are devised into Knock-Down kits (referred to as KD).
The Knock-Down approach involves making some of the parts in one place and then shipping them to another place for final assembly. For example, you might make some of the parts in one country, export them to another country, and complete the assembly of the car in that other country. Auto makers do this for several reasons including at times the benefit of possibly having some parts made at a lesser cost in another country and then bringing those parts to say the country in which the final assembly and then selling of the car will take place (there are often tax and financial benefits of doing things this way).
There are variants of the Knock-Down tactic. You can have all of the non-assembled parts in totality and ship those to a location to be assembled, in which case this is referred to as a Complete Knock-Down (CKD). If you have just part of the assembly, it is known as a Semi-Knocked-Down (SKD). When you are going to ship the Knock-Down to another country, this is known as a Knocked-Down Export (KDX). For the case of making the parts and assembling them into a whole car, doing so within the country of origin and then shipping them out to be sold, it is known as a Built-Up Export (BUX).
I’m guessing that most of us realize that the modularization of cars makes a lot of sense and have become accustomed to the notion. There is a slew of benefits by leveraging modularization. One aspect that might be surprising to you involves a form of modularization that you might not have yet explicitly considered, which I’ll tell you about in a moment.
Remember how I earlier suggested that for an AI system we might modularize it into at least two major halves or layers, consisting of a layer that has the AI components and a second layer with the more traditional components. I’m not saying you need to do things that way, and only pointing it out as a possibility, which might or might not make sense depending upon the nature of the AI system that you are creating. Also, be clear that the modularization exists within those halves too, and thus I am not somehow suggesting that there are merely two monoliths, and instead saying that you could have a major modularization at the topmost level and then have modularization within those subsequent layers or modules.
For cars, suppose we tried to employ the same idea of dividing a car into two major halves or layers. If so, what would those layers consist of?
I suppose you could liken this to those magic acts that appear to split a person in half. Yikes, people weren’t made to be split in half. It defies logic. We all know that the human body is built as one monolith and you cannot just cut it in half, though magicians try to make us believe otherwise. When a magician does this trick, do they cut the person in half lengthwise or by widthwise? Well, usually they cut the person around the stomach and have an upper and lower half (I’ve not seen magicians that try to cut a person down the middle of their length, which might be interesting to see, or perhaps disgusting to see).
In the case of a car, the seemingly most logical way to cut it into half would be to devise a lower half and an upper half. We’ll refer to the lower half as the chassis of the car, which can also be referred to in many other ways, including calling it the platform, the undercarriage, the powertrain, the skateboard, and so on. The upper half we’ll refer to as the body, or the body type, or some like to say it is a pod.
Let’s then say that we’re going to design a car that has two major halves, a lower half that is the chassis or platform, and an upper half that is the body or pod.
Why would we do this?
As long as we adhere to the interchangeable parts mantra, in theory we can make the chassis or platform in one place and later on attach the body or pod in another place. This would allow us to make the two halves in different parts of a country or in different countries, and yet still be able to bring them readily together when we wanted to do the final assembly.
This though is merely the advantage of production. We can also gain the advantage of possibly being able to reuse the chassis or platform and have a variety of body types or pods that we can place onto the chassis. This means that we can more likely have a multitude of different cars, which are hopefully easier to produce, by having our own “standardized” chassis or platform and then making a variety of pods that would be plopped onto the platform or chassis.
Pretend that you wanted to make a car that was primarily to be used for transporting people. You would want the interior of the car to be well-suited for people to be present in the car. There need to be seats that can accommodate the passengers. There needs to be protective gear such as air bags to provide safety aspects for the occupants. We might want to include in-car entertainment such as radios or TVs, and so on.
Suppose you also wanted to make a car that was primarily going to be used to transport goods. In that case, you don’t need and nor want those seats that would be used in a passenger-oriented car. The seats are just going to get in the way of being able to stack boxes or items into the car. You don’t need the entertainment gear since the boxes or bulky other items don’t care about being entertained. You might want to have various straps and other restraints that would keep the goods from rolling around. And so on.
You would most likely construe that these differing needs would mean that we need to have two completely different cars. One car is designed and built as a passenger car. The other car is designed and built as a goods transport car. Two different purposes. Two different designs. Seemingly the only thing they have in-common is that they are both cars.
But, wait! If a chassis or platform contained all of the engine, tires, transmission, and other such “car mobility” elements, we need to realize that the aspects about the body or pod portion is where the differences are. The lower layer can be possibly the same, while it is just the upper layer that we want to change out.
Thus, rather than making two completely different cars, suppose we considered making a lower half or layer that was the mobility portion, and the upper half was the body type or pod. We could then aim to make a variety of upper halves that could plug into our “standardized” lower layer. Doing so would give us a great deal of flexibility.
The flexibility of having a lower layer and a changeable upper layer could be quite attractive. When making cars, it is tough to predict how many cars you are going to likely sell. If you guess wrong, you can end-up not having enough cars to meet the market demand, or you might end-up with an excess of cars and have a bloated and costly inventory leftover.
You might have an especially difficult time trying to determine how many passenger cars to make versus how many goods transport cars to make.
Also, a buyer of your passenger car or your transport car is usually locked into whichever choice they made when buying the car. I own a traditional passenger car and at times when I’ve helped my kids move to their apartments or dorms for college, I’ve tried to use my passenger car to haul their stuff, though this is not easy to do, such as fitting a large-screen TV or a surfboard into my passenger sized and shaped car.
Ideally, it would be nifty to buy a car that could transform from being a passenger car into a goods transport car or being a transporting of goods car to becoming a passenger car. We’ve seen the auto makers struggle mightily with this same aspect, doing so by making the seats in a passenger car be able to be pulled out or potentially lay flat. Likewise, they make SUV’s or vans that can transport goods and that have collapsing seats or similar aspects to try and accommodate passengers.
Rather than trying to make one car that can do two things, we might instead consider making two cars that each does one thing well. The problem though is that we would normally need to make two different cars, which adds up in cost to produce and makes the prediction problem harder as to how many to make.
A solution might be to go ahead and make a chassis or platform that we can use universally for being the mobility center for whatever kinds of upper layers or pods that we might want to make. We could make one pod or upper layer that can superbly accommodate passengers. We could make another pod or upper layer that is well-suited to transporting goods. Etc.
This seems like a robust way to get the best of both worlds.
Of course, the catch consists of being able to actually be able to bring together the two halves and do so in a manner that is not overly arduous to achieve. If we are suggesting that you could readily switch from a passenger pod to a transport-of-goods pod, this implies that it is relatively easy to unplug one pod and plug in another pod.
Making a plug-and-play of an entire chassis with an entire pod, it’s a challenge. You could liken this somewhat to playing with Legos, though these are rather large Legos and have a lot that would bind them together. Presumably, the upper layer is going to want to tap into the functions of the lower layer, such as getting electrical power, as a minimum, along with sharing of a multitude of other aspects.
This concept of having a lower layer of the car and an upper layer is often referred to as a modular vehicle. Auto industry insiders might refer to this as the Ridek, which I’ll explain next.
A patent was awarded in the year 2000 to Dr. Gordon Dower for his invention of a modular vehicle, which also was an EV (Electrical Vehicle). The lower layer contained the engine, transmission, and so on, and he referred to it as the Modek, signifying the motorized or mobility layer (aka the chassis or platform). The upper layer was the Ridon. When you put together the Ridon with a Modek you got yourself a Ridek, the then usable car as a whole. General Motors (GM) came along in 2004 and attempted to patent a modular vehicle which they called the Autonomy. This led to a dispute about the matter.
When I attended this year’s Consumer Electronics Show (CES) in January, the modular vehicle approach was a bit of a splash since Mercedes-Benz was unveiling their Urbanetic, a concept car based on the lower layer and upper layer approach. The pod or upper layer for passengers will accommodate about a dozen occupants. There will be windows, a moonroof, and LED displays, all of which would befit the needs of human passengers. A pod for transporting goods, considered a cargo module, will have around 350 cubic feet of space and could accommodate perhaps ten pallets or so of goods.
Can A Modular Car Be Cool?
One question that some have asked about these modular designs is whether the resultant car will look attractive or not.
Is it possible to achieve modularity and at the same time have a cool looking car? Some of the concept designs look quite slick, while others have been criticized as downright ugly (or at least bulky and unwieldy in appearance). You might argue that the rise or fall of conventional cars is often based on how it looks as much as how it performs, therefore, the stylishness makes a big difference. In the case of AI self-driving cars, there are those that say that the looks of the car won’t make a difference since it is being driven by the AI and not by a human. In essence, if a human is driving the car, presumably their persona is wrapped up and bound into the look of the car, while for an AI self-driving car there is only the notion that it takes you where you want to go (performance then being king). Will people be willing and eager to ride inside an AI self-driving car that looks off-putting? Maybe yes, maybe no.
For my insights about the future of marketing in an era of AI self-driving cars, see: https://www.aitrends.com/ai-insider/marketing-self-driving-cars-new-paradigms/
Let’s next consider some of the nitty gritty about modular autonomous vehicles.
I recently participated in the Autonomous Vehicles 2019 (AV19) Silicon Valley summit, doing so in February, and had a chance to speak with Mark Crawford, Chief Engineer at the Great Wall Motors Company. He shared with me and the attendees a glimpse at how they too are pursuing a modular vehicle approach, packed with AI and autonomous capabilities.
Those of you that follow the automotive industry are likely aware of the rise of the Great Wall Motors Company, a Chinese automobile maker. They are the biggest producer of SUV’s for China and made a noteworthy accomplishment in 2016 when they passed the one million mark of cars sold in that year. Being in business since 1984, the auto maker is a household name in China, and gradually becoming known in other countries. In case you are wondering about the name of the firm, they opted to leverage the popular Great Wall of China moniker for the firm’s name.
This all brings me to the topic of MAVS.
Modular Autonomous Vehicle Systems (MAVS) is an up-and-coming buzzword and approach that consists of devising a lower half or chassis/platform upon which you can then interchangeably place a body type or pod, plus infusing autonomous capabilities into the resultant car. It’s a fascinating notion and one that is worth further analysis – I’ll do so in a moment.
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. The MAVS is a variation of AI self-driving cars and can impact the nature of AI self-driving cars and their advent. It’s worth knowing about and being included into your thinking about the future 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 auto makers 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.
For self-driving cars less than a Level 5, 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 true Level 5 self-driving car. Much of the comments apply to the less than Level 5 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 the 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 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. Period.
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/
MAVS and AI Self-Driving Cars
Returning to the topic of Modular Autonomous Vehicles Systems or MAVS, let’s consider how this relates to AI self-driving cars.
First, one of the most essential questions facing any tech firm or auto maker that wants to develop an AI system for purposes of imbuing a self-driving car is whether to use an existing conventional car as your base or opt to craft something anew.
You might recall that in the earlier days of AI self-driving car efforts there was a tendency toward crafting a new kind of car that would house the AI system. Waymo’s initial efforts went in this direction, and it was long rumored that Apple was aiming to do likewise (as were many other of the auto makers and tech firms in this space).
The logic at the time was that you might as well own and be able to fully control the entire car, soup to nuts, as they say, rather than trying to leverage an existing automobile that you likely otherwise had less control over.
There was also perhaps a bit of bravado involved, sparked by the assumption that it would be nifty to have your own branded car. In that case, you could sell the entire self-driving car, along with the bundled AI system for the autonomous elements. Why have to share the revenue and profits with some established car maker when you could do the whole enchilada. Mixed into the business sensibility was a brazen belief that making a car was relatively easy to do.
Some of this brashness was also due to the origins of many of the self-driving car efforts, namely arising from academic and university settings. In such an environment, you often piece together your own prototype, at times entirely from scratch. This led many of the AI developers that shifted into industry to assume they would do likewise at the auto maker or tech firm that landed them.
The harsh reality is that making a car that can be mass produced, and which can withstand the rigors of daily use in the real-world, requires a lot more effort and knowledge than it does to make a prototype in a research lab. Trying to scale-up a prototype to meet all of the regulatory requirements of an actual public roadway allowed car is daunting. Figuring out how to mass produce a car and make money doing so, well, that wasn’t in the wheelhouse of many AI developers.
One concern too was that you would be splitting your limited attention and resources toward trying to solve two different problems at the same time.
You are trying to develop and field the AI autonomous systems aspects, which of itself is absolutely a moonshot regarding trying to get to a Level 5 true AI self-driving car. Meanwhile, if you are also involved in designing and making the car itself, this becomes a huge distraction from the AI side of things. When I say distraction, don’t misconstrue this to imply that making the car itself is inconsequential, in fact it is immensely consequential.
Think about it this way. If you craft some tremendous AI system, but the underlying car stinks, you aren’t likely to get very far along on achieving true AI self-driving cars. A car that cannot run or falters constantly is not much of a sold base to use for the AI aspects. Indeed, I would assert that few would realize that your AI self-driving car was anything wonderous if it was continually breaking down, presumably due to the car aspects of the self-driving car.
That also brings up another difficulty about trying to solve two problems at once. If you did decide to make your own new car, when things go awry, how can you discern whether the problem exists in the arena of the car versus in the arena of the AI system. It would be overly complicated to do so. Things would be simpler if you knew that the car was essentially “perfected” and workable, allowing you to generally rule out issues being in the car arena and instead focus on the AI system.
For a slew of such reasons, most of the tech firms have banded together with auto makers that make cars. Or, you could look at it the other way too, encompassing that the auto makers opted to band together with the tech firms that do the AI systems. Furthermore, they generally are using a base of an existing “perfected” car to build the AI into and onto, such as Waymo’s use of the Chrysler Pacifica minivan for their Arizona tryouts.
Ideally, the AI systems aspects can be ported over to other models of cars, though this has yet to be seen as a readily possible aspect. Right now, the goal is pretty much to get a car working that has the possibility of becoming a true AI self-driving car, and whatever you choose as the base for now is fine. You can worry about the reusability once you’ve gotten the AI systems to work as intended.
For my article about the unlikely use of AI kits for self-driving cars, see: https://www.aitrends.com/selfdrivingcars/kits-and-ai-self-driving-cars/
For why a true AI self-driving car is a moonshot, see my article: https://www.aitrends.com/selfdrivingcars/self-driving-car-mother-ai-projects-moonshot/
For the basis of asserting that AI self-driving cars won’t be an economic commodity, see my article: https://www.aitrends.com/selfdrivingcars/economic-commodity-debate-the-case-of-ai-self-driving-cars/
For my article about the idea that AI self-driving cars will be subject to recalls, see: https://www.aitrends.com/selfdrivingcars/auto-recalls/
I don’t want to leave you with the impression that the base car can be anything that you willy-nilly choose. As mentioned, the base car should at least be something that works and has a track record of working. The next variant would be a newer model of an existing car that works, such that the new changes are mild enough that you can expect the newer model will overall work too. A brand-new car that has never seen the roadways is potentially more problematic.
When I say this, I know that some tech firms and auto makers would argue that they would rather start fresh and redesign a car to be suitable for AI self-driving car purposes. Yes, that’s a certainly attractive approach. We already know and acknowledge that true AI self-driving cars will have quite different interiors, since there won’t be a need for a human driver’s position anymore.
In that case, if you are building upon any existing car, one that is being sold to be used on our roadways today, there is obviously going to be an entire setup for a human driver. It’s only the concept cars that showcase the lack of a driver’s position. It makes little sense today to mass produce a car that has no human driving capacity, since who would buy it? Pretty much nobody, since the car would be little more than a lofty looking paperweight.
It is a bit of a conundrum. We want to eventually all excise out the human driver, which then will allow for the interior of the self-driving car to be completely envisioned. For now, this is not particularly practical since we don’t yet have anything that is able to drive like a true AI self-driving system, thus, a car either needs to allow for a human driver or be potentially sold purely as a human driven car, it’s a matter or practicality.
Logically, you might as well aim at a conventional car that has the human driver position, allowing you to anyway workout the AI side of things, along with having a human back-up driver present in the car. Once you’ve got that running well, it should be relatively straightforward to port over to a specially designed new kind of car that is shaped and built for self-driving purposes.
In that case, you’ve now fortunately kept the situation to one problem rather than trying to solve two problems at once. In theory, you’ve gotten the AI system to work well and thus you won’t need to overly focus on it, and meanwhile the focus goes toward the new kind of car and making sure it works. I don’t want to imply that the porting is going to be easy. It can be very hard, depending upon how the original AI system was devised.
Modular Software Structure Easier for Porting AI System
For some AI developers, if they aren’t structuring their software in a modular fashion, it is going to be a devil of a time to port their AI system over to some other kind of car. The odds are that their monolith AI has a ton of embedded assumptions about the underlying car that was originally used. Finding those assumptions will be like finding a needle in a haystack.
Whether the AI developers were able to think ahead and get ready for a future of porting their AI would be partially based on not just their own skills, but also on the auto maker or tech firm itself. If the auto maker or tech firm is in a pell-mell rush to be the first to achieve a true AI self-driving car, they might apply such immense pressure to the AI development efforts that anything that seems to cause a delay or inhibit progress gets tossed aside. AI developers that might have wanted to take a more modular approach could be overruled and told to just make things work. Being first might be considered a high priority than having something that is portable. As they say, there is little or no style when you are immersed in a street fight.
I’m not suggesting that the strive to be first is mistaken. It could be that the first to succeed gets all the glory and might capture the market, in which case they can deal with the porting aspects later on. The first such true AI self-driving cars are likely to gain huge acclaim and attention. The headlines will herald as heroes the auto maker and tech firm that managed to achieve the vaunted goal.
Generally, few though tend to believe that being first is an applicable first-mover’s advantage in the case of AI self-driving cars. There are many instances in the tech field of those getting to a new technology first that ultimately were not the “winners” and found themselves eclipsed by those that came along after them.
Some claim that the first true AI self-driving car maker is actually going to likely be the one that gets the most arrows in their back, presumably since their AI self-driving car has gotten into untoward circumstances while attempting to get it market ready. The heat and tarnished reputation might put their AI self-driving car into an early grave, and meanwhile some other upstart provides the same capability but has escaped the gauntlet of reputation smashing that the first-move undertook.
For my article about reverse engineering an AI self-driving car, see: https://www.aitrends.com/selfdrivingcars/reverse-engineering-and-ai-self-driving-cars/
For the potential of bugs and errors inside an AI self-driving car, see my article: https://www.aitrends.com/selfdrivingcars/ghosts-in-ai-self-driving-cars/
For my article about the burnout of AI developers and how that impacts their efforts, see: https://www.aitrends.com/selfdrivingcars/developer-burnout-and-ai-self-driving-cars/
For why some AI developers let their egocentric views overtake sound judgement, see my article: https://www.aitrends.com/selfdrivingcars/egocentric-design-and-ai-self-driving-cars/
I’ve dragged you somewhat laboriously through the question of whether to use an existing car or whether to aim at a brand-new car as your base for developing the AI system for a self-driving car.
Let’s try to look at the question in a different light. I’m going to tie things back to the topic of modular vehicles.
Maybe Cram the AI Into the Lower Layer
Rather than making an AI self-driving car by using a whole car, suppose instead you focused on a modular vehicle, specifically a car that is divided into a lower half for the chassis or platform and had a top layer for the pod or body type.
One approach would be to cram all of the AI self-driving car elements into the lower layer. In this manner, you could then mix-and-match other top layers of pods. Those pods would not presumably need any kind of AI capability per se, in terms of the mobility for the self-driving car. This makes it simpler to make different kinds of pods.
This approach assumes that you can have the AI self-driving car capabilities self-contained into the chassis. Maybe this is feasible, maybe not.
For example, let’s assume you are going to use radar, LIDAR, ultrasonic sensors, cameras and the like, all part of the sensory apparatus needed to enable the self-driving car and the AI to navigate and analyze the environment around the self-driving car. Where will those sensors be?
If you put all of those sensors solely into the chassis, this might be problematic. The LIDAR usually needs to be on top of the entire vehicle and be given a 360-degree unimpeded ability to scan the environment. Many of the other sensors are likewise most effective when placed at a position higher up on a vehicle. Would you be able to do this if the sensors were all contained solely within the chassis?
As such, you might have little choice other than to split the AI system across both the chassis and the pod. You might be able to put most of the guts of the AI system into the chassis, and then have the so-called peripheral devices like some of the sensors built into the pod. Some of the sensors might reside in the chassis and some of the sensors would reside in the pod.
In that case, you need to ensure that all of the pods have those sensory devices baked into them. You also need to make sure that however you connect the chassis and the respective pod will allow for the interfacing of the sensors that are on the pod with the guts of the AI system that resides in the chassis. One possible downside would be any latency introduced by using that connecting interface. Though, you could make the same argument about even a conventional car that has an “integrated” AI system, meaning that how the sensors are interconnected might suffer a similar kind of latency.
Can the chassis by itself roll around and act like a self-driving car? It depends once again on the nature of the sensors and where those sensors are placed. If some of the sensors are going to be contained in the pods, the chassis is essentially blind without having a mated pod. It could be that the chassis has sufficient sensors to be able to move around to some lesser degree, and not be able to fully travel on conventional roads without having a properly mated pod.
Speaking about the pods, we would now have the handy aspect that we could have one kind of pod that accommodates human passengers, and have a different pod that accommodates goods transportation. This does away with the earlier problem of trying to make one car that can do two different things. We now have a self-driving car that could be outfitted with the passenger pod for purposes of doing say ridesharing and being re-outfitted with the cargo carrying pod when you wanted the AI self-driving car to transport goods.
The nature of the removal or disconnecting of the pods, along with the coupling or adding on of the pods to the chassis will be crucial in this setup. Suppose you own a fleet of AI self-driving cars. During the day you might want 90% of them to be outfitted for passenger use. Late at night, you instead want to use 70% of them for cargo carrying and keep just 30% in a mode for passenger purposes. This means that at some point during a day, you will bring the fleet to a warehouse or some kind of location that has your pods, and you’ll want to make the switchovers there.
If it takes hours to make the switchover of each AI self-driving car, you’ll be in a quandary. Is it better to lose the potential revenue of those AI self-driving cars doing their ridesharing in order to “waste” the presumably no-income time of the switchover, in hopes that the money you’ll make for those AI self-driving cars as cargo carriers will be sufficient? Plus, you’ll need in the morning to do the switchover once again.
This kind of switching is only going to make dollars-and-sense if the switch over is relatively fast and easy to do. If the switchover is long to do, that’s a downside. If the switchover is complicated, that’s a downside in that you might have heightened costs involved in just doing the switchover. We need to also consider whether the switchover can be botched, namely that in the act of switching pods, it might be overly easy to damage either the chassis or the pod, thus undermining the potential ROI (Return on Investment) and having to continually replace or repair those chassis and pods.
On the topic of safety, it will be crucial too how the pods are attached to the chassis.
Suppose the AI self-driving car is zipping along on an autobahn at over 100 miles per hour. The AI detects debris up ahead. To avoid the debris, the AI commands the self-driving car to make a radical swerving motion. There is cargo inside the pod, rather than humans, and so the AI is able to make a more radical maneuver, realizing that it is merely cargo and not going to impact any humans that otherwise could not withstand the G-forces involved.
Will the attached pod be securely enough fashioned to handle this maneuver? If not, the pod might slide off the chassis, which obviously would be detrimental, or it might go askew, which is not a desirable status. In a conventional car that is not a modular vehicle, you presumably don’t think about the chances that the top part of the car is going to unexpectedly come off the bottom part of the car.
This brings up some notable aspects about the Machine Learning or Deep Learning that might be different when aiming at a Modular Autonomous Vehicle System. Do you train the Machine Learning or Deep Learning on a particular kind of pod, such as the passenger pod, and then it is instantiated when that pod is placed onto the chassis, and do likewise separately for the cargo pod, or do you mesh together the Machine Learning and Deep Learning for both types of pods?
I mention this because of my example about the AI self-driving car on the autobahn.
Recall that I said the AI knew that the cargo pod was being used and could therefore make more radical maneuvers. The Machine Learning or Deep Learning might or might not have realized that those differing pods can allow the AI to treat the driving task differently. AI developers might need to explicitly establish differing conditions and aspects to make sure that the Machine Learning or Deep Learning is “aware” that the self-driving car is going to be able to act differently depending upon the pod that is attached.
Indeed, I would argue that the entire AI system of the self-driving car would need to be architected toward the notion that there are going to be different kinds of pods being used. I’ve so far only mentioned two types of pods, one for passengers and one for transporting goods. There are likely going to be other kinds of pods that we might devise. In each instance of a pod type, the AI will need to be somehow revised or retooled, along with doing the various testing and redeployment efforts.
When the Ridek was patented, it was envisioned that the buyers might rent the Modek (the chassis) and possibly buy the pod or Ridon. That’s one way to do things. It could be the other way in that you opt to buy the chassis and rent the pod, allowing you to later on switch to a different kind of pod. Or, the entire setup of both the chassis and a pod is sold, perhaps even selling multiple pod types to someone that wants to have a complete set. It’s a mix-and-match opportunity.
On a related note, suppose the chassis was made as a kind of “open source” that you could then create your own pods and use those on the chassis itself. This might allow for a multitude of varying kinds of pods. An entire ecosystem of pods might emerge. Of course, the auto maker or tech firm that made the original chassis is then taking a chance and assuming that those pods are going to be suitable for the chassis. If someone does a rotten pod and the chassis gets into an untoward situation, it could be like the bad apple in the barrel that spoils the whole bunch.
Shifting gears, let’s briefly consider the matter of having a multitude of these MAVS and how they might work together as a team of virtualized ground-based mobility devices.
I’ve mentioned previously in my writing and speaking that we’ll gradually be leveraging a kind of Swarm Intelligence (SI) by having interacting AI self-driving cars. This brings together advances in Distributed AI (sometimes abbreviated as either DAI or DI), along with the efforts of dealing with Multi-Robotic Systems (MRS). In the case of AI self-driving cars, assuming we can achieve individualized behaviors that are sufficient, the next step would be to have them working together in various ways.
For example, you might have them sharing roadway and infrastructure information with each other, allowing any single AI self-driving car to achieve what I call omnipresence. You might have the AI self-driving cars aiding each other in a pack or group manner. This could include a caravan of AI self-driving cars and/or the use of AI self-driving cars for platooning purposes.
Mark Crawford provided a grand vision at AV19 of multiple interacting MAVS that would collaborate with each other. This is the kind of visionary perspective that we need to be thinking about and I applaud him for his efforts in progressing on these matters.
I realize that for many of the auto makers and tech firms it is hard right now to be taking a macroscopic view when you are in the trenches and trying to get your AI self-driving cars to work. Ultimately, it is crucial that we begin identifying a future that we can layout, and be creating a path now to build toward that future. Let’s not get ourselves painted into a corner by the AI systems we strive to build today. I’d like to hope and aim for architecting AI system for self-driving cars that will grow and mature and evolve as the advent of AI self-driving cars proceeds.
For my article about caravanning and platooning, see: https://www.aitrends.com/selfdrivingcars/traveling-in-vehicle-caravans-and-the-advent-of-ai-self-driving-cars/
For more about swarm intelligence, see my article: https://www.aitrends.com/selfdrivingcars/swarm-intelligence-ai-self-driving-cars-stigmergy-boids/
For the use of federated Machine Learning, see my article: https://www.aitrends.com/selfdrivingcars/federated-machine-learning-for-ai-self-driving-cars/
For my article about collaborative robots, see: https://www.aitrends.com/selfdrivingcars/ai-cobots-and-exoskeletons-the-case-of-ai-self-driving-cars/
For the importance of safety and AI self-driving cars, see my article: https://www.aitrends.com/selfdrivingcars/safety-and-ai-self-driving-cars-world-safety-summit-on-autonomous-tech/
Should AI self-driving cars be divided into two halves like a magician does on stage? When you consider the nature of what a car is or does, it makes sense that you could divide it into two layers, unlike how humans themselves are made.
Dividing up a car into a lower layer and an upper layer might be handy twofer. You can mix-and-match the bottom layer with a multitude of different use-case pods. Though I didn’t mention that you could potentially have differing chassis too, that’s another possibility. You might have a workhorse chassis that is less nimble and slower, while you might have a chassis that is turbocharged and able to carry heavy loads or go at extremely fast speeds. This means that you have many choices of mixing varying kinds of chassis with varying kinds of pods.
To some degree, this dual layered approach enters into an unknown territory for cars. We don’t have today any mass production large-scale examples of cars that are built and sold in this manner. We do though have an enormous industry of trucks that haul a wide array of freight vehicles, including flatbed trailers, step deck trailers, refrigerated trailers, dry trailers, and so on. Thus, it is certainly well-established that having a mix-and-match capability can be prudent.
Modular vehicles are taking a step toward the future by becoming autonomous modular vehicles. The AI systems that are being devised for AI self-driving cars can be architected for handling modular vehicles and bringing modular vehicles into the autonomous realm. These are exciting times and we’ll all need to be keenly attentive to what kinds of AI self-driving cars come into the marketplace and which ones gain prevalence. AI might just make modular vehicles into a big triumph.
Copyright 2019 Dr. Lance Eliot
This content is originally posted on AI Trends.
Let’s block ads! (Why?)
Source: AI Trends