jonlamb-gh / oxcc Goto Github PK

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.

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

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.

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.

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

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.

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?

• PR 317
• PR 310

Here's the OSCC reference:
#ifdef STEERING_OVERRIDE

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.

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.