${BLUE}build_control${NONE}: compile control and its dependencies.
${BLUE}build_prediction${NONE}: compile prediction and its dependencies.
${BLUE}build_pnc${NONE}: compile pnc and its dependencies.
${BLUE}build_no_perception [dbg|opt]${NONE}: run build build skip building perception module, useful when some perception dependencies are not satisified, e.g., CUDA, CUDNN, LIDAR, etc.
${BLUE}build_no_perception [dbg|opt]${NONE}: run build, skip building perception module, useful when some perception dependencies are not satisified, e.g., CUDA, CUDNN, LIDAR, etc.
${BLUE}build_prof${NONE}: build for gprof support.
${BLUE}buildify${NONE}: fix style of BUILD files
${BLUE}check${NONE}: run build/lint/test, please make sure it passes before checking in new code
Canbus accepts and executes the control command, and collect chassis status as feedback to control.
Canbus accepts and executes control module commands and collects the car's chassis status as feedback to control.
## Input
* Control command
* Control commands
## Output
* Chassis status
* Chassis detail status
* Chassis detailed status
## Implementation
The major components in canbus module are:
* Vehicle including vehicle controller and message manager
* (CAN client has been moved to `/modules/drivers/canbus` since it is shared by different sensors utilizing canbus protocol)
The major components in canbus module are:
***Vehicle**: the vehicle itself, including its controller and message manager
Your own CAN client can be implemented in the folder of *can_client* by inheriting from `CanClient` class. Remember to register your CAN client in `CanClientFactory`.
***CAN Client** - CAN client has been moved to `/modules/drivers/canbus` since it is shared by different sensors utilizing the canbus protocol
Your own vehicle controller and message manager can be implemented in the folder of *vehicle* by inheriting from `VehicleController` and `MessageManager`. Remember to register your vehicle in `VehicleFactory`.
You can implement your own CAN client in the folder `can_client` by inheriting from the `CanClient` class.
```
Note:
Do not forget to register your CAN client in `CanClientFactory`.
```
You can also implement your own vehicle controller and message manager in the folder `vehicle` by inheriting from `VehicleController` and `MessageManager`.
```
Note:
Do not forget to register your vehicle in `VehicleFactory`.
This module contains code that is not specific to any module but is useful for the functioning of Apollo.
## apollo_app
```
The "apollo_app" build target defines the abstract class ApolloApp,
which is implemented by all modules, as well as the macro APOLLO_MAIN,
The **apollo_app** build target defines the abstract class ApolloApp,
which is implemented by all modules, as well as the macro `APOLLO_MAIN`,
used to launch each module.
```
## log
```
The "log" build target wraps the Google Log system into project-specific macros,
allowing for more refined control over the levels of logging.
```
The **log** build target wraps the Google Log system into project-specific macros, allowing for more refined control over the levels of logging.
## macro
```
The "macro" build target defines a few commonly used class-specific macros.
```
The **macro** build target defines a few commonly used class-specific macros.
## adapters
```
Adapters are used by the different modules to communicate with one another.
The AdapterManager class hosts all the specific adapters and manages them.
Adapters need to be registered with the macro REGISTER_ADAPTER.
Adapters are used by the different modules to communicate with one another. The `AdapterManager` class hosts all the specific adapters and manages them.
Adapters need to be registered with the macro `REGISTER_ADAPTER`.
The Adapter class serves as a layer of abstraction between
Apollo modules and I/O mechanisms (e.g. ROS).
```
## configs/data
```
These specify the vehicle configuration.
```
The vehicle configuration is specified in `configs/data`
## math
```
Implements a number of useful mathematical libraries.
```
**math** implements a number of useful mathematical libraries.
## monitor
```
Defines a logging system.
```
**Monitor** defines a logging system.
## proto
```
Defines a number of project-wide protocol buffers.
```
**Proto** defines a number of project-wide protocol buffers.
## status
```
Used for determining whether certain functions were performed successfully,
providing helpful error messages otherwise.
```
**Status** is used for determining whether certain functions were performed successfully or not. If not, status provides helpful error messages.
## time
```
Helper functions related to time.
```
**Time** is a helper functions related to time.
## util
```
Contains an implementation of a factory design pattern with registration,
a few string parsing functions, and some utilities for parsing
protocol buffers from files.
```
**Util** contains an implementation of a factory design pattern with registration, a few string parsing functions, and some utilities for parsing protocol buffers from files.
## vehicle_state
```
This class specifies the current state of the vehicle (e.g. position, velocity,
heading, etc.).
```
The **vehicle_state** class specifies the current state of the vehicle (e.g. position, velocity, heading, etc.).
