Discussion:
[Rock-dev] Cannot typedef already defined types!
Ajish Babu
2014-05-13 13:31:45 UTC
Permalink
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140513/1c646759/attachment.htm
Ajish Babu
2014-05-14 08:03:43 UTC
Permalink
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*
*
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
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 <mailto: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/417237fd/attachment.htm
Sylvain Joyeux
2014-05-14 13:14:26 UTC
Permalink
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
Post by Ajish Babu
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
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
Post by Ajish Babu
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
Loading...