Tag: self-driving cars

Systems Engineering on AVP

You know how it can be a real challenge to understand the complexity in emerging multi-modal and automated transport systems?

By harnessing Systems Engineering best practices, our Systems Engineers at the Connected Places Catapult (CPC) use their expertise in systems requirements gathering, safety management, and verification and validationensuring that all aspects and interactions in the AVP system are clearly defined, integrated, evaluated and tested, thus improving our ability to deliver a safe, efficient and innovative system.  

Systems Engineering is an established practice capable of delivering technically complex systems, and Systems Engineers swear by the V lifecycle model, which shows the logical relationship between the different System Engineering activities.

In the V model, time and system maturity proceed from left to right:

System Engineering “V” diagram

In each stage of the system life cycle, the Systems Engineering process iterates to ensure that a concept or design is feasible, and that the stakeholders remain supportive of the solution as it evolves.

The process is applied sequentially, one level at a time, adding additional detail and definition with each level of development.

1. Concept Development

The concept development is the first step of the life cycle of the AVP project. This stage explores concepts, identifies stakeholders’ needs and proposes viable solutions.

It includes activities such as:

•        Concept of Operation (ConOps)

•        Systems Engineering activity Plan

•        Market Analysis

•        Competitor Assessment

•        Regulatory framework

2. Requirement Management

Requirements definitions are the key to success in the design and development of any complex system. Our Systems Engineers have carefully elicited requirements from all the project stakeholders to ensure the final product meets everyone’s needs, from technical feasibility to budget considerations and testability.

The total set of requirements encompasses the functional, performance, and non-functional requirements and the architectural constraints.

3. System Architecture

The architecture of a system is its fundamental structure. The purpose of drawing an architecture is to define a comprehensive solution based on principles, concepts, and properties logically related and consistent with each other. The architecture defines the system boundary and functions, from which more detailed system requirements can be derived.

This step of the cycle is focused on developing:

•        System Level Architecture

•        Functional Architecture

At the start of the AVP project, both of these architectures were drawn. The system level architecture refers more to the overall system and its operating environment. The functionalities that enable the AVP technology are mapped on the functional architecture, based on the Autoware ROS and showing modules such as perception, sensor fusion, path planning, and others.

4. System design and development

Once the initial opportunities and constraints have been identified in the steps above, it is time to create and describe in detail the AVP system to satisfy the identified needs.

While the Parkopedia Engineers work on developing the AVP system in accordance with the ConOps, Requirements and System Architecture, the Systems Engineers at the CPC focus on the functional system analysis and producing the Safety Case for the AVP testing.

This lifecycle step expands on ISO 26262, which addresses the functional safety in road vehicles. The analysis of the system level safety is carried through system-level functional analysis, such as the Failure Mode and Effect Analysis (FMEA) and the Hazard Risk Assessment (HARA) , which results in providing the system safety goals (translated as the safety requirements for the system). These form the system safety argument for the Safety Plan for the AVP project.
This step is crucial to ensure the risk is minimised if and when the system fails. Every malfunction leads to a warning and degradation strategy and the safety driver should be able to gain control of the vehicle.

Note: the system analysis also involves reviewing all of the previous deliverables as the design is being developed.

5. System Integration

The AVP system is made of different system elements provided by different parties:
– The vehicle is provided by StreetDrone
– The software, application and maps are provided by Parkopedia
– The localisation system is developed by the University of Surrey

This step ensures that all of the disparate system elements integrate to create an effective whole and allows the different teams to work in parallel confident that all of the pieces fit and work together.
The interface management activity relate to the steps taken to integrate the different architecture elements:

  • Reviewing and refining the previously mentioned deliverables (ConOps, System Architecture, Requirements, FMEA, HARA)
  • Assessing the criteria and methods for Requirements verification and validation (Analysis/Inspection/Test/Demonstration)
  • The Interface Control Document (ICD), which describes the integration strategy of the AVP system. This is a live document and is continuously updated until the end of the system development and testing.

6. Test & Evaluation

