Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Generate Types inside of RobotOS (and allow for definitions to be written to file). #65

Open
colinxs opened this issue Feb 19, 2019 · 0 comments

Comments

@colinxs
Copy link

colinxs commented Feb 19, 2019

Consider the following example:

module ex1
@rosimport sensor_msgs.msg: LaserScan
rostypegen(@__MODULE__)
using .sensor_msgs.msg: LaserScan
end

module ex2
@rosimport sensor_msgs.msg: LaserScan
rostypegen(@__MODULE__)
using .sensor_msgs.msg: LaserScan
end

julia> ex1.LaserScan == ex2.LaserScan
false 

The multiple definitions makes it difficult to define functions with specific definitions depending on the type of the ROS msg as in:

foo(LaserScan)
foo(Pose)

These functions are now only valid for the msg definitions in the module they were defined, and cannot be used for any other LaserScan or Pose defined elsewhere (despite being effectively the same type).

This issue would be avoided if instead rostypegen generated these modules inside of RobotOS. It appears that this is already possible via a call to rostypegen(RobotOS), so I suppose the "request" here is to remove the option to specify where the types are generated, and instead have them always be generated under RobotOS.

A second request (let me know if I should just make a separate issue for this) would be to allow for these type definitions to be written to a file and loaded by RobotOS (so that I could generate the types once on a machine with ROS and then utilize the types elsewhere). This is related to RobotOSData.jl whose owner avoided using RobotOS's typegen for this very reason.

Sorry for the wall of text!
Colin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant