-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zephyr Version / PR for CAN-FD transport #138
Comments
Hello @raitzjm we are in the maintenance phase for micro-ROS. Not sure if we are going to have a slot for updating to the newest Zephyr version. If you want to contribute to this effort, it will be also welcomed. |
Hi @pablogs9 , thanks for your response and sorry for my late reply, I was just very busy this last month. I understand, I think I can make the transport work with Zephyr 3.1 since is the official supported version for micro-ROS, and I can make it work with newer versions as well by checking the Zephyr version and adapting the logic with macros accordingly. That way, people who are also trying micro-ROS with newer versions can use the CAN-FD transport if you are ok with that. I just wanted to ask you some questions about it. 1- Does the micro-ROS with CAN-FD transport allows to select the message id at launch time, or is it hardcoded to 0x0001? With regards to micro-ROS being in maintenance phase now, does that mean that mean that not more development will be done in micro-ROS? I am open to contribute to updating to the newest Zephyr version, we can talk about it. |
What do you mean by message id?
In the agent side you should be able to handle multiple client connections simultaneously.
That would be great. |
The ID field of a CAN frame (or message as I called it before) . I wrote the transport for Zephyr using this as reference: https://github.com/micro-ROS/micro_ros_renesas2estudio_component/blob/iron/extra_sources/microros_transports/canfd_transport.c Here the CAN message id is hardcoded to 0x001. I can make the id as a config option in Zephyr, but I am not sure if the agent support different message IDs.
|
I do not recall now, you should check the Agent implementation here: https://github.com/eProsima/Micro-XRCE-DDS-Agent/blob/master/src/cpp/transport/can/CanAgentLinux.cpp |
Thanks, I will go through the Agent code to have a better idea of how is it handling the CAN communication. If I submit a PR and everything is fine, would you be able to merge it or no PRs are being accepted anymore now that the micro-ROS in in maintenance phase ? |
PRs are welcomed, maybe I take a while to review it, but in general, contributions are accepted. The maintenance phase means that we at eProsima are not developing new features, but community contributions will be accepted as long as we maintain the project. |
Sounds good. I will be working on making the CAN-FD transport compatible with Zephyr 3.1 besides the latest Zephyr version, which is what I have it working with right now , and then submit the PR. Thanks! |
I have written an implementation for CAN-FD transport for Zephyr, since the Agent already supports it.
And it is working very well. Significantly better than USB-CDC and UART for what I have personally tested. I would be happy to submit a PR for it. However, I wrote using Zephyr 3.5, and this module is officially only supported for 2.7.5 and 3.1. The CAN api changed slightly on 3.3, only the frame and filter structs , I think, thus my implementation won't work right away. I don't have problems modifying in to work with 3.1. However, I would like to know from the maintainers, what is the roadmap with respect to Zephyr versions and microROS distros , because 3.1 is quite old now, and EOL. Will rolling be updated to the latest Zephyr version (3.6 at this moment ) ?. That way , I will just submit my current implementation and we can backport it to Humble and Iron. Otherwise, I will submit the PR for 3.1. I would just like to get some feedback about what would the maintainers prefer.
The text was updated successfully, but these errors were encountered: