2006/12/29
Document Actions
Jal and the SirBot Project
SBP jalled
by
Sébastien Lelong
—
posted at
2006-12-29 11:44
last modified
2007-01-16 10:48
There are two distincts sides within the SirBot Project (SBP):
* the PIC side is ASM code, written once,
* the PC side, which communicates with the PIC side, is more dynamic, as the user can define a kind of language specific to its bot: protocol unit, which are the « smallest/primitive action » the bot can understand, orders, which are an aggregation of protocol unit, and tasks, which are orders and/or protocol unit with conditional events/loops.
The SBP purposes is to provides everything needed for the PIC side (software + hardware) and an easy way to define user's specific language from the PC side. One important thing is then to have an interface between those two sides (where the red line stands), that is the frontier between dynamic and the static side.
* the PIC side is ASM code, written once,
* the PC side, which communicates with the PIC side, is more dynamic, as the user can define a kind of language specific to its bot: protocol unit, which are the « smallest/primitive action » the bot can understand, orders, which are an aggregation of protocol unit, and tasks, which are orders and/or protocol unit with conditional events/loops.
The SBP purposes is to provides everything needed for the PIC side (software + hardware) and an easy way to define user's specific language from the PC side. One important thing is then to have an interface between those two sides (where the red line stands), that is the frontier between dynamic and the static side.
Currenly, this frontier definition is done writing an protocol file, which describes the protocol units, meaning the primitive actions the bot can understand. Based on this definition, the communication is quite simple: earch primitive action is associated to a procedure whithin the bot (eg. when sending the char « R » to the bot, this one proceed to a IR range and send back the results). This is a « one-letter <=> one function » association, which can have arguments ( the whole over a serial communication). Sending an order is just sending several primitive actions, thus sending chars. This is what can be observed while looking at the way SBP interacts with the TamaBot Daycare, for instance. Thanks to these abstractions, feeding the tamagotchi is as simple as typing "send FEED" in the SBP console.
What about Jal in all of this ? Jal makes the PIC developpement side easier and faster. The SPB idea is to make things « high-level », from both the PIC and the PC sides and Jal brings the whole a level higher. But the most important thing is when I'm writing Jal code, it's quite similar to when I'm writing commands whithin the SBP console:
| Jal | SBP Console |
move(SERVO_A,103) |
send SERVO A 103 |
Using the SBP console is quite simple. It's initialized from the protocol file, and then connects to the bot. The problem is the duplication of the primitive actions definition (protocol file + command definition in the bot). Actually, what I'd like to be able to do is to migrate part of this console directly inside the PIC. Sort of embedded interpreter, which would expose several "public" methods to the client (the console), thus avoiding these duplication. One could directly connect to the bot, query it to know what it can do, dynamically sending interpreted commands. That's it, migrate some of the dynamic stuff, from the PC, to the PIC. This is not what I primarly planned: "Move all the complex stuff into the PC side, because coding in ASM is painful". But when using Jal, things just get easy :)
This seems to be a classical robot control interface. Several projects dealing with this problem already exist: Urbi, PlayerStage, Orocos, naming a few. But the supported hardwate is far (far) from a Microchip PIC and hobby robots (Aibo, Korebot, Pioneer bots, ...), and cannot be used here (AFAIK).
So what to do ? Is having a small embedded interpreter reasonably possible ? Does this already exist ? I'd really like SBP to be able to do that...
So what to do ? Is having a small embedded interpreter reasonably possible ? Does this already exist ? I'd really like SBP to be able to do that...
- Category(s)
- SirBot Project
