ERS-7 porting progress

1. Ad-hoc wireless is working now, as stated in AiboPet's reply in the forum:

| >>> APMODE=0
| >Sorry I missed this the first time.
| >
| >Don't set the mode to 0, keep it to 2 (automatic) for all uses
| >APMODE=2
| >
| >It will automatically work in either Infrastructure (when within range of an
| >access point) or Ad-Hoc.
| >
| >In the Ad-Hoc case, the PC WiFi card
| >+ must be setup to Ad-Hoc as well
| >+ must be on the same channel
| >+ same SSID, WEP etc of course
| >
| >AND MOST IMPORTANT:
| >+ must be running BEFORE you boot AIBO (ie. Link light on or flashing)

But it is still unstable, need to tweak a lot everytime.

2. Now it is able to control ERS-7's head by mouse. However, the legs are not working.

3. All the motions are modified for ERS-7. Since legs are not working, can't really test them.

The major differences between ERS7 and ERS210A

Beside the differences in shapes, they also differ in following aspects:

1. The software limitation for joint angle in legs.
   
2. The roll joint for neck in ERS210A is removed in ERS7, another titl joint is added.
   
3. Pressure based touch sensors are changed to static eletric based touch sensors in ERS7 (?)
4. The joints for tail is not changed, execept the position of the joints.

These are obvious changes I have noticed. Porting software from ERS210A to ERS7 are mainly based on these changes.

Problems also found in MovingLegs7.cc from the given samples

I am currently working on porting the software written for ERS-210A to ERS-7 from McMaster University Engineering Office.

I've just read the sample program MovingLegs7.cc and found that:

const double BROADBASE_ANGLE[] = {
120, // RFLEG J1
90, // RFLEG J2
30, // RFLEG J3

120, // LFLEG J1
90, // LFLEG J2
30, // LFLEG J3

-120, // RRLEG J1
70, // RRLEG J2
30, // RRLEG J3

-120, // LRLEG J1
70, // LRLEG J2
30 // LRLEG J3
};

Since the lower bound for LRLEG J1 is -115 degrees, according to the Model
Information documents for ERS-7, how is that possible for LRLEG J1 to be -120
degrees?

Since the upper bound for RFLEG J1 is 115 degrees, according to the same Model
Information documents, how is it possible for RFLEG J1 to be 120 degrees?

I do suspect it is a typo error in the Model Information for ERS7

APPENDIX: Software Limitations of Joint Motions from Model Information for ERS7:

2.1.1 Single Joints Parts Range (Unit: degree)
Neck tilt1 (-75, 0)
Neck pan (-88, 88)
Neck tilt2 (-15, 45)
Mouth (-55, -3)
Left leg(front/rear)J1 (-115, 130)
Left leg(front/rear)J2 (-10, 88)
Left leg(front/rear)J3 (-25, 122)
Right leg(front/rear)J1 (-130, 115)
Right leg(front/rear)J2 (-10, 88)
Right leg(front/rear)J3 (-25, 122)
Tail tilt (5, 60)
Tail pan (-45, 45)

Can I control the DoStart() startup order for all objects by using IsReady()?

As replied in OPEN-R BBS by aibopet:

Well you aren't controlling the startup order of the objects.
The 'IsReady' logic is meant to handle any possible startup order, and the
multi-tasking nature of the operating system.
The technique can be used to fix other possible startup conflicts [but can be
hard to test]

The order can be random, and what happens before an object is ready to receive
notifications depends on how the object is implemented. The order of the
OBJECT.CFG file usually decides the order, but it isn't always that simple.

Other alternatives:
[ie. the fewer calls to IsReady, the better IMHO]
If you are building more complicated objects communicating to eachother,
another solution is to not send notifications until everything is up and
running (ie. all objects have returned from DoStart).
Then you can have one object start the real behavior.

Finally there is an undocumented? feature of the .OCF file where you can set
the priority for an object. The default is 128. Objects with larger numbers
are loaded first. I would only play with that as a last resort if you have
race condition problems.

Video Streaming Implemented.

Screenshot:



Screenshots before the bugs were fixed:

Two methods of sending TCP/IP packets in OPEN-R Internet Programming

I've asked a question about sending TCP/IP packets in OPEN-R, and the reply from AiboPet is:

[two replies merged]
> Here is my Snd() routine:...
> I didn't follow the way the samples did.

> sndMsg.Call(IPStack, sizeof(TCPEndpointSendMsg));

That's one way to do it. It *should* block until the SendMsg is processed.
That may cause problems since this can take a long time.

However, in this case I'm not sure if all other notifications are blocked.
I had some strange problems trying to use Call before (and went back to using
Send and a second callback)

------
>What happens after the following statement is executed?
>sendMsg.Send(ipstackRef, myOID_, Extra_Entry[entrySendCont],
>sizeof(TCPEndpointSendMsg));

That's the other way - and the way I use all the time (also in the samples)
and is recommended.
The statement returns immediately. When the request is completed, it will call
your routine "SendCont".

In this case there are two radically different "Send"s
The sendMsg structure contains the TCP/IP Send request (ie. send data from
AIBO to PC).
The "Send" function being called is the OPEN-R object communication notion of
send (ie. send data from your process to the TCP/IP handler/stack)

I suggest reworking the code to use this technique, and I suspect the
collision problem will go away.

RE:video streaming from Aibo to PC