Prior to driving in the desired environment, the vehicle has to demonstrate that it is capable of safely navigating and responding to diverse situations and scenarios, such as emerging pedestrians, vehicles, obstacles, etc. By combining simulation and testing in a real environment (open field track and car parks), the AVP system can be validated.

This step focuses on ensuring that the developed system is operationally acceptable and that the responsibility for the effective, efficient, and safe operations of the system is transferred to the owner.

  • Can the system be tested, demonstrated, inspected, or analysed to show that it satisfies requirements?
  • Are the requirements stated precisely to facilitate specification of system test success criteria and requirements

Testing will always be performed with a highly trained safety driver, who will monitor the vehicle behavior at all times and ready to take over in the event of a failure. An engineer will monitor the path on a HMI, so that the safety driver is not distracted. The system must be able to detect and respond to a wide range of static obstacles in the testing environment.

Prior to testing, some activities need to be completed to ensure the safety of the AVP system:

Safety Plan

It examines the evidence required to show that acceptable safety has been achieved for any given testing activity, and how that evidence is to be collected, such that when all the evidence is taken together, there is a convincing argument that the project as a whole is safe.

Safety Case

It summarises the evidence collected prior to commencing Autonomous Valet Parking testing in accordance with the Safety Plan. There will be a Safety Case for each test phase: testing in a controlled environment (open field track), testing in car parks and the demonstration.

RAMS:

This document sets out the safety procedures that all participants are required to follow during testing of the autonomous control system and ensures the requirements and procedures are read and understood by all involved in the trial, and adhered to at all times. The Risk Assessment for the trial is also included in this document. Similarly to the Safety Case, each testing phase will be prepared with a RAMS.

After testing, the requirements are reviewed and given a pass/fail mark depending on the acceptance criteria set. In both cases, a justification needs to be provided.

Once again, the previous deliverables are reviewed and refined as required.

7.Operation and maintenance

The AVP system has now been tested in different test environments and settings. The system is ready to be deployed, and as part of this activity, several demonstrations are organised as evidence of the operational effectiveness of the deployed AVP system.

The Systems Engineers carry the below activities, verifying and validating the concept one last time:

  • RAMS
  • Safety Case close out
  • Verification and Validation close out
  • Review and refine as required previous deliverables
Systems Engineering Process Flow Diagram

8. Conclusion

The self-driving car industry is a fast-moving and uncertain environment, which makes safety the number one priority. This is also why the AVP project consortium is encouraging the industry to work together, collaborate, share use-cases and lessons learnt. Self-driving cars have the potential to ensure safety of passengers, reduce road congestion, drive smarter and in a more sustainable way. By implementing a robust Systems Engineering process, the self-driving car industry can mitigate risks and drive society safely into the future.

First Autonomous Test

We successfully completed our first tests at Turweston Aerodrome last week.

Unloading the StreetDrone.ONE

The plan was to check and ensure the robustness of the drive-by-wire system, to train our safety drivers and to do basic path following.

We also took the opportunity to collect some data from the ultrasonic sensors that are on the StreetDrone.ONE which we will use for system safety.

Ultrasonic data collection
Drive-by-wire testing

For testing the drive-by-wire system, we carried out a number of test runs using teleoperation from the driver. We drove on the track forward, backward and changing steering at various speeds. The system performed satisfactorily. We also performed a full brake test to work out a safe driving speed and stopping distance in a case of emergency stop. Further details are presented in this blog post.

Path following with PID feedback control and a basic GPS and IMU localisation

On the final day, we tested a basic path following to make sure everything worked together. We integrated the drive-by-wire (dbw) system with a path follower, PID motion controller and a basic gps and imu localisation in this open space environment.

We managed to achieve the objective of testing the dbw with the feedback control for the path following. However, precision was not there as we expected. The basic imu and gps sensor localisation would not give very accurate positioning and tends to drift away or jump around to within 5m accuracy. To resolve this issue, we are working on a better localisation using RTK GPS (like a simpleRTK2B) using RTK corrections over NTRIP.

Our next test will focus on path following using the high quality localisation and we also hope to start with path planning within the open space. More updates will follow!

Why Autonomous Valet Parking?

