Engineering Autonomous Vehicles and Robots. Shaoshan Liu

A unified cloud platform for autonomous driving. Computer (12): 42–49.

      9 9 Liu, S., Tang, J., Zhang, Z., and Gaudiot, J.-L. (2017). Computer architectures for autonomous driving. Computer 50 (8): 18–25.

      10 10 AutonomousStuff (2017). Lincoln MKZ Platform. https://autonomoustuff.com/product/lincoln-mkz (accessed 1 October 2018).

      11 11 YouTube (2018). PerceptIn DragonFly Sensor Module https://www.youtube.com/watch?v=WQUGB-IqbgQ&feature=youtu.be (accessed 1 October 2018).

      12 12 Vega, P. (2018). UC Irvine grad works to make a self-driving car costing under $10,000. Los Angeles Times. http://www.latimes.com/socal/daily-pilot/news/tn-dpt-me-driverless-cars-20180105-story.html (accessed 8 January 2018).

      13 13 PerceptIn (2017). PerceptIn DragonFly Pod. https://www.perceptin.io/products (accessed 1 October 2019).

      14 14 GitHub (2019). CANopenNode. https://github.com/CANopenNode/CANopenNode (accessed 1 October 2019).

      15 15 GitHub (2019). Open Source Car Control. https://github.com/PolySync/oscc (accessed 1 October 2019).

      16 16 GitHub (2019). OpenCaret. October 2019, https://github.com/frk2/opencaret (accessed 1 October 2019).

      17 17 GitHub (2019). NtripCaster. https://github.com/nunojpg/ntripcaster (accessed 1 October 2019).

      18 18 gpsd (2019). gpsd – a GPS sevice daemon. https://gpsd.gitlab.io/gpsd/index.html (accessed 1 October 2019).

      19 19 GitHub (2019). Kalibr. https://github.com/ethz-asl/kalibr (accessed 1 October 2019).

      20 20 OpenCV (2019). OpenCV. https://opencv.org (accessed 1 October 2019).

      21 21 GitHub (2019). ORB-SLAM2. https://github.com/raulmur/ORB_SLAM2 (accessed 1 October 2019).

      22 22 Geiger, A. (2019). libELAS. http://www.cvlibs.net/software/libelas (accessed 1 October 2019).

      23 23 GitHub (2019). Mask R-CNN. https://github.com/matterport/Mask_RCNN (accessed 1 October 2019).

      24 24 GitHub (2019). Baidu Apollo. https://github.com/ApolloAuto/apollo (accessed 1 October 2019).

      25 25 GitHub (2019). OpenStreetMap. https://github.com/openstreetmap (accessed 1 October 2019).

2 In-Vehicle Communication Systems

      2.1 Introduction

As shown in Figure 2.1, one key component in the modular design architecture is the in-vehicle communication network, which allows Electronic Control Units (ECUs), sensors, and other components to communicate with each other. Note, the Controller Area Network (CAN) bus is the most widely used in-vehicle communication network today due to its simplicity.

      In this chapter, we introduce in-vehicle communication systems. We first introduce CAN bus, which is a high-integrity serial bus system for networking intelligent devices. Also, we introduce FlexRay, a deterministic, fault-tolerant, and high-speed bus system developed in conjunction with automobile manufacturers and leading suppliers; FlexRay is meant to gradually replace CAN as the default in-vehicle communication network. In addition, we introduce CANopen, a communication protocol and device profile specification for embedded systems used in automation, as well as CANopenNode, a free and open source CANopen Stack written in ANSI C in an object-oriented way. We believe this chapter will provide sufficient background for readers to understand in-vehicle communication networks.

2.2 CAN

      A CAN bus is a high-integrity serial bus system for networking intelligent devices. CAN buses and devices are common components in automotive and industrial systems. Using a CAN interface device, applications can be developed to communicate with a CAN network [1,2].

      In the past few decades, the need for improvements in automotive technology caused increased usage of electronic control systems for functions such as engine timing, anti-lock brake systems, and distributor-less ignition. Originally, point-to-point wiring systems connected electronic devices in vehicles. As more and more electronics in vehicles resulted in bulky wire harnesses that were heavy and expensive, point-to-point wiring was no longer scalable.

      To eliminate point-to-point wiring, automotive manufacturers replaced dedicated wiring with in-vehicle networks, which reduced wiring cost, complexity, and weight. In 1985, Bosch developed the CAN, which has emerged as the standard in-vehicle network.

Figure 2.1 Modular design architecture.

CAN provides a cheap, durable network that allows the devices to communicate through the ECUs. CAN allows the ECUs to have one CAN interface rather than analog inputs to every device in the system. This decreases overall cost and weight in automobiles. Each of the devices on the network has a CAN controller chip and is therefore intelligent. All transmitted messages are seen by all devices on the network. Each device can decide if the message is relevant or if it can be filtered.

      As CAN implementations increased in the automotive industry, CAN (high speed) was standardized internationally as ISO 11898. Later, low-speed CAN was introduced for car body electronics. Finally, single-wire CAN was introduced for some body and comfort devices. Major semiconductor manufacturers, such as Intel, Motorola, and Philips, developed CAN chips. By the mid-1990s, CAN was the basis of many industrial device networking protocols, including DeviceNet and CANOpen.

As shown in Figure 2.2, CAN specifies the media access control (MAC) and physical layer signaling (PLS) as it applies to layers 1 and 2 of the OSI model. MAC is accomplished using a technique called nondestructive bit-wise arbitration. As stations apply their unique identifiers to the network, they observe if their data are being faithfully produced.

      If it is not, the station assumes that a higher priority message is being sent and, therefore, halts transmission and reverts to receiving mode. The highest priority message gets through and the lower priority messages are resent at another time. The advantage of this approach is that collisions on the network do not destroy data and eventually all stations gain access to the network. The problem with this approach is that the arbitration is done on a bit-by-bit basis requiring all stations to hear one another within a bit time (actually less than a bit time).