I posted a question about video streaming from Aibo to PC in OPEN-R forum:

| Hi,

|

| In past weeks I tried to implement the video streaming from Aibo to PC. The main

| idea is to have a buffer (array of 44x38x3) in the Aibo storing the YUV data

| received from Camera. Every time the main program is notified by FbkImageSensor,

| it send the whole buffer to the client by TCP/IP connection. The client does the

| YUV2RGB convertion.

|

| The problem is, the video received by the client is corrupted. Here are 3

| screenshots:

|

| http://msw.mcmaster.ca/~wangy/temp/s1.png

| http://msw.mcmaster.ca/~wangy/temp/s2.png

| http://msw.mcmaster.ca/~wangy/temp/s3.png

|

| However, if I make the server only transmit the first frame, the image received

| by client is fine.

|

| The wireless mode for Aibo and PC is ad-hoc, so I think the network delay can be

| ignored.

|

| Here is the code of Notify() to be called by subject FbkImageSensor:

|

| void gEye::Notify(const ONotifyEvent& event)

| {

| if (gEyeState == _IDLE) {

| return;

| //do nothing

| }

|

| static int x, y;

|

| OFbkImageVectorData* fbkImageVectorData

| = (OFbkImageVectorData*)event.Data(0);

|

| OFbkImageInfo* info = fbkImageVectorData->GetInfo(layer);

| byte* data = fbkImageVectorData->GetData(layer);

|

| OFbkImage current_Y(info, data, ofbkimageBAND_Y);

| OFbkImage current_Cr(info, data, ofbkimageBAND_Cr);

| OFbkImage current_Cb(info, data, ofbkimageBAND_Cb);

|

| gEye_snd_data.width = info->width;

| gEye_snd_data.height = info->height;

|

| if ((current_Y.IsValid() == true)

| && (current_Cr.IsValid() == true)

| && (current_Cb.IsValid() == true)){

|

| for (y = 0; y < info->height - 1; y++){

| for (x = 0; x < info->width; x++){

| gEye_snd_data.image[x][y][0] =

| current_Y.Pixel(x, y);

| gEye_snd_data.image[x][y][1] =

| current_Cr.Pixel(x, y);

| gEye_snd_data.image[x][y][2] =

| current_Cb.Pixel(x, y);

| }

| }

| Snd();

| }

| observer[event.ObsIndex()]->AssertReady(event.SenderID());

| }

|

| Any helps are appreciated.

|

| Yu

And it got replied from aibopet:

My guess is the old data has not being completely transmitted before the next

Image notification comes in (and over-writes the old data).

This will depend what is going on in your 'Snd()' routine. It should lock out

the buffer access until all the data is transmitted, and/or copy it to the

TCP/IP buffer first.

In most of the other TCP/IP samples (eg: EchoServer/Client) copy the data to a

transmit buffer before starting the send process ('SetSendData' or something

like that, followed by 'Send'). The transmission is not complete until

the 'SendCont' callback is called.

AIBO Camera resolutions

Searched from here:
https://openr.aibo.com/cgi-bin/openr/e_regi/im_trbbs.cgi?uid=general&df=bbs.dat&prm=TAN&pg=-1&no=0832#0832
"
H Layer - 176x144 (or 208x160 for the ERS-7)
M Layer - half that 88x76 (or 104x80 for the ERS-7)
L Layer - half that again 44x38 (or 52x40 for the ERS-7)

The C Layer (color detection) is the same resolution as the M layer. One byte per pixel.

With the latest SDKs (1.1.4 for 2x0 and 1.1.5 for ERS-7) it captures additional bands where you can combine to build a double-H layer (called "HR" layer in the sample)

Synthetic "HR" Layer - 352x244 (or 416x320 for the ERS-7)
"

[BBS] How are RCRegion, OShmPtrBase and OShmPtr related?

RE:How are RCRegion, OShmPtrBase and OShmPtr related? AiboPet [2004/05/16-01:36]

>Could anyone tell me what are the relations between RCRegion, OShmPtrBase and
>OShmPtr? What is MemID? Are there any documentations other than the reference
>guide talking about these concepts?

These are mostly undocumented internals of OpenR. You can figure most of them
out by looking at the headers.

MemID (MemoryRegionID) is the lowest level memory allocation chunk (like a
memory handle in other operating systems) - for sharing memory between
processes.
RCRegion is a C++ class that encapsulates a MemID and includes other features
like reference counting and memory offset addressing
OShmPtr is a C++ template class that encapsulates a MemID and includes C++
type-safe access to the data
OShmPtrBase is used to help implement OShmPtr

My general advice is to use them when needed for other APIs (usually RCRegion
when calling SetData etc), and ignore them otherwise.
Inside your own program, use any memory allocation technique you want (eg:
normal C++ operator new/delete)

Guide for studying Tekkotsu

1. Read the OPEN-R SDK Programmer's Guide

2. Read the overview of Tekkotsu Framework:

http://www-2.cs.cmu.edu/~tekkotsu/Overview.html

3. (Optional) Review C++:

http://www-2.cs.cmu.edu/~tekkotsu/CPPReview.html

4. Go through BehaviorBase class:

http://www-2.cs.cmu.edu/~tekkotsu/dox/classBehaviorBase.html

5. Read the tutorials:

http://www-2.cs.cmu.edu/~tekkotsu/Tutorials.html