Why Autonomous Valet Parking, not robo-taxis, will lead the adoption in self-driving technology

Looking back on 2018, the press have reported it to be the year when the hype around self-driving “came crashing down” with the first driverless fatality in March 2018. The first driverless taxi service was rolled out but it didn’t quite have the impact that the industry was expecting.

Research on self-driving cars has been continuing for more than 30 years, starting with the pioneering work by Ernst Dickmanns on the PROMETHEUS project. A lot of work has taken place since then and is still ongoing, but the question remains: why has the problem of self-driving still not been solved in 30 years?

In a sense, the problem has been solved and autonomous driving is already here.  Heathrow pods, Greenwich pods, Easymile, May Mobility are live now, and many others are already in production.  What sets these simpler systems apart from the systems being developed by Cruise, Argo, Aptiv, Waymo, Uber, Aurora, Lyft, FiveAI and others, is that the environments into which they are deployed are constrained in some way.  

The biggest challenge faced by the developers of general purpose self-driving technology is the requirement to handle complex environments with unpredictable interactions. Waymo’s director of engineering recently summarised the challenge by saying that the final 10% of technology development is requiring 10x the effort required for the first 90%.  Where the environment is simpler or constrained, then self-driving technology reduces to that of autonomous mobile robots like the kiva.

A more realistic approach to deploying self-driving is therefore needed. The two major places where self-driving car technology are likely to be deployed are on motorways – constrained environments with very strict rules, limitations on cyclists and pedestrians – and low speed restricted environments like retirement villages and car parks.

Autonomous Valet Parking (AVP)

Parking is one of the most important challenges for a traveller, with a parking pain point experienced on 12% of UK journeys (19% in London); the average driver spends 6.45 mins looking for a parking space during each journey. With nearly 1 in 5 journeys already experiencing problem finding a space, AVP represents a way of solving not only the current parking pain point, but also improving the overall parking experience for the other 81% of drivers. BCG’s 2015 report showed that 67% of drivers are interested in “capabilities such as automated searching for parking spots and autonomous valet parking”. Bosch’s 2017 study found that two thirds of consumers want an automated parking feature.

A study by Allensbach in 2016 asking the question “When would you want a driver assistance feature to take over for you?” overwhelmingly showed parking as the most desirable feature.

When German consumers were asked by Bitkom in 2016 when they would be willing to hand over control to the vehicle, the answer similarly was for parking.

The idea of Autonomous Valet Parking is to mimic the Valet function available in selected car parks.  After driving to a suitable drop-off location at or near the entrance of the car park, and similar to handing the keys to a valet, the driver presses the “PARK” button on a specially designed app.  The car then drives off under autonomous control and finds a suitable place to park. When the driver wants the vehicle back, they will press “SUMMON” and the vehicle will navigate to the pick-up zone.

The Society of Automotive Engineers (SAE) classifies this as a Level 4 feature, in that it provides total automation under specific circumstances.

Based on publicly available information, almost all premium OEMs (Daimler, Audi, JLR, VW, BMW) are working on AVP pilot projects . The reason this feature is so desirable is that it:

  1. Improves the parking experience by allowing drivers to be dropped off at a convenient location (e.g. at the entrance of the car park closest to the desired location such as shops or food court), avoiding the inconvenience and stress of having to find a parking space.
  2. Utilises parking spaces more efficiently by tighter/double parking of autonomous cars, and optimally distributing these vehicles within the available parking real estate.
  3. Avoids unnecessary congestion and pollution through real-time dissemination of parking space availability to the connected autonomous cars.

In addition to the economic benefits, there are clear social and environmental benefits. Driving around looking for parking causes stress and frustration, costs, wasted time, missed appointments, accidents and congestion, noise pollution and CO2 emissions. IBM’s parking survey found that in addition to the typical traffic congestion caused by daily commutes and gridlock from construction and accidents, it is estimated that over 30 percent of traffic in a city is caused by drivers searching for a parking space. By reducing the need to circle looking for a space, AVP has the potential to significantly reduce unnecessary congestion and pollution.

