4

Crazy-Looking Futuristic Autonomous Concept Vehicles: Reality or Fiction?

 2 years ago
source link: https://medium.com/@olley_io/crazy-looking-futuristic-autonomous-concept-vehicles-reality-or-fiction-d1079475a384
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Crazy-Looking Futuristic Autonomous Concept Vehicles: Reality or Fiction?

We all like to imagine some not-so-distant utopia where we’re chauffeured around the world while we accomplish our everyday tasks. Automakers have been hinting at a vehicular revolution of the form and function of vehicles for years, and hired many talented designers to give us something to hang in our bedroom wall:

2010 GM EN-V Concept (Source)Audi’s Truck Project, “Plan B” (source)Volvo’s Autonomous Multi-Segment Tractor-Trailer “AT404” Rendering (source)

And even better yet, automakers and robot builders have even created some of prototypes for us to see, experience, and read about first hand:

Toyota’s e-Palette Unveiled at CES 2018 (source)

But, if you’re anything like me, you don’t believe all the hype. There’s no way we’re going to catch an Uber in a 2-wheeled, self-balancing pod. Nor are we going to have an 8-wheeled fully-equipped office that drives us to our next meeting. We can’t possibly ride in 20-segment buses from New York to LA that have their own hotel suite in each segment. And why would we have grocery delivery robots with some odd combination of wheels when a delivery car works just fine?

0*junq8c5iZmsIRKrs
Starship Robotics’ Robot Delivery Vehcile (From ’s Article HERE)

…But what if we could? What if we do the thought experiment on how these crazy contraptions might actually work, and what if it’s not so unreasonable for someone to make these a reality?

I mean, sure, we can come up with plenty of technological mumbo-jumbo to describe how someone might build some publicity-stunt-vehicle and watch it drive in a closed course, but our regulatory bodies would never let that thing hit the streets, right? Again, let’s do the thought experiment on what it might take for both the public and the regulatory bodies to consider these creative monstrosities “safe.”

China’s Traffic Straddling Bus (source)

Safety

Let’s first define “safety.” Safety for automobiles is a measure of how confident you can be that a occupant of a vehicle will get from point A to point B without bodily or property harm. We’ve added features to our automobiles since conception to increase the safety of our vehicles, and we will continue to make improvements. Here’s a quick list of some of the technological advancements that have improved the safety of automobiles over the years:

  • Seat Belts
  • Airbags
  • Aerodynamic and Down Force Improvements
  • Independent Suspension
  • Tire Compounds
  • Disk Brakes
  • Fire Retardant Materials
  • Chassis Rigidity Technology
  • Water and Oil Cooling Systems
  • Front, Rear, and Side Crash (Crumple) Zones
  • Sensors for Tire Pressure, Engine Temp, etc
  • Window Defroster
  • Traction and Stability Control
  • Anti-Wheelie Control (Motorcycles)
  • Electronic Suspension
  • Driver Indicators
  • Emergency Services Notification
  • Adaptive Cruise Control

All of these technologies have allowed vehicles to stop, go, and turn more responsively to driver inputs, and in the event of a collision, have saved passengers from additional bodily harm.

Safety and Race Cars

Almost all advancements in automobile technology come from racecars. Everything described above has its origin in racing. All of these technologies have a purpose for either making a vehicle maneuver around a track faster or save the life of the driver of the racecar in the event the vehicle loses control.

It’s worth noting that there are plenty of racing technologies that didn’t make their way into passenger vehicles. My personal favorite is from Chevrolet Engineer Jim Hall; where in order to make a Can-Am race car go through turns faster, he put two snowmobile engines in the back of the car and a plexiglass skirt from the body of the car to the ground, so that it could suck air out from under the car and create a vacuum between the underbody of the car and the ground. It was said that this car could drive upside down. This was clearly outlawed in racing almost immediately, but you have to love the innovation:

Jim Hall’s Chaparral 2J (Source)

Here’s a few other crazy concepts from racing:

GM’s Maurice Olley’s Patent For Independent Rear Suspension (Source)

But even racecars were constrained to 4-wheels (motorcycles to two in a straight line), so there’s potentially more to learn about how cars with different configurations might behave in traction-limited circumstances.

Self-Driving Cars and Safety

But safety means something different for Self-Driving Cars. I wrote about this extensively in This 5-Part Series detailing how we can be confident that self-driving cars will be safe. In short, safety for self-driving cars is our confidence in the vehicle’s software and hardware to make the best possible decision in every circumstance. This means that the vehicle needs to trust what it is sensing, be sure that the path the vehicle plans is the best path and one that the vehicle can execute, and then trust that once the decision is made, the vehicle will act out that plan. This is the core of the sense-plan-act paradigm in robotics.

