-
Notifications
You must be signed in to change notification settings - Fork 11
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
ros2_control PDO commands #219
Conversation
Conflicts: panther_hardware_interfaces/README.md panther_hardware_interfaces/include/panther_hardware_interfaces/canopen_controller.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/panther_system.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/roboteq_data_converters.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/roboteq_driver.hpp panther_hardware_interfaces/src/motors_controller.cpp panther_hardware_interfaces/src/panther_system.cpp panther_hardware_interfaces/src/roboteq_driver.cpp
Conflicts: panther_bringup/launch/bringup.launch.py panther_controller/config/WH01_controller.yaml panther_controller/config/WH02_controller.yaml panther_controller/config/WH04_controller.yaml
Conflicts: panther_controller/config/WH01_controller.yaml panther_controller/config/WH02_controller.yaml panther_controller/config/WH04_controller.yaml panther_description/urdf/panther_macro.urdf.xacro panther_hardware_interfaces/CMakeLists.txt panther_hardware_interfaces/CODE_STRUCTURE.md panther_hardware_interfaces/README.md panther_hardware_interfaces/include/panther_hardware_interfaces/canopen_controller.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/motors_controller.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/panther_system.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/panther_system_ros_interface.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/roboteq_data_converters.hpp panther_hardware_interfaces/include/panther_hardware_interfaces/roboteq_driver.hpp panther_hardware_interfaces/src/canopen_controller.cpp panther_hardware_interfaces/src/motors_controller.cpp panther_hardware_interfaces/src/panther_system.cpp panther_hardware_interfaces/src/panther_system_ros_interface.cpp panther_hardware_interfaces/src/roboteq_driver.cpp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, PR without tests
panther_hardware_interfaces/config/roboteq_motor_controllers_v80_21a.eds
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm satisfied with these changes; they are just a few suggestions.
How about using ""
instead of <>
when including certain header files?
panther_hardware_interfaces/include/panther_hardware_interfaces/motors_controller.hpp
Show resolved
Hide resolved
const RoboteqData & GetFrontData() { return front_data_; } | ||
const RoboteqData & GetRearData() { return rear_data_; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const RoboteqData & GetFrontData() { return front_data_; } | |
const RoboteqData & GetRearData() { return rear_data_; } | |
const RoboteqData & GetFrontDataRef() { return front_data_; } | |
const RoboteqData & GetRearDataRef() { return rear_data_; } |
I believe we discussed this ref/copy issue previously, but I just suggest adding Ref
to the method names as a solution. What are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer the regular names (without Ref
), how about you @KmakD?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't have a strong opinion about this. I guess with Ref
we leave less room for confusion later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I would even prefer to remove reference and just copy, if that can be confusing, instead of adding Ref
to method names xd I think that it will look strange, and I haven't seen such convention anywhere.
bool RoboteqDriver::Boot() | ||
{ | ||
booted_.store(false); | ||
return FiberDriver::Boot(); | ||
return LoopDriver::Boot(); | ||
} | ||
|
||
bool RoboteqDriver::WaitForBoot() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just curious about what happens when we use std::future<std::string>
in this boot sequence. In my opinion, it would be clearer, but I am aware of the fact that it may not be worth it. Using std::async()
in CANopenController::BootDrivers()
and remove WaitForBoot()
could be an option there ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if async
can be used in this case - Boot
method only requests boot operation, once it completes OnBoot
is called, for which WaitForBoot
waits. It could be done with future
, but I wouldn't use string
for that - IMO that would look worse. Instead bool variable can be used, that will store result if the boot was successful or not (change booted_
to promise). This makes sense, not sure if it will be that better, but I can change it. What do you think about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. @KmakD ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, 488c578, it wasn't even necessary to use bool promise.
I just mentioned it yesterday when reviewing GPIO and I agree. This change will have to be done also in other parts of the code ('battery', 'lights'). |
New capabilities were introduced in fw 2.1a for Roboteq, which allowed us, among others to use PDO commands, and move some other information also to PDO. Additional required changes to
panther_msgs
: husarion/panther_msgs#18