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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev >> >> > >
_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