With space at a premium in busy city centres, vehicles equipped with AVP technology could make use of the less desirable spaces that are further from the entrance, freeing up parking spaces closer to a desired destination for those without the technology.

In addition to the economic, social and environmental benefits to AVP, there are also some technical reasons why it is a good candidate feature for large scale public rollout.

1) low speeds mean much lower risk of damage to people, cars and infrastructure.

2) a constrained environment means that the complexity of interactions with other actors has the potential to be significantly reduced.  

3) the cost of the required sensor suite and hardware platforms is lower because of the reduced risk and lower speeds.

Conclusion

This consortium’s key objective is to identify obstacles to the full deployment of AVP through the development of a technology demonstrator. It aims to achieve this goal by

  1. Developing automotive-grade indoor parking maps, required for autonomous vehicles to localise and navigate within a multi-storey car park.
  2. Developing the associated localisation algorithms – targeting a minimal sensor set of cameras, ultrasonic sensors and inertial measurement units – that make best use of these maps.
  3. Demonstrating this self-parking technology in a variety of car parks.
  4. Developing the safety case and preparing for in-car-park trials.
  5. Engaging with stakeholders to evaluate perceptions around AVP technology.

Autonomous Valet Parking is a low cost, low risk and high reward feature that consumers want.  It makes sense then to expect that this feature will be the first fully autonomous feature (at level 4 or 5) available to the general public.  Through Parkopedia’s autonomous valet parking project, we are actively working to make that desire a reality.

Autoware

Parkopedia’s mission is to improve the world by delivering innovative parking solutions. Our expertise lies within the parking and automotive industries, where we have developed a solid reputation as the leading global provider of high quality off-street and on-street parking services.

Parkopedia helped found the AVP consortium because we believe that Autonomous Valet Parking will become an important way in which we can serve our customers, by reducing the hassle of the parking experience. Parkopedia are providing highly detailed mapping data for off-street car parks, one of the critical components to a car being able to successfully park autonomously.

To make Autonomous Valet Parking a reality, the consortium first selected the StreetDrone.ONE as its car development platform. We are now developing the software stack to run on our StreetDrone with NVIDIA Drive PX2. The University of Surrey, another founding member of the AVP consortium, provides the camera-based localisation algorithms needed for the car to navigate autonomously inside a parking garage, which will support vision, in addition to LiDAR-based localisation.

Parkopedia has joined the Autoware Foundation as a premium founding member, along with StreetDrone, Linaro/96Boards, LG, ARM, Huawei and others. We believe in open source as a force multiplier to build amazing software, and the AVP consortium is committed to using Autoware as the self-driving stack which will run on our StreetDrone and PX2 to demonstrate Autonomous Valet Parking.

Autoware was started in 2015 by Professor Shinpei Kato at the Nagoya University, who presented it at ROSCon 2017. Autoware.ai is based on ROS 1, which has certain fundamental design decisions that make it impractical for production autonomous cars. ROS 2, backed by Open Robotics, Intel, Amazon, Toyota and others, is quickly maturing, and from the very beginning was designed to fulfill the needs of not only researchers in academia, but also the emerging robotics industry.

Autoware.Auto launched in 2018 as an evolution of Autoware.AI, based on ROS 2, applying engineering best practices from the beginning, such as documentation, code coverage and testing, to build a production-ready open-source stack for autonomous driving with the guarantees in robustness and safety that the industry demands. We want to modularise Autoware.ai and align with Autoware.Auto and move to ROS 2.

We want high quality software, we care about safety and we want to do things right. Parkopedia’s main contributions so far have been to improve the quality of the code by fleshing out the CI infrastructure, adding support for cross-compiling for ARM and the NVIDIA Drive PX2, modernising the message interfaces and developing a new driver to support 8 cameras, among other improvements.

Our plan for 2019 is to keep contributing to Autoware.AI and Autoware.Auto to support the StreetDrone ONE and to make whatever changes necessary to support our Autonomous Valet Parking demonstration.

We’re very grateful to Shinpei Kato and the Tier4 team for open-sourcing Autoware and for welcoming our contributions.