Hi everyone,
I was just wondering about the switch to the CyberRT framework.
What advantages do cyber have over ROS, are there any subtle or distinct differences that make it better (or worse)?
I have gone through the documentation (and forums) trying to understand the differences, but I thought I would ask here to see if anyone who knew the frameworks with more depth could provide some insight.
I am not opposed to the change or anything like that, just trying to gain an understanding of the high level differences between the two frameworks.
Any info would be really appreciated.
Thanks!
rzerohan
If you just a regular robot researcher, I would recommend ros over cyberrt.
If you want to build a robot and sell it as a product, you may want to try cyberrt.
I haven't test their performance, so I cannot compare them in the performance aspect.
But I don't think this is a main reason since ros is open-sourced, you can just fork it and do improvement
base on it, isn't it?
I can share some personal opinion after reviewing their design
Much better documentation
Large community, you can get help easily
Much Stable since it already tested by a lot of time
A lot of existing package, tools.
Rely on Rosmaster, Centralize
XMLRPC
Not stable yet
Light Weight
Mostly used lockless technique instead of mutex in implementation (The performance is expected to be better)
You can control every line of code (I think this is the main reason why baidu create cyberrt.) Then you can change the low level mechanism to fulfill the high-level module requirement.
Easy to customize and debug
No longer need to support the old ros api (Maybe this is the reason why apollo give up apollo-ros?)
Less helper function, utility
Import the routine, scheduler concept (i am not quite sure is it good change or not, need more test)
(The below is also supported by apollo version of ros)
Shared Memory support
Decentralize
RTPS
Protobuf Support
@KitFung thanks for helping with the summary.
@rzerohan
We will have a more indepth docs soon, but for now. I would like to point out a couple of feature in Apollo Cyber RT:
@rzerohan if you can understand Chinese, we have our video on CSDN with more technical details about Cyber RT.
https://edu.csdn.net/course/detail/16425
We also plan to have something similar in English in the next couple of months.
Is it true that Apollo v3.5 no longer uses apollo-ros (https://github.com/ApolloAuto/apollo-platform)? If that's the case, can I understand CyberRT as a middleware replacement of ROS in Apollo v3.5 and also providing new customized features to meet the performance requirement of autonomous driving?
@KitFung
You can control every line of code (I think this is the main reason why baidu create cyberrt.) Then you can change the low level mechanism to fulfill the high-level module requirement.
I'm just curious, we can't control every line of code of ROS?
It seems we could edit very basic ROS library such as roscpp.
And also its source code is available like ros_comm.
Please explain.
Thank you in advance.
Most helpful comment
If you just a regular robot researcher, I would recommend ros over cyberrt.
If you want to build a robot and sell it as a product, you may want to try cyberrt.
I haven't test their performance, so I cannot compare them in the performance aspect.
But I don't think this is a main reason since ros is open-sourced, you can just fork it and do improvement
base on it, isn't it?
I can share some personal opinion after reviewing their design
ROS:
Much better documentation
Large community, you can get help easily
Much Stable since it already tested by a lot of time
A lot of existing package, tools.
Rely on Rosmaster, Centralize
XMLRPC
CyberRT
Not stable yet
Light Weight
Mostly used lockless technique instead of mutex in implementation (The performance is expected to be better)
You can control every line of code (I think this is the main reason why baidu create cyberrt.) Then you can change the low level mechanism to fulfill the high-level module requirement.
Easy to customize and debug
No longer need to support the old ros api (Maybe this is the reason why apollo give up apollo-ros?)
Less helper function, utility
Import the routine, scheduler concept (i am not quite sure is it good change or not, need more test)
(The below is also supported by apollo version of ros)
Shared Memory support
Decentralize
RTPS
Protobuf Support