Pleo with WiFi SD Card

[ward1e]

Hi,

I have recently recieved a pleo for christmas, and although I have been very impressed with what it can do so far but I do still feel that it is missing a lot of features that could be implemented through programming so hopefully ugobe or the programming community will be able to help out. When the SDK is finallly released.

I have a personal intrest in robotics, and electronics and have built my own CNC machine from scratch before. I also can program in several languages and have expierence developing applications for Windows Mobile Devices with C++ and C# but I still have no expierence with PAWN.

The main concern that I have at the moment still is the lack of memory and performance that pleo currently offers to enable much more complex behaviours without a serious investment in optimising every last detail for the RAM/Processor constraints. This made me think back to when PDAs had no WiFi built in, and somebody thought up the idea of integrating WiFi into an SD card to enable the feature for PDAs. These WiFi SD cards can be had in the UK for around £25 now.

I was just wondering if it would be possible even theoretically if it hasn't been attempted by Ugobe to use one of these WiFi SD cards to interface with pleo and offload the majority of the processing to a PC or something with a lot more RAM and speed as it would open a lot more possiblities for programming the pleo or simiply controlling it remotely?

Thanks

Ben

[Primus]

Is it possible? Maybe, but to what end? What processing would you have your PC do that Pleo can't currently do?

[roschler]

HI have a personal intrest in robotics, and electronics and have built my own CNC machine from scratch before. I also can program in several languages and have expierence developing applications for Windows Mobile Devices with C++ and C# but I still have no expierence with PAWN.


Ben,

Don't worry. PAWN is one of those scripting languages that's straight out of the C syntax barn like PHP, etc. In fact it's C syntax without all the nasty parts of C like memory management, pointer suicide, etc. I have not used it myself but I read about it and that's the impression I got.

[PleoPet]

There are two kinds of SD memory+WiFi cards.
One kind is for specific PDAs that have an "SDIO" slot and the proper drivers (typically PocketPC only). Unlikely to work with Pleo for a number of reasons.

The other kind (newer "Eye-Fi") uses WiFi under the covers to transfer photos between the PC. When Pleo saves a photo on the SD card (possible today with the debug terminal or with a simple PAWN program), it should be visible on the PC.
That kind of card should work, however it would be a slow process for a low quality photo. I don't know bad the power drain would be (WiFi can take a lot of power). An RF 'spy-cam' taped to the Pleo's head/back would be cheaper, higher quality and frame rate.

----
There are interesting scenarios where Pleo's brain can be supplemented by a PC. The Pleo's main CPU is programmable with Pawn, and it good enough for most simple calculations and general entertainment personalities. For anything more complicated, you can't beat a PC.
However you don't need much radio bandwidth between the PC and the robot - if you avoid transfering pictures and sound (which are difficult to do for other reasons). WiFi is overkill. An RF transceiver attached to serial port makes more sense to talk to the main Pleo CPU
http://www.aibohack.com/pleo/xbee_pleo.jpg
BTW: the earlier prototype models had a Bluetooth connector inside as well.

There are other Wireless options. It all depends on what you are trying to do. For vision based algorithms for room navigation, it is much easier to hook up a fixed webcam to your computer and see where Pleo is walking within the room. The robot can act as a remote control performer under control of the PC.

[cmadmacs]

very good information. I'm learning so much.

[UgobeTyler]

Good day,

The main issues with the SDIO WiFi solution are the additional resource requirements. We would need to add some kind of IP stack, which of course takes ROM and RAM (and this should come as no surprise, but we used up the majority of the space available in Pleo [given any amount of flash or memory, we will fill it up!]).

I am intrigued by the Eye-Fi solution. If it is an open standard, it could be something worth investigating. If anybody has links to more technical detail, post a reply.

FYI, if the idea is to take pictures with the built-in Pleo camera, be warned: the current Pleo hardware uses a UART connection between the main Atmel ARM7 and the head NXP ARM7 processor, which is the bottleneck when it comes to capturing images. And I should also add that we did not design Pleo to "take pictures" anyway!

Thank you,
Tyler

[Primus]

http://www.eye.fi/

[PleoPet]

Semi-related news: http://www.engadget.com/2008/01/08/lexar-to-license-eye-fis-wifi-sd-tech/
As mentioned, the Pleo camera is not designed for processing or fast transfer to the main CPU. A few frames per *minute* if you are lucky.

