Comments (13)
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.
from oxcc.
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.
from oxcc.
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.
from oxcc.
Hi Andrew,
That sounds awesome, thank you!
I put together a rough draw.io schematic of the pins here.
For the CAN transceivers, I have been using the CAN transceiver SN65HVD230 from Waveshare.
from oxcc.
my pleasure, great work btw. The SN65HVD230 is your CAN controller, isn't it? This might work similar to Kvaser Leaflight I assume. CMIIW
from oxcc.
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.
from oxcc.
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.
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.
from oxcc.
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.
from oxcc.
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:
- Nitrogen8M - quad A53 + M4 cores (and GPU)
- Nitrogen6 SoloX - A9 + M4 cores
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
from oxcc.
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
from oxcc.
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.
from oxcc.
@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.
from oxcc.
Nice @andrewraharjo , nothing really stands out to me in your design that would be troublesome, looks good π
from oxcc.
Related Issues (11)
- Investigate continuous override behavior
- Determine a reasonable ADC sample time HOT 2
- Should control command timeouts be re-implemented?
- Disable controls globally when any faults are detected
- Enable compile-time feature gating for STEERING_OVERRIDE
- Fix overflow in the fault condition ported logic
- Check for and apply fixes from upstream OSCC
- Downgrade ADC resolution to 10-bit so users don't have to re-calibrate vehicle configurations
- Runtime configuration HOT 2
- AIN signal to DAC output mapping inconsistent between brake, throttle and steering modules HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oxcc.