Tuesday, 30 March 2010

About eLua

Well, Here is a little about eLua.
The complete port of eLua to the MCU environment (32-bits, by now) made by Mr. Bogdan Marinescu and Dado Sutter, this last one a great friend of mine from PUC-Rio and something like a tutor on this software/hardware grounds where I stand today.

For those uninformed, Lua is an interpreted language (some call a script language or dynamic language) mainly developed by Prof. Roberto Ierusalimschy (hope I got his name right =] ) also from PUC-Rio. It is very simple, small but yet powerful...So why not to use all this power on my project!?
Here is a little transcription from eLua's official site that resumes everything:

eLua stands for Embedded Lua and the project aims to offer the full implementation of the Lua Programming Language to the embedded world.

eLua is not a stripped down set of Lua to fit in the embedded environment. Much on the contrary, it strives to offer the same features as the desktop version of Lua, complementing them with specific features for embedded use and discarting the need of an operating system running on the microcontrollers. Besides offering different flavors of the full Lua implementation (like the possibility of choosing between an integer-only and a floating point numbers implementation), a lot of work was and will be done in the direction of making Lua more "embedded-friendly" by augmenting the core language with features that allow lower memory requirements and faster embedded performance.

Why Lua? Extremely well crafted, Lua is the perfect example of a minimal, yet fully functional language. Although generally advertised as a "scripting language" (and used accordingly especially in the game industry), it is also fully capable of running stand-alone programs and web services (ex: Adobe Lightroom, World of Warcraft, ...). Its limited resource requirements make it suitable to a lot of microcontroller families. The intrinsic high portability of the original Lua code (which is ANSI C and runs virtually on every platform), combined with the highly portable software architecture of eLua, allow for easy porting of the project to a large variety of architectures. The peripheral access libraries/modules exported by eLua are also portable by design, so one could run a Lua program (without or with very few modifications) on every eLua supported platform. This brings an unprecedent level of portability to the embedded aplications world. eLua inherits the minimalistic and functional design of Lua, staying in line with the well known KISS, Keep It Small and Simple philosophy.

Friday, 26 March 2010

On centralized control

Now, at the beginning of the project, I have to decide if I use a "emulated" local control or real local control.
By emulated I mean: Use a computer to send a low-level command (like "move foward" and so on) and emulate the local capabilities and knowledge of each agent on software or...
Real local control: Each robot have the complete control of it's action based on real local knowledge and processing.

I started creating a table of pros and cons of each approach to help me:

Emulated:

Pros:
  • Much simpler robots.
  • Much Cheaper robots (an important consideration, since I'm paying for them).
  • It's easier to convert the project to an academic competition (like RoboCup) since the architecture is closer.
  • more... (help me to think about this)
Cons:
  • Expend lot of time in Computer Vision, concurrence management, communication protocols, routing and other unrelated complex software.
  • Not real a swarm, since if the "brain" computer dies all agents stop...
  • Have to simulate sensors response.
  • more... (help me to think about this)
Real local:

Pros:
  • True local processing.
  • Real swarm, robust in case o failure of agents.
  • Focus on behavioral algorithms instead of a simulation platform.
  • Real challenge for my MCU programming skills (and eLua's power =) ).
  • more... (help me to think about this).
Cons:
  • More complex Hardware (electronics mainly).
  • Expensive agents.
  • More sensible to project errors (mostly a consequence of the complexity).
  • Turning away from other academic activities involving the built robots (again, something like RoboCup).
  • more... (help me to think about this)

Army of Lawnbots

While I have no advances in my project (I decided to not post, explicitly, about my procrastination habits) here are some interesting news about DIY robots:

Just viewed the Hackaday post about the Lawnbot400, a robot lawnmower.
Very nice!
Imagine a bunch of those moving in a synchronized way on big, irregular, field...

Thursday, 25 March 2010

Warming up

This blog is an attempt to register the development of my MSc degree thesis on swarm robotics.
So expect little tutorials, news about robotics and some desperate calls for help when I get stuck!
Ah! Just in case, you can know more about me and my research at the links on the sidebar.

Not too much by now, but I expect this to be useful for someone! (It will be for me =])

Just to give a taste, one of my preferred swarm robotics projects. the Swarm-Bots :