In order for governing bodies and the public to have confidence the autonomous vehicle (AV) is safe, we need statistics and metrics to prove it to us. Likely some institute will standardize on some set of scenarios and metrics around the performance of the autonomous system in those scenarios, but that is yet to be seen. Once we have a measurable standard for “safety” of autonomous vehicles, we can then make a claim on the “safety” of vehicles.

Today we use the “incident report” or “disengagement report” as a metric indicating how safe autonomous vehicles are. This is a metric that gives a amount of incidents per miles driven, and we often compare that number to the statistics we have about the number of accidents per miles driven of standard vehicles. This can be a misleading comparison through, since every time the safety driver “disengages” autonomy, another incident is checked, which a driver may do so whether or not the car was about to have an accident, just to ensure the safety of those involved.

For the purposes of this discussion, let’s pretend we’ve determined metrics for autonomous vehicle safety as described previously, and let’s use this loosely defined metric to compare the safety of our crazy concept vehicles. Let’s also assume that we’ve deemed standard, 4-wheel autonomous passenger cars as “safe.” This will make more sense as we go on.

Path Planning

The core of our safety problem lies in Path Planning. We assume that the sensors that are used on the crazy concept vehicles are the same sensors that are used in our hypothetical “verified safe” self-driving cars described above. We assume that the software used to Simultaneously Localize And Map (SLAM) is also the same (safe!). We also assume that the sensor fusion is identical. We trust that the actuators and PID control systems for those actuators will actually do what they’re told.

Then the only difference now is how the vehicle plans its path, since we assume the inputs to the path planner are the same as a standard AV. More generally, we’re discussing how the vehicle plans what commands to send to its actuators. I say this because in a standard vehicle you have three main commands that are sent to actuators to drive the vehicle:

  • Brake Force (%)
  • Accelerator Force(%)
  • Turn Angle (Degrees or %)

Sometimes, these actuations come with a velocity or acceleration component to get to those set destinations. However, the time that is spent in “transient,” or in a change from state-to-state of the vehicle, should be minimized because solving for “steady state,” or no chance in outputs of the planner, is a much simpler problem.

We will not talk about the specific algorithms used in path planning, since this topic has many hundreds of textbooks written about it. I can recommend the following for some “light” reading on the topic:

https://github.com/mithi/robotics-coursework/blob/master/BOOKS.MD

Path Planning for Nonstandard Vehicles

In a nonstandard vehicle, you could potentially have many more outputs:

  • Turn, Acceleration, or Braking per wheel or wheel pair
Jeep Hurricane All-Wheel Steering (source)
  • Ballast or Gyroscopes
Chinese “Gyrocar” Prototype by Zhu Lingyun (source)
  • Independent Suspension Control
Bose and Later ClearMotion’s Skyhook Fully Independent Suspension (source)
  • Rolling, Yawing, or Pitching body segments
BMW’s Self-Balancing, Self-Driving Concept Motorcycle (source)

Can you think of any others?

Each of these additional outputs complicates the path planner. By complication, we mean computation complexity, which could show itself in three ways. Firstly, this could mean more time is needed to compute the planning algorithms, which probably makes the vehicle less safe because it slows its decision process down. This could also mean larger processors are needed, eating more power from the vehicle and lowering the range. It could also mean more simplification of the algorithm is required, which could again mean the algorithm might make an incorrect decision and thus reduce safety.

Depending on the path planning algorithms employed, some algorithms could become some number of additional outputs more complex, and some could scale exponentially with the number of additional outputs. This is bad news for the safety of our autonomous vehicle.

So, we should strive to limit the number of actuators to only the necessary ones for the vehicle to serve its function. 4-wheeled cars already do this several ways. One is by having only one linkage that turns both front wheels. Another is by setting the camber and caster angle of the front tires to a set location (or one that has consistent geometry). A car could choose to have independent turning, camber, and caster of each wheel, which would certainly improve the performance of the vehicle, but that would take solving the for the ideal state in every given scenario, which is computationally complex.

There are some instances in existing 4-wheel vehicles that complex actuation is solved in the “act” paradigm. ABS, for example, takes one command of “brake this hard” from its path planner (the human or robot) and reads the wheel speed of each wheel to determine how hard to actually apply the breaks to each wheel. Traction control, wheelie control, torque vectoring, and independent suspension work this way. By solving this in the “act” section, it takes the burden off the path planner.

ABS Diagram (source)

