Comments (8)
Thinking deeper on the topic and considering discussion in #28, I now believe, that we need a plugin mechanism to handle the infinite number of available sensors out there. I will further think about that and make a proposal.
from urdfdom.
Thanks @rhaschke, I was composing a response pointing to that discussion but you beat me to it. :)
The discussion for adding sensors to URDF has surfaced and resurfaced a few times. As you suggested, the difficulty of supporting sensors is choosing the right abstractions.
SDF supports sensors because Gazebo can simulate a specific set of sensors (laser range finders, cameras, etc.).
One question I have is how sensors in URDF will be integrated with the rest of the ROS toolchain. For example, when a robot with a LaserScan tag in its URDF is visualized in Rviz, will Rviz know to add a LaserScan visualization with the correct transform extracted from the URDF? These kinds of questions might help motivate the proposal and make it general enough to benefit the whole community.
I'm open to reviewing new proposals for sensors in URDF. However we should consider the development overhead of the initial implementation as well as the integration with our tooling. A bit of time and effort investment in the design may help reduce that overhead.
from urdfdom.
One question I have is how sensors in URDF will be integrated with the
rest of the ROS toolchain. For example, when a robot with a LaserScan
tag in its URDF is visualized in Rviz, will Rviz know to add a
LaserScan visualization with the correct transform extracted from the
URDF? These kinds of questions might help motivate the proposal and
make it general enough to benefit the whole community.Currently, we are not (yet) thinking about an automated creation of
additional displays in rviz. But our work points along a similar direction:
Given you add a sensor stream visualization to rviz (in our current case
tactile data), the associated display plugin will inspect the urdf to
know about sensor transform and other sensor parameters, which are fixed
and therefore are not published in the sensor stream.I'm open to reviewing new proposals for sensors in URDF. However we
should consider the development overhead of the initial implementation
as well as the integration with our tooling. A bit of time and effort
investment in the design may help reduce that overhead.Thanks, I will keep you updated ;-)
from urdfdom.
I'm less of a ROS insider and come from a simulation-biased perspective, but I second Robert's notion of introducing a plugin mechanism. In MARS we annotate URDF with information about sensors using SMURF and use factories to create them in simulation.
But maybe that's something more fundamental that may apply to other elements beyond sensors and thus should be discussed along with other improvements for "URDF 2.0"?
from urdfdom.
I have a lot of ideas about extensibility/a plugin interface for the "next generation" of RDFs. I am writing them up and will post them on a public forum (and notify you both when the post is finished).
from urdfdom.
@rhaschke some times ago we set up a ROS SIG on Robotic Skins [1].
While activity on the SIG has been relativly low, I think you could find useful feedback on the semantics of your proposal on how to describe tactile sensors information, even before that discussion on how to include sensors information on the "next generation of *RDFs" is completed.
[1] : http://wiki.ros.org/sig/RobotSkin
from urdfdom.
@sachinchitta has put together some notes on the topic of future RDFs and has pulled a number of my suggestions, again coming from SMURF. I haven't yet found time to work in the parallels between SDF and SMURF, but a number of ideas are in there.
It's on a github page rendered from this repository.
Perhaps we could move that repo into ros and use it as a starting point for some kind of white paper or alternatively use a github wiki to put our notes together?
from urdfdom.
Some thoughts here:
http://discourse.ros.org/t/urdf-ng-parser-tools-wishlist/55
We would need @sachinchitta's permission to move the repo into the ROS org and I wouldn't want to fork it into the organization without asking him first :) Sachin, do you currently have any interest in helping to push major changes to URDF/whatever robot description format is used in ROS? It would be great to have your input.
from urdfdom.
Related Issues (20)
- Question: check_urdf does not take into account transmission tag, wrong behaviour ? HOT 1
- Invalid path in urdfdom_INCLUDE_DIRS on Windows installation using vcpkg
- Using wrong headers HOT 2
- Deprecation warning on urdfdom_parser with Clang HOT 2
- check_urdf: no loop detection
- Branch urdfdom for Galactic HOT 5
- Usage of `version` attribute in `robot` xml-node HOT 2
- [cmake] urdf_LIBRARIES is still wrong HOT 2
- Feature request: check_urdf should be able to read from std_in HOT 2
- parseJointLimits() does not parse acceleration limits
- Joint limits (vel, effort) are checked even when the joint is continuous type.
- Build Status link in README.md is broken HOT 2
- Use tinyxml2 instead of tinyxml HOT 3
- Remove tinyxml2 from public API HOT 2
- Cannot parse capsule error HOT 1
- Fixed joints parse limits but not axis
- Add support for quaternion in URDF HOT 3
- Removing console_bridge for Logging HOT 4
- support export URDF HOT 1
- Don't use (outdated) self-provided gtest version (especially if another version is installed already) HOT 7
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 urdfdom.