Hi, Arsalan, and anyone who has interest in ROS connecting to opencog,
From the discussions with Arsalan, first the ROS needs to input the
environment information to the opencog, and the map-info message is a bit
complex,
so I made some explanation about the map-info message format and handlling
here:
Note: this is for the old 2D spacemap.
This an xml message send to opencog PAI: This message is sent by
OCConnector.cs in the Unity project - sendMapInfoMessage()
<xsd:annotation>
<xsd:documentation>
An aggregate of all map data from virtual world which consists
of "blips".
</xsd:documentation>
</xsd:annotation>
<xsd:complexType name="MapInfoType">
<xsd:sequence>
<xsd:annotation>
<xsd:documentation>
The map data behaves much like a radar screen, a grid with a
series of blips that represent nearby entities.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="blip" type="oc:BlipType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="map-data" type="oc:MapDataType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="global-position-x" type="xsd:int" use="required"/>
<xsd:attribute name="global-position-y" type="xsd:int"
use="required"/>
<xsd:attribute name="global-position-offset" type="xsd:int"
use="required"/>
<xsd:attribute name="global-floor-height" type="xsd:int"
use="optional"/>
<xsd:attribute name="gridParcel" type="xsd:string" use="optional"/>
</xsd:complexType>
The global-position-x and global-position-y is the begin coordinates
of the whole map,
The global-position-offset is the size of the map, in our old 2D
spaceMap, we require the map to be a square,
So, if global-position-x = 10, global-position-y = 20,
global-position-offset = 50,
then the max_x = 10+50 = 60, max_y = 20+50 = 70;global-floor-height is
the height of the floor, it's optional, you dont need to include it in
the message, or just set it to be 0.
gridParcel is not used now, just neglect it.
So basicly every map-info message contain the same
Note: there are 2 processMapInfo() in the PAI, one is using protobuf,
another one doesn't, you don't need to use the protobuf.
The protobuf one while the MapDataType xml element, no-protobuf one
process the BlipType xml element.
*There are corresponding xml tag definitions in
opencog/embodiment/Control/PerceptionActionInterface/PVPXmlConstants.h*
If you have any questions pls feel free to ask me.
Originally put together by the Brazilian team, which I subsequently
edited and kept up to date while involved with the HK project. However
it hasn't been edited since Aug 2011, so I'm not sure how much (if
anything) has changed.
On 4 July 2012 18:34, Shujing Ke <rainkekek...@gmail.com> wrote:
> Hi, Arsalan, and anyone who has interest in ROS connecting to opencog,
> From the discussions with Arsalan, first the ROS needs to input the
> environment information to the opencog, and the map-info message is a bit
> complex,
> so I made some explanation about the map-info message format and handlling
> here:
> Note: this is for the old 2D spacemap.
> This an xml message send to opencog PAI: This message is sent by
> OCConnector.cs in the Unity project - sendMapInfoMessage()
> <xsd:annotation>
> <xsd:documentation>
> An aggregate of all map data from virtual world which consists of
> "blips".
> </xsd:documentation>
> </xsd:annotation>
> <xsd:complexType name="MapInfoType">
> <xsd:sequence>
> <xsd:annotation>
> <xsd:documentation>
> The map data behaves much like a radar screen, a grid with a
> series of blips that represent nearby entities.
> </xsd:documentation>
> </xsd:annotation>
> <xsd:element name="blip" type="oc:BlipType" minOccurs="0"
> maxOccurs="unbounded"/>
> <xsd:element name="map-data" type="oc:MapDataType" minOccurs="0"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> <xsd:attribute name="global-position-x" type="xsd:int"
> use="required"/>
> <xsd:attribute name="global-position-y" type="xsd:int"
> use="required"/>
> <xsd:attribute name="global-position-offset" type="xsd:int"
> use="required"/>
> <xsd:attribute name="global-floor-height" type="xsd:int"
> use="optional"/>
> <xsd:attribute name="gridParcel" type="xsd:string" use="optional"/>
> </xsd:complexType>
> The global-position-x and global-position-y is the begin coordinates of the
> whole map,
> The global-position-offset is the size of the map, in our old 2D spaceMap,
> we require the map to be a square,
> So, if global-position-x = 10, global-position-y = 20,
> global-position-offset = 50,
> then the max_x = 10+50 = 60, max_y = 20+50 = 70;
> global-floor-height is the height of the floor, it's optional, you dont need
> to include it in the message, or just set it to be 0.
> gridParcel is not used now, just neglect it.
> So basicly every map-info message contain the same
> Note: there are 2 processMapInfo() in the PAI, one is using protobuf,
> another one doesn't, you don't need to use the protobuf.
> The protobuf one while the MapDataType xml element, no-protobuf one process
> the BlipType xml element.
> There are corresponding xml tag definitions in
> opencog/embodiment/Control/PerceptionActionInterface/PVPXmlConstants.h
> If you have any questions pls feel free to ask me.
> Many thanks,
> Shujing
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To post to this group, send email to opencog@googlegroups.com.
> To unsubscribe from this group, send email to
> opencog+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opencog?hl=en.
> Hi, Arsalan, and anyone who has interest in ROS connecting to opencog,
> From the discussions with Arsalan, first the ROS needs to input the
> environment information to the opencog, and the map-info message is a bit
> complex,
> so I made some explanation about the map-info message format and handlling
> here:
> Note: this is for the old 2D spacemap.
> This an xml message send to opencog PAI: This message is sent by
> OCConnector.cs in the Unity project - sendMapInfoMessage()
The reason I ask is because:
-- XML parsing is very slow; last time I measured, 4-5 years ago, the XML
parser was 4x or 5x slower than the guile interpreter. So, just for raw
data input, one gets a big performance boost by avoiding XML.
-- XML messages are very verbose. This clogs up ethernet, etc. and leads to
more slowdowns.
-- XML messages are hard to read (for a human) and thus are hard to debug...
I've not measured the speed of the python interpreter, but perhaps its
comparable to that of guile. I don't know if we have anything for json,
but surely that would be faster than xml. Perhaps the RESTful interfaces,
too, I dunno.
I would recommend using either python or guile; both offer one more
advantage that xml does not: it becomes very easy to make changes, while
maintaining backwards-compatibility. So, for example, suppose you decide
that PositionXNode, etc. is not the right input, but you don't want to
change the robot. You can always write a thin wrapper
(define (PositionXNode x) (PositionBlah (sqrt (* x 3.1416))))
or whatever, to quickly convert from one format to another, without writing
any c++ code, without recompiling.
Yea, the xml messages in the embodiment are very old and unconvenient.
So I am now using zmq + protobuf for new stuff like new learning server.
But the PAI & Unity xml messages has been being implemented from 1.5 year
ago,which has a lot of codes in both opencog and Unity sides. After Joel,
Troy and zhenhua left, I am the only person who is working on embodiment.
But I am not supposed to be working on the embodiment for ever - just no
one else want to deal with this ugly module. This year my works should be
focused on 3D spaceMap, new learning server, Entity identification, Event
detection...really a lot of works...I can only try my best to use better
elegant methods to implement these new stuff, but I really have no time to
modify all the old ugly stuff in the embodiment.
If anyone can really take the job to replace the xml messages in the
embodiment with a better format, we'll appreciate a lot.
> On 4 July 2012 01:34, Shujing Ke <rainkekek...@gmail.com> wrote:
>> Hi, Arsalan, and anyone who has interest in ROS connecting to opencog,
>> From the discussions with Arsalan, first the ROS needs to input the
>> environment information to the opencog, and the map-info message is a bit
>> complex,
>> so I made some explanation about the map-info message format and
>> handlling here:
>> Note: this is for the old 2D spacemap.
>> This an xml message send to opencog PAI: This message is sent by
>> OCConnector.cs in the Unity project - sendMapInfoMessage()
> The reason I ask is because:
> -- XML parsing is very slow; last time I measured, 4-5 years ago, the XML
> parser was 4x or 5x slower than the guile interpreter. So, just for raw
> data input, one gets a big performance boost by avoiding XML.
> -- XML messages are very verbose. This clogs up ethernet, etc. and leads
> to more slowdowns.
> -- XML messages are hard to read (for a human) and thus are hard to
> debug...
> I've not measured the speed of the python interpreter, but perhaps its
> comparable to that of guile. I don't know if we have anything for json,
> but surely that would be faster than xml. Perhaps the RESTful interfaces,
> too, I dunno.
> I would recommend using either python or guile; both offer one more
> advantage that xml does not: it becomes very easy to make changes, while
> maintaining backwards-compatibility. So, for example, suppose you decide
> that PositionXNode, etc. is not the right input, but you don't want to
> change the robot. You can always write a thin wrapper
> (define (PositionXNode x) (PositionBlah (sqrt (* x 3.1416))))
> or whatever, to quickly convert from one format to another, without
> writing any c++ code, without recompiling.
> --linas
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To post to this group, send email to opencog@googlegroups.com.
> To unsubscribe from this group, send email to
> opencog+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opencog?hl=en.
Yeah, using XML is a legacy decision from the petaverse project.
I spent a fair amount time making the XML parsing sane, as it used to have
100s of copy pasted lines. But I didn't fully understand the embodiment
messages enough to feel confident to replace the underlying format.
On Monday, 9 July 2012, Shujing Ke wrote:
> Hi, Linas Vepstas
> Yea, the xml messages in the embodiment are very old and unconvenient.
> So I am now using zmq + protobuf for new stuff like new learning server.
> But the PAI & Unity xml messages has been being implemented from 1.5 year
> ago,which has a lot of codes in both opencog and Unity sides. After Joel,
> Troy and zhenhua left, I am the only person who is working on embodiment.
> But I am not supposed to be working on the embodiment for ever - just no
> one else want to deal with this ugly module. This year my works should be
> focused on 3D spaceMap, new learning server, Entity identification, Event
> detection...really a lot of works...I can only try my best to use better
> elegant methods to implement these new stuff, but I really have no time to
> modify all the old ugly stuff in the embodiment.
> If anyone can really take the job to replace the xml messages in the
> embodiment with a better format, we'll appreciate a lot.
> On 4 July 2012 01:34, Shujing Ke <rainkekek...@gmail.com> wrote:
> Hi, Arsalan, and anyone who has interest in ROS connecting to opencog,
> From the discussions with Arsalan, first the ROS needs to input the
> environment information to the opencog, and the map-info message is a bit
> complex,
> so I made some explanation about the map-info message format and handlling
> here:
> Note: this is for the old 2D spacemap.
> This an xml message send to opencog PAI: This message is sent by
> OCConnector.cs in the Unity project - sendMapInfoMessage()
> The reason I ask is because:
> -- XML parsing is very slow; last time I measured, 4-5 years ago, the XML
> parser was 4x or 5x slower than the guile interpreter. So, just for raw
> data input, one gets a big performance boost by avoiding XML.
> -- XML messages are very verbose. This clogs up ethernet, etc. and leads
> to more slowdowns.
> -- XML messages are hard to read (for a human) and thus are hard to
> debug...
> I've not measured the speed of the python interpreter, but perhaps its
> comparable to that of guile. I don't know if we have anything for json,
> but surely that would be faster than xml. Perhaps the RESTful interfaces,
> too, I dunno.
> I would recommend using either python or guile; both offer one more
> advantage that xml does not: it becomes very easy to make changes, while
> maintaining backwards-compatibility. So, for example, suppose you decide
> that PositionXNode, etc. is not the right input, but you don't want to
> change the robot. You can always write a thin wrapper
> (define (PositionXNode x) (PositionBlah (sqrt (* x 3.1416))))
> or whatever, to quickly convert from one format to another, without
> writing any c++ code, without recompiling.
> --linas
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To post to this group, send email to opencog@googlegroups.com.
> To unsubscribe from this group, send email to
> opencog+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opencog?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To post to this group, send email to opencog@googlegroups.com.
> To unsubscribe from this group, send email to
> opencog+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/<http://groups.google.com/group/opencog?hl=en>
On 8 July 2012 22:57, Shujing Ke <Shujin...@gmail.com> wrote:
> Hi, Linas Vepstas
> Yea, the xml messages in the embodiment are very old and unconvenient.
> So I am now using zmq + protobuf for new stuff like new learning server.
> But the PAI & Unity xml messages has been being implemented from 1.5 year
> ago,which has a lot of codes in both opencog and Unity sides. After Joel,
> Troy and zhenhua left, I am the only person who is working on embodiment.
> But I am not supposed to be working on the embodiment for ever - just no
> one else want to deal with this ugly module. This year my works should be
> focused on 3D spaceMap, new learning server, Entity identification, Event
> detection...really a lot of works...I can only try my best to use better
> elegant methods to implement these new stuff, but I really have no time to
> modify all the old ugly stuff in the embodiment.
That's fine; I'm not really asking you to do anything, I was just
commenting on the general ideas. I am quite aware of old ugly code, the
need to fix it, and the lack of time -- and that's because I wrote a lot of
it (not this code, but other code -- one learns by doing, and often it
takes 2-3-4 tries before it comes out right).
