You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, first of all thanks for the quick response on my PR earlier.
I am not sure if possible but if you want to make migration towards your package easier for people that are coming from cv_camera pkg then it would be great to have the full parameter set available (http://wiki.ros.org/cv_camera#Parameters).
In general, having the frame rate and dimensions being exposed via parameters instead of needing a separate config file (as currently) might already be sufficient to catch 99% of the use cases from previous cv_camera pkg users. Question would be whether the parameter naming is consistent across different camera brands (I am new to this, so probably breaks here already). However, if possible that would be a great deal for anybody migrating as it would mean to be able to continue using the rest of an existing infrastructure by just having to switch the nodes that handle the cameras.
Anyways, was just an idea I got during migration.
The text was updated successfully, but these errors were encountered:
There is lots of leeway on what GenICam features cameras support, with most of them not being required.
However if cameras do implement those features they should follow the SFNC (StandardFeatureNamingConvention).
For the frame rate there is the "recommended" AcquisitionFrameRate feature which probably most cameras implement, so this could be added as a dynamic reconfigure parameter.
The width/height you can usually not choose freely, so this might be a bit harder to map automatically...
Hi, first of all thanks for the quick response on my PR earlier.
I am not sure if possible but if you want to make migration towards your package easier for people that are coming from cv_camera pkg then it would be great to have the full parameter set available (http://wiki.ros.org/cv_camera#Parameters).
In general, having the frame rate and dimensions being exposed via parameters instead of needing a separate config file (as currently) might already be sufficient to catch 99% of the use cases from previous cv_camera pkg users. Question would be whether the parameter naming is consistent across different camera brands (I am new to this, so probably breaks here already). However, if possible that would be a great deal for anybody migrating as it would mean to be able to continue using the rest of an existing infrastructure by just having to switch the nodes that handle the cameras.
Anyways, was just an idea I got during migration.
The text was updated successfully, but these errors were encountered: