Explanation about embodiment map-info

[Shujing Ke]

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()

<?xml version="1.0" encoding="UTF-8"?>
<oc:embodiment-msg xsi:schemaLocation="http://www.opencog.org/brain BrainProxyAxon.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:oc="http://www.opencog.org/brain">
  <map-info global-position-x="24" global-position-y="24" global-position-offset="48" global-floor-height="99">
    <map-data timestamp="2012-07-04T13:50:33.854"> ...  </map-data>
  </map-info>
</oc:embodiment-msg>

The format of this map-info message is in   /opencog/embodiment/Control/PerceptionActionInterface/BrainProxyAxon.xsd

    <xsd:element name="map-info" type="oc:MapInfoType"/>

    <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

        <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"/>

unless your map size is changed.

And the actual information of the location etc of the entity in a map-info is in:

<xsd:element name="blip" type="oc:BlipType" minOccurs="0" maxOccurs="unbounded"/>

And you can also find the format of "blip" in the BrainProxyAxon.xsd:

    <xsd:complexType name="BlipType">
        <xsd:sequence>
            <xsd:element name="entity" type="oc:EntityType" minOccurs="1" maxOccurs="1"/>
            <xsd:element name="position" type="common:VectorDataType" minOccurs="1" maxOccurs="1"/>
            <xsd:element name="rotation" type="common:RotationDataType" minOccurs="1" maxOccurs="1"/>
            <xsd:element name="velocity" type="common:VectorDataType" minOccurs="1" maxOccurs="1"/>
            <xsd:element name="dimension" type="common:VectorDataType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="properties" type="oc:PropertiesType" minOccurs="0" maxOccurs="1"/>
         </xsd:sequence>
         
        <xsd:attribute name="timestamp" type="xsd:dateTime" use="required"/>
    </xsd:complexType>

And the parsing of a map-info is in PAI:

void PAI::processMapInfo(DOMElement * element, HandleSeq &toUpdateHandles)


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

[Joel Pitt]

There is also:

http://wiki.opencog.org/w/EmbodimentProxyMessages_(Embodiment)

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.

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To post to this group, send email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to
> opencog+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opencog?hl=en.

[Linas Vepstas]

On 4 July 2012 01:34, Shujing Ke <rainke...@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()

<?xml version="1.0" encoding="UTF-8"?>
<oc:embodiment-msg xsi:schemaLocation="http://www.opencog.org/brain BrainProxyAxon.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:oc="http://www.opencog.org/brain">
  <map-info global-position-x="24" global-position-y="24" global-position-offset="48" global-floor-height="99">
    <map-data timestamp="2012-07-04T13:50:33.854"> ...  </map-data>
  </map-info>
</oc:embodiment-msg>

Why XML? Why not some native, easy-to-read opencog format, for example, something like this:

(MapInfoLink

   (PositionXNode "24")

   (PositionYNode "24")

   (PositionZNode "48")

...etc...

) 

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

[Shujing Ke]

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.

Shujing

2012/7/9 Linas Vepstas <linasv...@gmail.com>

--

[Joel Pitt]

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.

--
Joel Pitt, PhD | http://ferrouswheel.me | +6422 189 2817
Skype: ferrouswheel

[Linas Vepstas]

Hi,

On 8 July 2012 22:57, Shujing Ke <Shuj...@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). 

--linas