Quantcast
Channel: ROS Answers: Open Source Q&A Forum - RSS feed
Viewing all articles
Browse latest Browse all 126

auto-generated dynamic_reconfigure headers fail to compile depending on field names

$
0
0
In Fuerte, if a .cfg file used with dynamic_reconfigure contains a field named "i":
...
gen.add( "i", double_t, SensorLevels.RECONFIGURE_RUNNING, "i gain", 1, 0, 200 )
...
the header will fail to compile with:
no match for ‘operator=’ in ‘i = boost::any_cast [with ValueType = double]((* & val))’
The offending auto-generated code is:
class DEFAULT
{
  public:
    DEFAULT()
    {
      state = true;
      name = "Default";
    }

    void setParams(PIDConfig &config, const std::vector params)
    {
      for (std::vector::const_iterator i = params.begin(); i != params.end(); i++)
      {
        boost::any val;
        (*i)->getValue(config, val);

        if("p"==(*i)->name){p = boost::any_cast(val);}
        if("i"==(*i)->name){i = boost::any_cast(val);}
      }
    }

    double p;
double i;

    bool state;
    std::string name;

    
}groups;
Here, it's clear that setParams is using an iterator called "i", yet a member variable "i" of type "double" also exists within the same class. While the obvious solution is to change the config field name from "i" to something like "i_gain" in this particular case, this issue breaks diamondback-compatible code and limits the names which may be used for dynamic_reconfigure fields. To clarify, I'm using Ubuntu 12.04 64-bit/gcc 4.6.3 on a VM with a clean ROS install and the latest updates installed via dist-upgrade. ---- **Additional Issues** It appears there are at least two more cases in which dynamic reconfigure param names can cause compilation issues. When the class "DEFAULT" is added by the cfg generator:
class DEFAULT
{
  public:
    DEFAULT()
    {
      state = true;
      name = "Default";
    }

    ...

    // variables from user-specified fields

    ...

    // internal variables
    bool state;
    std::string name;
    
}groups;
the variables "state" and "name" appear to always be created, and will therefore conflict with any user-created variables with the same name. To avoid these issues, it's probably a good idea to manually append "_param" or something similar to the name of all dynamic_reconfigure fields in .cfg files; however, as with the previous part of this issue, it would be great if this stuff would just work out-of-the-box.

Viewing all articles
Browse latest Browse all 126

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>