robot state publisher is flawed because it does not allow external programs
to change a rigid transform without the addition of a sequence of joints.
If it would allow us to both ask it what the current value is, and to
modify the value it was publishing, then our interface would be less
convoluted. I agree that this is awkward, but is not a flaw in our base
transform interface class, just in the inability to both read and write
geometric constants. Calibration is the setting of constants, the robot
state publisher assumes constants will not change their values. It was a
reasonable assumption, but in this case it was wrong and we have to work
around it.


On Wed, Apr 30, 2014 at 5:56 PM, Shaun Edwards <notifications@github.com>wrote:

> In
> industrial_extrinsic_cal/include/industrial_extrinsic_cal/ros_transform_interface.h:
>
> > +     */
> > +    ROSCameraHousingListenerTInterface(const std::string optical_frame,const std::string housing_frame);
> > +
> > +    /**
> > +     * @brief Default destructor
> > +     */
> > +    ~ROSCameraHousingListenerTInter
> face()  {  } ;
> > +
> > +    /** @brief  as a listener interface, this does nothing. Transform is defined by the urdf */
> > +    bool pushTransform(Pose6d & Pose){return(true);};
> > +
> > +    /** @brief get the transform from the hardware or display */
> > +    Pose6d pullTransform();
> > +
> > +    /** @brief as a listener interface, this does nothing. Transform is defined by urdf */
> > +    bool store(std::string filePath){ return(true);};
>
> This seems like it will be a source of errors/confusion. This class only
> really does 1 our of 3 functions. This could mean the inheritance/base
> class design is flawed.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/ros-industrial/industrial_calibration/pull/26/files#r12170458>
> .
>