[Xasher]

I don’t believe the amount of memory should be a problem. I currently have a robot I built and programmed myself using a 2 kb IC chip and I have been able to control 4 servos, to walk forward, back, left and right turn while monitoring 4 IR sensors 2 sonic sensors and a Flame detecting sensor. It utilizes over 2000 lines of code in 2 KB of memory with over 20 WORD variables.
Now the amount of memory available will all depend on how they utilize the Pawn program. Is Pawn built into the IC chip? When I program the IC chip in my robot I compile the program into Hex language before flashing it to the chip. If pawn does the same the amount of memory usage would be tiny. If the IC chip has the Pawn program built into it, not unlike the STAMP 2 IC chips, most of the internal memory on the chip could be being utilized by the programming language. Since all the programming in Pleo fits into 8mb of memory flashed onto the IC chip, according to the website, I suspect they are compiling the information before flashing onto the chip. If that is the case a small 64mb SD card should hold a lot of code.
Most of the hardcore programming is already in Pleo’s code, to rewrite the motor controls and sensor detection should not be necessary. So specific movement combinations and AI will be all that is necessary to add to the existing code.

[UgobeTyler]

Xasher,

The way we implemented the Pawn VM allows us to execute arbitrarily large scripts - we call this code blocking. Note we are currently based on Pawn 3.2. The new Pawn 3.3 has built-in support for what they call overlays, which is similar to what we did, but it is even better, since it breaks up the code on function boundaries (ours uses fixed 512 byte blocks). Additionally, Pawn 3.3 has an option to pack code, making it - on average - about 35% smaller (our numbers - your mileage may vary). We are investigating the new Pawn 3.3 release because of these features. So far it is promising, but there is still more tuning that needs to be done.

One real memory limitation in the VM is the fixed size of the data plus stack. Right now it varies between 2K and 4K per virtual machine. On the plus side, you can adjust your stack size to gain more data space.

Thank you,
Tyler

[Xasher]

I apologize for going off subject on my above post. I accidently posted it under the wrong topic.:o Thanks for the response though Toby

[roschler]

PleoPet,

Are you already using the XBee to talk between the Pleo and a PC, or is that purely a conceptual photo? How are you doing that without the PDK?

Also, what serial port? I only see an SD card slot and a USB port on the bottom of Pleo? Did you manage to thread wires all the way through Pleo's belly to the internal UART Tyler mentioned?

Thanks,
Robert

[ryane]

i believe you just have to remove a plastic piece to uncover the port.

[PleoPet]

> Are you already using the XBee to talk between the Pleo and a PC, or is that purely a conceptual photo?
Real photo - works great. Someone else wired up the BlueSmurf module using a similar approach.
I recommend the XBee over the BlueSmurf or a wired USB because the link stay alive on the PC side even if the robot is turned off and back on (you do that a lot when swapping SD cards)

> How are you doing that without the PDK?
Without the PDK, you can poke around with the built-in debug monitor commands, muck around with the running personality, view interesting statistics etc. You can do that with the USB cable too.
FWIW: I do have the pre-release PDK (that's how I wrote YAPT)

>...i believe you just have to remove a plastic piece to uncover the port.
See the photo here: http://www.pleodreams.com/node/7
(NOTE: it is a serial port, 3.3V levels, power and ground, email me if you want pinouts)
So far I haven't found an easily available connector.
======
Also tried an Eye-Fi card, but I haven't got it to work yet (a problem with the EyeFi I suspect, it has a *unique* way of connecting over WiFi)

[Shagz]

Xasher,

The way we implemented the Pawn VM allows us to execute arbitrarily large scripts - we call this code blocking. Note we are currently based on Pawn 3.2. The new Pawn 3.3 has built-in support for what they call overlays, which is similar to what we did, but it is even better, since it breaks up the code on function boundaries (ours uses fixed 512 byte blocks). Additionally, Pawn 3.3 has an option to pack code, making it - on average - about 35% smaller (our numbers - your mileage may vary). We are investigating the new Pawn 3.3 release because of these features. So far it is promising, but there is still more tuning that needs to be done.

One real memory limitation in the VM is the fixed size of the data plus stack. Right now it varies between 2K and 4K per virtual machine. On the plus side, you can adjust your stack size to gain more data space.

Thank you,
Tyler

I actually was curious about this., I assume from reading some posts on here, that "Disk Space" is partially a non issue, since even the smallest SDs should be plenty (from the sounds of it).

But next what's got my curiosity, is what about "Working Memory", ie.. when Pleo is running, and storing variable, etc.. how much is there to work with?

I haven't poked around very far on the site yet..(i'm in the office right now), but i will definately be checking out some of the pleoworld-links posted here and see what other treasures of info i can find =)

