You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Consider the following example:
The multiple definitions makes it difficult to define functions with specific definitions depending on the type of the ROS msg as in:
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
The text was updated successfully, but these errors were encountered: