[ros-users] roslua: creating messages with subtypes

Tim Niemueller niemueller at kbsg.rwth-aachen.de
Wed Jun 15 12:59:55 UTC 2011


On 21.02.2011 17:32, Markus Klotzbuecher wrote:
> Dear List,

Hi Markus.

Just catching up with emails from the ROS list.

> I just gave roslua a try and its working quite nicely. One smaller
> problem I noticed is when printing some array types:
> 
> $ lua -lroslua
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>> twist = roslua.get_msgspec("geometry_msgs/Twist")
>> t=twist:instantiate()
>> t:print()
> geometry_msgs/Twist
> /home/mk/src/git/lua/roslua/src/roslua/msg_spec.lua:53: attempt to call method 'find' (a nil value)
> stack traceback:
>       /home/mk/src/git/lua/roslua/src/roslua/msg_spec.lua:53: in function 'is_array_type'
>       /home/mk/src/git/lua/roslua/src/roslua/message.lua:259: in function 'print_value'
>       /home/mk/src/git/lua/roslua/src/roslua/message.lua:285: in function 'print'
>       stdin:1: in main chunk
>       [C]: ?
>>

Can you try with the latest version, I added several fixes since back
then. Does that solve your problem?

> Secondly I wondered if there is a more compact way to create messages
> which contain submessages. For instance to create and fill a
> "geometry_msgs/Twist" I did the following:
> 
> local Vector3=roslua.get_msgspec("geometry_msgs/Vector3")
> 
> local m = p.msgspec:instantiate() -- geometry_msgs/Twist message
> local vec3lin = Vector3:instantiate()
> local vec3ang = Vector3:instantiate()
> 
> vec3lin.values.x=x
> vec3lin.values.y=y
> vec3lin.values.z=z
> vec3ang.values.x=xang
> vec3ang.values.y=yang 
> vec3ang.values.z=zang
> 
> m.values.linear = vec3lin
> m.values.angular = vec3ang

This should no longer be necessary, can you please verify with the
latest git version?

> Before that I tried 
> 
> m.values.linear.x = x
> m.values.linear.y = y

This must be:
m.values.linear.values.x = x

I have added the values table to make the fields easier to distinguish
from existing method names and fields. We might reconsider if this was a
wise decision, because it is especially ugly for such nested types as this.

I'll think about it using a setter meta table to verify that only field
are set. It might also be just a convenience redirect to the values
table, or possibly a compatibility wrapper for some time.

	Tim

-- 
KBSG - Knowledge-Based Systems Group            AllemaniACs RoboCup Team
========================================================================
http://robocup.rwth-aachen.de                     RWTH Aachen University
http://kbsg.rwth-aachen.de                               Ahornstrasse 55
http://www.fawkesrobotics.org                             D-52056 Aachen



More information about the ros-users mailing list