jonlamb-gh / oxcc Goto Github PK

View Code? Open in Web Editor NEW

18.0 6.0 5.0 233 KB

A port of Open Source Car Control written in Rust

License: Apache License 2.0

GDB 0.46% Shell 0.26% Rust 99.23% RenderScript 0.04%

rust rust-embedded stm32 stm32f767zi autonomous-vehicles autonomous-driving nucleo-f767zi can-bus bootloader no-std

oxcc's Introduction

OxCC

Overview

A port of Open Source Car Control written in Rust.

OxCC runs on the NUCLEO-F767ZI STM32F767ZI board.

It is built around the traits and patterns provided by the embedded-hal project and community: see the BSP crate, the HAL crate, and the device crate.

OSCC Divergence

Apart from the change in MCU/board, OxCC combines all of the OSCC modules (throttle, brake, steering, CAN gateway) into a single application.

Hardware

A new layout and schematic is currently in the works, check out the rough pinout to get started.

CAN

OxCC uses the stm's on-board bxCAN controller. For a transceiver I've been using the SN65HVD230 from Waveshare.

Getting Started

Dependencies

rust (nightly)
svd2rust
openocd (for debugging)
gdb-arm-none-eabi (for debugging)
binutils-arm-none-eabi (uses objcopy for device deployment)
stlink (for device deployment)

Building

The default Cargo configuration will build for the Kia Soul EV vehicle with the panic-over-abort strategy.

See the [features] section of the Cargo.toml to change configurations.

Install system package dependencies:

sudo apt-get install openocd
sudo apt-get install gdb-arm-none-eabi
sudo apt-get install binutils-arm-none-eabi

Install stlink from source: guide

Install Rust nightly and additional components:

curl https://sh.rustup.rs -sSf | sh
rustup install nightly
rustup component add rust-src
rustup component add rustfmt-preview --toolchain nightly
rustup target add thumbv7em-none-eabihf

Install svd2rust:
```
cargo install svd2rust
```
Build OxCC firmware:
```
cargo build
```

Deploying

Deploy the firmware Using st-flash (provided by stlink):

# Convert ELF to ihex format
arm-none-eabi-objcopy \
    -O ihex \
    target/thumbv7em-none-eabihf/release/oxcc \
    target/thumbv7em-none-eabihf/release/oxcc.hex

# Upload to flash
st-flash \
    --format ihex \
    write \
    target/thumbv7em-none-eabihf/release/oxcc.hex

Debugging

In one terminal, start openocd:

openocd -f board/stm32f7discovery.cfg

In the OxCC terminal, use the runner to start a gdb session:

cargo run

License

Licensed under either of

Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

oxcc's People

Contributors

Stargazers

Watchers

Forkers

zackpierce mullr andrewraharjo tommyblaireslewis icodein

oxcc's Issues

Should control command timeouts be re-implemented?

Some discussion on OSCC control command timeouts in this PR; they were removed.

Is that a reasonable claim? What happens when the last throttle command was non-zero and no further control commands (or any CAN frames) are received?

We have plenty of cycles to burn, and it would be pretty easy to re-implement that logic.

Check for and apply fixes from upstream OSCC

Investigate continuous override behavior

OSCC throttle module doesn't allow for continuous overrides but brake and steering do?

Disable controls globally when any faults are detected

Now that all of the modules (brake, throttle and steering) are on a single chip, they no longer need to respond to other modules fault CAN messages in order to disable themselves.

Instead, we can report up when a fault is detected in a given module and disable controls for all.

Compatibility with Sensor Interface, VCM, and Gateway Boards

If my assumption correct, the signal paths for those boards don't change per PolySync released. Is this valid assumption? The Nucleo board outer pinouts serve as Arduino pinouts. I haven't taken a greater look in the code but it does utilize MCP's and DAC's stuffs from Arduino boards.

Determine a reasonable ADC sample time

OSCC was likely using the default Arduino ADC configuration, which could be along the lines of ~104 microseconds per analogRead().

OxCC is currently using a prescaler/cycle-time combination that gives 27.33 microseconds per sample.

AIN signal to DAC output mapping inconsistent between brake, throttle and steering modules

All of the modules should have a consistent mapping between the analog input hight/low signals and the DAC output A/B channels.

I think the mapping should be:

AIN signal high maps to DAC channel A
AIN signal low maps to DAC channel B

Currently the brake and throttle modules are inverting the mapping when they
call the prevent_signal_discontinuity() function.

The steering module seems to be using them correctly.

TODO Confirm this is a bug in the OSCC firmware or just a hardware pin mapping issue.

Can we do away with high/low and just have A/B for both input and output?

Downgrade ADC resolution to 10-bit so users don't have to re-calibrate vehicle configurations

While it would be great to use the full 12-bit ADC resolution; this requires existing users to re-calibrate their existing vehicle configuration data which is not very convenient.

For example, the constant ACCELERATOR_OVERRIDE_THRESHOLD is a calibrated value in the 10-bit range.

My initial porting effort set things up with full 12-bit resolution, and I just shifted the constants.
Those changes should be restored with this effort.

Enable compile-time feature gating for STEERING_OVERRIDE

Here's the OSCC reference:
#ifdef STEERING_OVERRIDE

Runtime configuration

It would be handy if users could modify parameters at runtime.

The bootloader I put together already has some configs in flash. It would be easy to reserve a (partial) sector of flash for user firmware configuration parameters.

An initial effort could likely just provide a simple flash get/set framework over CAN; a proper XCP implementation could be done too.

Fix overflow in the fault condition ported logic

panicked at 'attempt to subtract with overflow', src/fault_condition.rs:47:28