[eric]

this may help our hackers/programmers

http://www.ikontools.com/articles/eyefi-dissected

[PleoPet]

> But next what's got my curiosity, is what about "Working Memory", ie.. when Pleo is running, and storing variable, etc.. how much is there to work with?
Short answer: Not Enough!
The main body processor has 64KB RAM total.
These days, 64KB is not a lot of memory (http://en.wikipedia.org/wiki/Commodore_64 ).

That RAM is shared with the core firmware with many features and bells and whistles (USB driver, SD driver, low level motor control, high level personality control, Pawn interpreter, lots of cached data, ...).
Your program and data gets what is left over.

When writing your own Pawn programs, you are limited to a few KB per module. Actual limits will be decided when the PDK is finally released.
That includes space for your program code (Pawn compiled down to binary opcodes), program data and stack data. There are packing and swapping tricks.

It can be a hassle to deal with, but for most simple programs it shouldn't matter. Simple programs don't have a lot of data and compiled Pawn programs are relatively small. Large data like sounds and motions are swapped in from SD card when needed.
For more data intensive programs it can be a pain. For example the YAPT/Babe runtime is almost completely data driven (with data read from a file but kept in RAM), so if you have more than 60 conditions the program may ignore the last few.

[Shagz]

hmm, that puts a damper on some of my excitement =)

but, only temporarily....lol

granted i can easily add some "swap file" sorta of system, where all my variants would be stored on SD... but, i would imagine that'd be kind of slow. Maybe it's somethign that the Ugobe guys could implement at a lower level, that the devs would use the API to access. It would only apply to custom personalities anyways, so that means the SD would be in the slot, and could create some "swap file" for storage.

[PleoPet]

> granted i can easily add some "swap file" sorta of system, where all my variants would be stored on SD.....
The Pleo system already has that covered.
They do a great job swapping data and code from the SD card. That's why some earlier 'slower' SD cards had problems. In reality most SD cards can handle the paging/swapping speeds necessary for most typical personalities.
If you want to keep code and data resident all the time, you will hit the limits.

[kmakice]

I've had my Pleo for about six months, but I'm only now getting a chance to play with it. I would like to us a wireless SD card to be able to extend Pleo's environment to network signals.

The cards I have seen that might help make Pleo networked all come with desktop/PDA apps to manage the connectivity. Since Pleo doesn't have a screen and keyboard - only commands I can add via SD card - I have two questions:

1) Can I store scripts on an SD wireless card, in the same way I would a normal memory card?

2) Does the Pleo script come with some wireless connectivity modules?

Thanks,
Kevin

[PleoPet]

> 1) Can I store scripts on an SD wireless card, in the same way I would a normal memory card?
Yes if they are hybrid cards that are both Wireless cards and regular storage cards (including the EyeFi card)
BUT you are wasting your money. Pleo will only use the storage part. Storage only cards are much cheaper (ie. regular SD cards)

> 2) Does the Pleo script come with some wireless connectivity modules?
Not using SD cards.
See this thread: http://forums.pleoworld.com/showthread.php?t=1009
(and in particular this post http://forums.pleoworld.com/showpost.php?p=10337&postcount=4 )
FWIW: I recommend the XBee modules. Cheap and easy to hook up to a PC without dealing with Bluetooth software quirks. Hooking into the serial port on the bottom is the biggest problem.

[UgobeTyler]

All,

Here is some additional information regarding the Eye-Fi and Pleo. We did a small amount of testing, and there are currently two issues which prevent the Eye-Fi from working:

1. The Eye-Fi expects the device to store images in JPEG format. Currently in Pleo, we only support BMP format.

2. The Eye-Fi expects the images to be stored according to the DCF standard. See: http://en.wikipedia.org/wiki/DCIM

Both of these are potentially solvable in a firmware update, but neither is currently planned.

Thank you,
Tyler