So, we first limit the number of actuations possible to limit the outputs from the path planning function. Then we further group these actuations in ways that can be disconnected from the planner itself. For example, we might group all “brake” functions of each wheel into its own automated section, so the path planner says “brake this hard,” another system determines how hard to apply the brakes to each wheel. If this function requires more than 2–3 inputs from the “sense” stack per actuation, then it likely cannot be simplified enough to be its own system and needs to be a part of the path planner.

Ideally, we get to a state that has only 3 outputs from the path planner: Accelerate, Brake, and Turn. Then, smaller and computationally simple subsystems will determine how much of each to apply to each actuator. Good candidates for these simpler subsystems are as follows:

So, let’s assume that all our vehicle path planners can be simplified as such: the inputs of the “nonstandard” path planner are the same as the general AV case. The outputs are still brake, acceleration, and turning, exactly as they would be with a standard AV. There are additional subsystems that handle computationally “simple” actuations, and we put them (for discussion purposes) in the “act” paradigm. These subsystems are specific to our vehicle, but we’ve chosen straightforward and logical groupings of actuations, that can be modeled consistently and repeatably. This is key for the next stage of our discussion.

The “Black Box” of Path Planning

I said we wouldn’t get into the nitty-gritty of path planning (see: Kalman Filtering and Bayesian Statistics), but there’s one topic that cannot be ignored: How can the path planner determine what the best route for these nonstandard vehicles is in any given scenario?

This is where things get fun, and a little crazy.

A standard passenger autonomous vehicle’s path planner can know exactly what it is capable of in any given scenario by using a field of study called “multibody vehicle dynamics.” You can read more on this on my article here.

Years of race car development, high performance multibody dynamics software (like MSC Adams or CarSim), and SAE standards have helped us understand pretty well what 4-wheeled, constrained vehicles will do in many scenarios. Engineers take some simplification of this very complex problem and plug it into their path planner to solve for ideal paths.

If a car is operating in its 99% use case, these algorithms do not have to work very hard, since it does not have to calculate the limit of the vehicle. However, in the case where the car must make an emergency maneuver, these algorithms must function with precision, to avoid an incident while staying within the limit of the vehicle. If the car inaccurately calculates the limit of the vehicle, it may go into an uncontrollable slide (overestimation) or it may have missed a exit path to a tragic accident that the car was actually able to execute (underestimation).

It’s worth noting that brilliant minds like Chris Gerdes’ Sandford Dynamic Design Lab are trying to better understand how to leverage sliding in various scenarios to increase the possibilities of a vehicle’s path, by creating an automated drifting DeLorean, but that is a story for another time.

MARTY, the Autonomous Drift DeLorean (source)

Multibody Vehicle Dynamics for Nonstandard Vehicles

So how do we determine what a crazy concept car can do without all of the historical study that’s been done before? We’d start with plnty of simulations with multibody dynamics software to determine the limit of the tires of our vehicle under various states. We’d probably do a good amount of linear algebra too (see: Solving Jacobian Matrices). Then we’d need to test our findings on prototype vehicles under various scenarios. This involves building mule vehicles and potentially crashing them. Once we have tweaked our models from the test results, we probably have an extremely complex multi-dimensional series of algorithms. This would be too computationally complex to put “in-line” within the AV’s path planner, so we’d need to simplify.

Bicycle Model Simplification of a 4-Wheel Vehicle (source)

I won’t discuss all of the methodologies to simplify vehicle dynamics problems (mostly because I know very few of them), but one methodology used for drones is the “lookup table” to estimate the state space of the vehicle in a constrained number of scenarios. For example, we might set up 10 different values of slopes the vehicle might be traversing, 4 different road conditions, and 20 different turn radii. This would give us (10 x 4 x 20) 800 different limits of the vehicle for each output of the path planner (1600 if turning either direction). In actuality, this number is much higher, since the number of different scenarios we care about is much larger and the step size is much smaller. It will be higher still due to the complexity of the states that the nonstandard vehicle could be in. Since we’ve chosen “straightforward and logical groupings of actuations that can be modeled consistently and repeatably,” we will still get an n x m x o dimensional lookup table in memory that the path planner can simply pull from to determine limits of its outputs in each scenario.

Again, there are a number of different ways to approach this problem, but in general, we need to create simulations, test those simulations, and then create a simplified algorithm that allows us to approximate the results of those tests and simulations. Likely, those tests will occur on closed tracks, such as racetracks, so we’ll get back to that racing heritage one way or another.

As you can imagine, this process takes quite a long time, so we don’t anticipate getting to call a unique vehicle “safe” anytime close to the beginning of its development.

