[Rock-dev] Cannot typedef already defined types!

[Sylvain Joyeux]

Wild guess, there is a but in orogen when the typedef is not defined in the
project where the type is defined.

The only workaround I see right now is for you to use the std::vector<>
(i.e. not the typedef) on the port for the time being. Please open a ticket
on rock.opendfki.de as well.

Sylvain


On Wed, May 14, 2014 at 10:03 AM, Ajish Babu <ajish.babu at dfki.de> wrote:

>  Hi,
>
> the line triggering the error is
> *using_task_library "cog_support_polygon"*
> which contains the port with this datatype. The complete file looks like
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *name "sherpa_tt_deployments" using_task_library "trajectory_generation"
> using_task_library "cog_support_polygon" using_task_library "sherpa_tt_mcs"
> using_task_library "sams" deployment 'sherpa_tt_kinematics' do
> task("self_collision_viz", "sams::SelfCollisionViz").
> realtime.priority(40)             task("self_collision_ctrl",
> "sams::SelfCollisionCtrl").         realtime.priority(70)
> task("self_collision_check", "sams::SelfCollisionCheck").
> realtime.priority(70)     task("cog_support_polygon",
> "cog_support_polygon::Task").         realtime.priority(70)
> task("rml_position", "trajectory_generation::Task").
> realtime.priority(80).         periodic(0.01)     task("sherpa_tt_mcs",
> "sherpa_tt_mcs::Task" ).         realtime.priority(80)
> add_default_logger end*
>
> and the cog_support_polygon.orogen looks like
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *name "cog_support_polygon" using_library "kdl_parser" using_library
> "cog_support_polygon" import_types_from "base" import_types_from
> "cog_support_polygonTypes.hpp" import_types_from
> "cog_support_polygon/SupportPolygon.hpp" task_context "Task" do
> needs_configuration     runtime_states 'WITHIN_SAFETY_MARGIN',
> 'OUTSIDE_SAFETY_MARGIN',         'OUTSIDE_SUPPORT_POLYGON'     #Properties
>     property("urdf_file", "/std/string").         doc("UDRF file for the
> robot")     property("safety_margin", "/double", 0.0).         doc("Minimum
> allowed distance to edge of convex hull")     #Input ports
> input_port("enabled", "bool").         doc("Set true to enable to modify
> command")     input_port("joints_command", "/base/commands/Joints").
>         doc("Current joint state")     input_port("body_orientation",
> "/base/Quaterniond").         doc("Orientation of the body w.r.t the world
> CS")     input_port("support_points", "*
>
>
>
>
>
>
>
>
>
>
>
>
>
> * /cog_support_polygon/PolygonPoints3d").         doc("Points which are
> part of the support")     #Output ports
> output_port("modified_joints_command", "/base/commands/Joints").
> doc("Reference for joints")     output_port("support_polygon_info",
> "/cog_support_polygon/SupportPolygonInfo").         doc("Data output from
> the support polygon")     # Computed time for one cycle in seconds
> output_port "actual_cycle_time", "/double"     port_driven 'joints_command'
> end*
>
> Now it is running without using the typedef !
>
> regards
> Ajish
>
>
>
> On 05/13/2014 11:39 PM, Sylvain Joyeux wrote:
>
> What is unclear is what generates the error from the orogen file. What is
> inside the sherpa_tt_deployments.orogen file ? (especially in the first few
> lines ...)
>
>  Sylvain
>
>
> On Tue, May 13, 2014 at 3:31 PM, Ajish Babu <ajish.babu at dfki.de> wrote:
>
>>  Hi all,
>>
>> I was trying to use the type
>> * typedef std::vector< base::Vector3d > PolygonPoints3d;*
>> as port type in orogen module. The module builds without problems.
>>
>> But when I try to build the deployment it gives an error
>> *sherpa_tt_deployments.orogen:4: type
>> /cog_support_polygon/PolygonPoints3d is not declared
>> (Orocos::Generation::ConfigError). *
>>
>> What I understand now is that the type *std::vector< base::Vector3d > *is
>> already in the typekit in base/orogen/types/base.orogen. I could not find
>> any warnings about it.
>>
>> Does anybody know what is going on? Why was there no problem in building
>> the module? Why would another typedef create such a problem?
>>
>> regards
>> Ajish
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140514/2851826b/attachment.htm