Comments (9)
hi, what's the status of this port? Karsten's PR has a number of missing things like parsing in actuators, and it's not a 1:1 port with minimal changes from ros1.
from ros2_control.
@ddengster I should have marked this PR as draft. I am agreeing with @bmagyar review and most likely that transmission interface should have a new design in the first place. I just need something going for get started with the gazebo_ros_control
part of it.
I think this issue is the right place to voice some concerns or design proposals for a ROS2 implementation.
from ros2_control.
No problem, @Karsten1987. I also happen to be working on a minimal gazebo_ros_control
plugin for my own priorities.
With regards to the PR, I was expecting something closer to a 1-to-1 for the parser - doing a minimal working port first from ros_control, then applying breaking design changes later.
Also I'm not sure if we need a TransmissionParser object instantiation? I just need a function call to populate my TransmissionInfo data structures. But then again I'm not of the mindset that we need to 'objectify' things to get our code to do what it needs to do.
from ros2_control.
Over the years there were quite a few attempts at improving ros_control
to improve extendability but the one that kept failing was joint and actuator interfaces. They are locked into place by the intertwined structure of transmission_interface
and it solidified bad patterns in the entire framework. If you have specific requirements from transmissions please do say so :)
Also, I agree with removing classes when not needed. If a class contains no state but only a bunch of (hopefully static) functions, we have a better name for that: namespace.
from ros2_control.
I'm assuming you're referring to JointInfo
and ActuatorInfo
? It's members are mostly strings, which are imo the most extendable types you can have without bringing in a whole bunch of other abstractions to resolve parsed xml strings into another type. (And I'm not really a guy who likes bringing in more abstractions without a few existing use cases)
Perhaps I'll pick an example to narrow it down?
There's plenty of transmissions[j].joints_[0].name_
, is this the bad thing you're referring to?
Anyway, let me know and mabye we can trash it out.
from ros2_control.
I saw that @bmagyar has merged transmission_interface in ros2_control/master. Is there any plan for the following data structures.
struct JointInfo
{
std::string name_;
std::vector<std::string> hardware_interfaces_;
std::string role_;
std::string xml_element_;
};
/**
* \brief Contains semantic info about a given actuator loaded from XML (URDF)
*/
struct ActuatorInfo
{
std::string name_;
std::vector<std::string> hardware_interfaces_;
std::string xml_element_;
};
from ros2_control.
Where do you need those informations?
from ros2_control.
We are missing transmission-loader and an xml format to close this.
from ros2_control.
Done in the recent ros2_control release, 2.6
from ros2_control.
Related Issues (20)
- CI build job rolling/testing failed!
- CI build job humble/main failed!
- /controller_manager is not loading up HOT 4
- CI build job jazzy/main failed!
- CI build job jazzy/testing failed!
- os2 launch articubot_one launch_robot.launch.py HOT 4
- Controller manager: tell hardware_interface which state interfaces to populate HOT 2
- CI build job humble/testing failed!
- CI build job humble/main failed!
- CI build job humble/testing failed!
- test_spawner_unspawner timouts on Jazzy builds HOT 2
- TestLoadController.unload_on_kill is broken
- Add tests for hardware_spawner and other python scripts
- Naming controller_manager causes multiple controller_manager to spawn and spawner node fail HOT 1
- test_spawner_unspawner runs into timeout on source builds HOT 2
- Conflict in Controlling Multiple Robotic Arms Simultaneously in ROS2 Control Using SOEM Due to Shared Global Variables HOT 5
- CI build job humble/source failed! HOT 1
- Add tests to the `params_file` parameter in test_spawner_unspawner.cpp
- Compatibility with ROS 2 Components HOT 6
- Chainable controllers HOT 8
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 ros2_control.