Quick Note on Machine Learning

There are many that advocate for building a simulation or mule vehicle and letting it “figure out itself” what it is capable in any given scenario. I won’t touch much on this topic since it’s very complex and I’m certainly no expert. Many argue whether or not this would be a more effective approach to traditional multibody dynamics approaches. But as an astrophysics professor that designed how satellites open to stop rotation once told me, “you don’t ‘learn’ physics, you use the equations.” There will likely be some element of machine learning associated with determining what the crazy concept vehicle is capable of, but we will leverage multibody dynamics equations, simulations, and testing as the backbone of what the AI spits out. ML will likely get us better models quicker, not eliminate the need for this methodology.

Putting it All Together

So, what have we done? We’ve leveraged the same elements of the AV Stack as a standard 4-wheeled passenger AV. We’ve ripped out the part of the path planner that determines the limits of the standard vehicle and replaced it with one for our nonstandard vehicle. We’ve also modified or added additional subfunctions in the “act” paradigm that consist of “straightforward and logical groupings of actuations that can be modeled consistently and repeatably.”

Certain concept vehicles have their own set of complexities. For example, if you’re building a 2-wheel, autonomous, self-balancing bod, like such:

Segway and GM Prototype Vehcile (source)

You’d have to add a self-balancing control subsystem that takes brake, acceleration, and turning outputs from the path planner, and translates them into only brake and acceleration actuation commands for each wheel, all while keeping the vehicle upright. Through simulation and test, you determine the limits of the vehicle for brake, acceleration, and turning, taking into consideration what the vehicle must be able to do to right itself in any given scenario. For example, in order to stop or slow the vehicle while traveling at speed, you need the wheels to accelerate quickly to put the vehicle’s center of mass behind the contact point, keeping it balanced, while it slows down. Think about trying to run while balancing a meter-stick on the palm of your hand. You’d need to quickly shift your hand forward if you wanted to stop. You might imagine that if you are maxing out the RPM of the wheels, you wouldn’t be able to stop without tipping forward, because you wouldn’t have enough power or wheel speed left to put the vehicle in the right position to stay balanced while slowing or stopping. All this would need to be factored into the path planner.

Another example is the automated office space:

Ikea’s Space10’s “Office on Wheels” Concept (source)IDEO’s “Work on Wheels” Concept (Source)

For this one, the highest priority is preventing the passenger from getting motion sickness, which is common of passengers reading and working in moving vehicles. There are a number of strategies for inside the office space to help with this, but I’ll talk about the one that applies to the AV stack: Fully active suspension.

Active Body Control Diagram (source)

Fully active suspension works to eliminate bumps in the vehicle by anticipating them and moving the wheel with an actuator up or down to eliminate the transfer of the bump into the chassis of the vehicle and thus into the occupant’s body. This type of suspension also either keeps the vehicle level while turning, or even makes the vehicle lean into turns so that the force vector experienced by the passenger by gravity, centripetal, and front-to-back accelerations goes directly through the center of the passenger’s body.

Toyota’s i-Road Concept Leaning into a Turn (source)

You’d need to add the control of each independent suspension to the “act subsystem,” and update the path planner to produce a value for turning, braking, and accelerating that minimizes the resulting forces the passenger feels. Of course, there will still be a limit that consists of the absolute capabilities of the vehicle in emergency situations, but the general use case (the 99%) will want to keep the passenger comfortable and free from motion sickness during their commute.

Will it Actually Happen?

We did it. We created a “safe” futuristic crazy concept vehicle. Why isn’t everyone doing this?

As you can probably imagine, all that math, simulation, and testing takes significant time and resources, and that’s just for adding automation. The darn thing would still need to be mechanically tested, which is an entirely different project.

Since we already have models that work for the standard vehicle configurations that have been here for over a century, it’s pretty easy to use those. Don’t fix what’s not broke, right? Since most autonomous vehicles are currently just retrofits of existing production vehicles anyway, building a brand-new vehicle would have a huge investment associated with it.

Why would we pour all the energy in designing, developing, and testing these crazy vehicles? Have we justified the benefit of doing so?

Shape-Shifting Tractor “Red Valtra” Concept Rendering (source)

Likely, the answer is we won’t do this anytime soon, simply because the market does not call for it. We will certainly see incremental changes in vehicle design and function, but it is unlikely that we will see a step-function modification of traditional vehicle design. However, all it takes is one crazy “Jim Hall” character to make something so much better than everything we’ve seen before and then our childish dreams might just become a reality. Maybe that’s you!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK