In a word, no. Everything goes through the WiFi link. There is no storage capability on the EZB4 itself. The best way to reduce the load on the WiFi system is to insure you limit the amount of data you send to the robot. For example, don't send a constant stream of requests for a sensor's data. Send one at reasonable intervals like every quarter or half second. Things like that. The general stuff sent to the robot to make it move should not be all that much of a load on your system in the first place, so I would not worry too much about that.

Ah OK. Yeah I will just do what I can to keep the load down. For a really cool robot platform it is interesting that all of the processing is done on a remote computer and not the ARM processor. It is simpler on the front end, but seems less efficient for a robotics platform. I know that running the code on board won't have the same capabilities, but it would be pretty awesome if you could load code onto the controller via wifi, a serial capable bootloader, or ISP. It would open some doors for much faster sensor response time and possibly allow for interrupts. Anyways... I am just rambling.

Thanks for the quick response! -Eric

@ericsims interrupts? Geez dude you been hangin' around the Arduino camp and the '90s too long.... The ezb/ARC is fully multi tasking.... The way it works now is you can change/adjust your code on the fly (unlike the Arduino)... meaning accelerated robot programming...

Don't worry... if you hang around here long enough we will be able to "beat" the Arduino outta' ya'..... I am saying this is because I used to use Arduino, but got bored of building boring line following and obstacle avoiding robots....

Haha. Yeah I see what you mean... when you can have a bunch of threads... However, it is nice to not use an entire thread to poll one digital pin waiting... But its not arduino, I love the LPC11U24 (which is still kinda old)... Many people cling to the Arduino for some reason...

I have LPC11Uxx on some pcbs for projects great for embedded stuff where you don't need the whole dev platform.

-Eric

@ericsims .... just ribbin' ya'.... Hope you stick around you seem like a real educated robot guy.... welcome....

HI Eric,

@WBS and @RR have you well covered but I figured I'd jump in and add that there's always the ability to use the ez-b as the master and an arduino or LPC11Uxx as a slave device feeding the master sensor data, interfacing to addressable LEDs, etc. You can interface to a slave device via uart or I2C if you'd like and have a hybrid robotic system. A few forum members have gone this route, check out some other threads around the forum if you are curious.

@richard lol I know. And thanks! That means a lot to me!

@jeremie I will have to check that out! I thought about this before, but didn't want to exercise that much effort.

I also have another question for you guys: I know that the sdk contains a lot of useful stuff, but is there some way to call programs created in ezbulider from the sdk? This would be the same kind of thing. I am trying to streamline my idea, but retain the ability to use the ezbulider 'in line' with the rest of my code.

Thanks -Eric

@Eric I'm actually not sure if you can call ARC project files with the SDK, I'll have to leave that for someone else to answer but I wanted to make you aware of the huge, new ARC feature, check out this thread!

You can now write your own plugins that become custom ARC controls within the GUI. This essentially opens up ARC for all kinds of third party development.