search

jonlamb-gh / oxcc

A port of Open Source Car Control written in Rust
Apache License 2.0
19 stars 5 forks source link

Compatibility with Sensor Interface, VCM, and Gateway Boards #26

Open andrewraharjo opened 5 years ago

andrewraharjo commented 5 years ago

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.

jonlamb-gh commented 5 years ago

I think your assumption is pretty reasonable. I didn't see many revisions when looking around in the OSCC repository.

It would be great if OxCC were pin-compatible with existing hardware, but currently it is not. It does however use most of the same hardware (MCP 4922 DAC, etc).

The initial porting effort focused mainly on insuring each module (throttle, brake, and steering) could own whatever peripherals/pins they need access to, such that no module shares a resource with another module.

For example, the analog input pins for each module in types.rs: ADC1 is given to the brake module, ADC2 to throttle, and ADC3 to steering.

andrewraharjo commented 5 years ago

Jon,

Do you have the rough schematic to connect one the board with STM32 board? I can help to create new layout for those OSCC boards.

Let me know.

jonlamb-gh commented 5 years ago

Hi Andrew,

That sounds awesome, thank you!

I put together a rough draw.io schematic of the pins here. rendered

For the CAN transceivers, I have been using the CAN transceiver SN65HVD230 from Waveshare.

andrewraharjo commented 5 years ago

my pleasure, great work btw. The SN65HVD230 is your CAN controller, isn't it? This might work similar to Kvaser Leaflight I assume. CMIIW

jonlamb-gh commented 5 years ago

The CAN bits I put together for oxcc use the stm's on-board bxCAN controller; which I believe is based on the CAN core of BOSCH's C_CAN controller. AFAICT there are no on-board/integrated transceivers, so I have my CAN1 and CAN2 Rx/Tx pins each wired up to a SN65HVD230 board. For host-side CAN communications, I'm using a PCAN-USB adapter but I have also used the Leaf Lights in the past.

andrewraharjo commented 5 years ago

@jonlamb-gh

Check this out! I have made this progress so far - Steering/Throttle together. I added Molex 48 pins connector and getting ready for the VCM and gateway. Within next week, it should be done and ready to be reviewed and fabbed.

image

The designs are straight from OSCC, latest build, but at the same time I plan to add a CAN interface to it as well (say CANTact) so the users won't tie using kVaser or any other CAN devices. Although, I will add extra debug port out from the design if the users want to communicate/use kVaser or their own CAN interface.

What do you think? I put this as dev board and you can easily connect them one-one jumper with STM32 development board. Once we figure out the correct wiring, I'll update the board.

jonlamb-gh commented 5 years ago

Nice work @andrewraharjo, looks like you've made good progress! It should serve well as a flexible dev board and I'm looking forward to trying one out when ready.

andrewraharjo commented 5 years ago

Jon, also I’d comment on this. Can we get it work on ROS platform? We should plan to extend this as full ARM-GPU based.

SoC platform would be better suitable with OXCC rather than tie up with NVIDIA GPU (Jetson, Xavier,etc)

Check this https://www.96boards.org/product/hikey970/

What do you think? Can we support it?

Hint: HiSilicon is planning release ASIL-S 820e board which better candidate for processing. I can run my neural processor and hopefully control the board using your ‘rust’ API on top of it. Just something to think about.

jonlamb-gh commented 5 years ago

Very cool, I've also wondered on how to integrate OxCC into other platforms/SoCs.

My initial thoughts are that it's probably best to keep the safety-related control logic of OxCC running on an MCU given the real-time nature of things it uses (timers, watchdog, interrupts, etc).

I've been experimenting with a few of the heterogeneous multi-core SoC boards from BD:

I run bare-metal bits on the M4 core and some OS on the A core(s).

They can communicate with each other via shared memory (for example with OpenAMP) rather than over a CAN bus. Layering an API over the shared memory segment would be pretty straight forward.

Here's a link to one of my experimental projects you can check out if interested: SoloX AMP in Rust

andrewraharjo commented 5 years ago

@jonlamb-gh

Nice, that is the direction where it should be. How do you get support on the SoloX Nitrogen6 board? Also, for the higher layer API, what's the plan to make it work with ROS? ROSCCO is all written in C/C++

TBH, I am not Rust expert but I need some sort of control command that I can publish/subscribe. If we can figure out, I think that would be my 2nd priority after finishing up the board. Also, if there is any SoC out there that can output the DAC and SPI lines, should we ditch the STM32? I mean I don't mind to create a closed source board with SoC integration.

Just a matter of time, I guess

jonlamb-gh commented 5 years ago

Both of those boards have a far amount of community driven support I've found.

You could run Ubuntu, Yocto, or some other Linux distro to host your ROS applications.

With these SoC's, ROSCCO is not necessarily needed. Your ROS applications can talk directly to the OxCC firmware via shared memory, so theoretically any of your ROS nodes running locally could call into the API or you could have a single gateway node like ROSCCO does (I think?). The API could be semantically similar to the existing OSCC API, but backed by a Rust implementation of RPMsg.

It would also be pretty straight forward to replace ROSCCO's back-end CAN stack with RPMsg.

I've also had a hard time locating some hardware with the 6 DAC channels OxCC needs, I'll let you know if I come across any.

andrewraharjo commented 5 years ago

@jonlamb-gh Check this out. I am planning to fab this board within next week. It'll take about 2-3 days to complete fab. What do you think? I'd like to do sanity check/review with you. Remember, this board is intended for development only. Until we can find the way to port it to STM32 then this board will be beneficial for development.

oxcc_ecu

jonlamb-gh commented 5 years ago

Nice @andrewraharjo , nothing really stands out to me in your design that would be troublesome, looks good :+1: