[ANN] Player-Ada 2.0.3.0 released

[ANN] Player-Ada 2.0.3.0 released

[Alex R. Mosteo]

Player-Ada
==========
A binding for the Player/Stage robotic platform.

Player-Ada is a not-so-thin binding to the libplayerc client library that is
distributed as part of the Player/Stage multi-robot interface/simulator
software.

It currently implements the following interfaces: blobfinder, gps, laser,
localize, planner, position2d, simulation.

Binding homepage: http://ada-player.sf.net/
Player homepage:  http://playerstage.sf.net/

Re: [ANN] Player-Ada 2.0.3.0 released

[Dmitry A. Kazakov]

On Thu, 26 Oct 2006 19:51:01 +0200, Alex R. Mosteo wrote:

> Player-Ada
> ==========
> A binding for the Player/Stage robotic platform.
> 
> Player-Ada is a not-so-thin binding to the libplayerc client library that is
> distributed as part of the Player/Stage multi-robot interface/simulator
> software.
> 
> It currently implements the following interfaces: blobfinder, gps, laser,
> localize, planner, position2d, simulation.
> 
> Binding homepage: http://ada-player.sf.net/
> Player homepage:  http://playerstage.sf.net/

Hardware?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ANN] Player-Ada 2.0.3.0 released

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

> On Thu, 26 Oct 2006 19:51:01 +0200, Alex R. Mosteo wrote:
> 
>> Player-Ada
>> ==========
>> A binding for the Player/Stage robotic platform.
>> 
>> Player-Ada is a not-so-thin binding to the libplayerc client library that
>> is distributed as part of the Player/Stage multi-robot
>> interface/simulator software.
>> 
>> It currently implements the following interfaces: blobfinder, gps, laser,
>> localize, planner, position2d, simulation.
>> 
>> Binding homepage: http://ada-player.sf.net/
>> Player homepage:  http://playerstage.sf.net/
> 
> Hardware?

The binding has only been tested in Linux with gnat, but it's supposed to be
pure Ada95 without using gnat extensions. Quoting Player FAQ:

"
Player runs on pretty much any POSIX platform, including embedded systems
(Player has been cross-compiled to run on several ARM- and PPC-based Linux
systems). Specifically, Player's requirements are:

    * POSIX development environment, with threads (pthreads)
    * TCP stack
    * A compiler with both C and C++ (we have only tested gcc, but other
compilers may work)
    * A bash shell, to run the configure script; this implies that Player
will not build natively in Windows, though some users have it running under
Cygwin, and there are rumors of MinGW builds as well.
"

If you refer to what robots can be controlled with player:

http://playerstage.sourceforge.net/doc/Player-cvs/player/supported_hardware.html

I have used it with Pioneer3 DX/AT robots equiped with sonar and SICK200
lasers.

Alex.

Re: [ANN] Player-Ada 2.0.3.0 released

[Dmitry A. Kazakov]

On Fri, 27 Oct 2006 10:42:27 +0200, Alex R. Mosteo wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Thu, 26 Oct 2006 19:51:01 +0200, Alex R. Mosteo wrote:
>> 
>>> Player-Ada
>>> ==========
>>> A binding for the Player/Stage robotic platform.
>>> 
>>> Player-Ada is a not-so-thin binding to the libplayerc client library that
>>> is distributed as part of the Player/Stage multi-robot
>>> interface/simulator software.
>>> 
>>> It currently implements the following interfaces: blobfinder, gps, laser,
>>> localize, planner, position2d, simulation.
>>> 
>>> Binding homepage: http://ada-player.sf.net/
>>> Player homepage:  http://playerstage.sf.net/
>> 
>> Hardware?
> 
> The binding has only been tested in Linux with gnat, but it's supposed to be
> pure Ada95 without using gnat extensions. Quoting Player FAQ:
> 
> "
> Player runs on pretty much any POSIX platform, including embedded systems
> (Player has been cross-compiled to run on several ARM- and PPC-based Linux
> systems). Specifically, Player's requirements are:
> 
>     * POSIX development environment, with threads (pthreads)
>     * TCP stack
>     * A compiler with both C and C++ (we have only tested gcc, but other
> compilers may work)
>     * A bash shell, to run the configure script; this implies that Player
> will not build natively in Windows, though some users have it running under
> Cygwin, and there are rumors of MinGW builds as well.
> "
> 
> If you refer to what robots can be controlled with player:
> 
> http://playerstage.sourceforge.net/doc/Player-cvs/player/supported_hardware.html
> 
> I have used it with Pioneer3 DX/AT robots equiped with sonar and SICK200
> lasers.

Thanks for the information.

If I correctly understood it is not embedded, the thingy is controlled by a
PC.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ANN] Player-Ada 2.0.3.0 released

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

(snip)

> If I correctly understood it is not embedded, the thingy is controlled by
> a PC.

Well, no and yes. In our case, the Pioneer robots have an embedded board
with PC/104 socket that allows to have a x86 platform running linux. Player
connects to the hardware via RS232. But I suppose you refer to more exotic
platforms?

You can check more details here: http://mobilerobots.com/

Re: [ANN] Player-Ada 2.0.3.0 released

[Dmitry A. Kazakov]

On Fri, 27 Oct 2006 12:03:10 +0200, Alex R. Mosteo wrote:

> Dmitry A. Kazakov wrote:
> 
> (snip)
> 
>> If I correctly understood it is not embedded, the thingy is controlled by
>> a PC.
> 
> Well, no and yes. In our case, the Pioneer robots have an embedded board
> with PC/104 socket that allows to have a x86 platform running linux.

Is it role of being a sort of extension board, arithmetic booster, DSP
board etc as in PCs of early 90s?

> Player
> connects to the hardware via RS232. But I suppose you refer to more exotic
> platforms?

Nothing specific. I am just wondering if there is an architecture that
could natively support Ada, down to actuators, sensors and real-time
control loops.

[In industry actuators and sensors are connected via Ethernet (maybe
modified) or a field bus. The latter slowly dies out. RS232 is, well, quite
outdated.]

> You can check more details here: http://mobilerobots.com/

Thanks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ANN] Player-Ada 2.0.3.0 released

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

> On Fri, 27 Oct 2006 12:03:10 +0200, Alex R. Mosteo wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>> (snip)
>> 
>>> If I correctly understood it is not embedded, the thingy is controlled
>>> by a PC.
>> 
>> Well, no and yes. In our case, the Pioneer robots have an embedded board
>> with PC/104 socket that allows to have a x86 platform running linux.
> 
> Is it role of being a sort of extension board, arithmetic booster, DSP
> board etc as in PCs of early 90s?

I think it's a standard socket for industrial PCs that allows stacking of
cards. A card can mount the CPU, another one the wireless, another some USB
ports and so on...

http://en.wikipedia.org/wiki/PC/104

>> Player
>> connects to the hardware via RS232. But I suppose you refer to more
>> exotic platforms?
> 
> Nothing specific. I am just wondering if there is an architecture that
> could natively support Ada, down to actuators, sensors and real-time
> control loops.

Do you know MARTE OS? It could be useful for such an architecture and is
mostly Ada.
http://marte.unican.es/

Our robots have a proprietary OS (ARCOS) in the other side of the RS232 for
real-time control of the robot. I don't know much about it.

> [In industry actuators and sensors are connected via Ethernet (maybe
> modified) or a field bus. The latter slowly dies out. RS232 is, well,
> quite outdated.]

I don't have much experience with robots out of these ones, but USB is still
second place to RS232: even if newer SICK models have USB, our models, GPS
receivers, the robot microcontroller, the pan-tilt camera units, our
lasers, all use RS232... may be they tricked us into buying obsolescent
hardware ;)

Re: [ANN] Player-Ada 2.0.3.0 released

[Dmitry A. Kazakov]

On Fri, 27 Oct 2006 15:29:54 +0200, Alex R. Mosteo wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Fri, 27 Oct 2006 12:03:10 +0200, Alex R. Mosteo wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>> (snip)
>>> 
>>>> If I correctly understood it is not embedded, the thingy is controlled
>>>> by a PC.
>>> 
>>> Well, no and yes. In our case, the Pioneer robots have an embedded board
>>> with PC/104 socket that allows to have a x86 platform running linux.
>> 
>> Is it role of being a sort of extension board, arithmetic booster, DSP
>> board etc as in PCs of early 90s?
> 
> I think it's a standard socket for industrial PCs that allows stacking of
> cards. A card can mount the CPU, another one the wireless, another some USB
> ports and so on...
> 
> http://en.wikipedia.org/wiki/PC/104

Yes it is, but I actually meant the system architecture:

Sensors / Actuators
  ^
  |  DAC/ADC, I/Os etc
  y
Controller [closed, runs nobody knows what]
  ^
  |  RS232
  V
Extension board [open, runs Linux with an [Ada] application on]

Architectures like this were widely used in industrial automation 10 years
ago. History tends to repeat itself... (:-))

>>> Player
>>> connects to the hardware via RS232. But I suppose you refer to more
>>> exotic platforms?
>> 
>> Nothing specific. I am just wondering if there is an architecture that
>> could natively support Ada, down to actuators, sensors and real-time
>> control loops.
> 
> Do you know MARTE OS? It could be useful for such an architecture and is
> mostly Ada.
> http://marte.unican.es/

Interesting, thank you for the link.

> Our robots have a proprietary OS (ARCOS) in the other side of the RS232 for
> real-time control of the robot. I don't know much about it.
> 
>> [In industry actuators and sensors are connected via Ethernet (maybe
>> modified) or a field bus. The latter slowly dies out. RS232 is, well,
>> quite outdated.]
> 
> I don't have much experience with robots out of these ones, but USB is still
> second place to RS232: even if newer SICK models have USB, our models, GPS
> receivers, the robot microcontroller, the pan-tilt camera units, our
> lasers, all use RS232... may be they tricked us into buying obsolescent
> hardware ;)

Presently, it is no problem to bring a small embeddable 100MBaud Ethernet
switch on the board and connect sensors/actuators directly to the robot's
"LAN." The problem is that Ethernet/fieldbus-capable sensors/actuators are
quite expensive. Ada were an excellent candidate for implementation of a
middleware for "software wiring" of process variables in such a system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ANN] Player-Ada 2.0.3.0 released

[Jeffrey R. Carter]

Alex R. Mosteo wrote:
> 
> Well, no and yes. In our case, the Pioneer robots have an embedded board
> with PC/104 socket that allows to have a x86 platform running linux. Player
> connects to the hardware via RS232. But I suppose you refer to more exotic
> platforms?

I don't know if it's the question Kazakov was asking, but what I'd like 
to know is: Does the robot have to be connected to the PC (RS232) in 
order to function?

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Player-Ada 2.0.3.0 released

[mosteo]

Jeffrey R. Carter ha escrito:

> Alex R. Mosteo wrote:
> >
> > Well, no and yes. In our case, the Pioneer robots have an embedded board
> > with PC/104 socket that allows to have a x86 platform running linux. Player
> > connects to the hardware via RS232. But I suppose you refer to more exotic
> > platforms?
>
> I don't know if it's the question Kazakov was asking, but what I'd like
> to know is: Does the robot have to be connected to the PC (RS232) in
> order to function?

If your question is if you can flash some program inside the robot
microcontroller and completely forget about the serial and external
things, I think the answer is no, or not easily. The robot's
microcontroller is documented and its OS is upgradeable. I don't think
the documentation says enough to replace the  OS with something else,
but certainly this is not the use the manufacturer has in mind. The
intended use for the robot is via serial. You'd also have other
problems: the microcontroller has access to wheels and sonars, but not
to laser that is a completely isolated entity. Maybe you could use the
now unused serial to link these two.

ITOH, nothing mandates that the client (user) side of the serial is a
PC. The protocol is documented so you could use whatever you want. In
fact the robot can be purchased with or without embedded PC. Without
it, you need either a radio serial, a laptop to put on the robot, or
something else. The advantage of a PC is that you have out-of-the box
the proprietary software provided, and Player as an open source option.

If you're concerned with a full real-time solution, this is doable: the
microcontroller OS is RT and the periods of wheel encoders and sonars
feedback are documented. So nothing precludes using some RT-Linux or
other RTOS in the client side.

(Actually, these Pioneer robots are popular within the robotic
community. You can probably find other PC software interfaces as well.
CARMEN comes to mind).

http://carmen.sourceforge.net/hardware.html

Re: [ANN] Player-Ada 2.0.3.0 released

[Alex R. Mosteo]

Dmitry A. Kazakov wrote:

> Yes it is, but I actually meant the system architecture:
> 
> Sensors / Actuators
>   ^
>   |  DAC/ADC, I/Os etc
>   y
> Controller [closed, runs nobody knows what]
>   ^
>   |  RS232
>   V
> Extension board [open, runs Linux with an [Ada] application on]

That's it, and you explain it mroe clearly than me.

> Architectures like this were widely used in industrial automation 10 years
> ago. History tends to repeat itself... (:-))

At least the move to USB will simplify/cheapify new systems?

> Presently, it is no problem to bring a small embeddable 100MBaud Ethernet
> switch on the board and connect sensors/actuators directly to the robot's
> "LAN." The problem is that Ethernet/fieldbus-capable sensors/actuators are
> quite expensive. Ada were an excellent candidate for implementation of a
> middleware for "software wiring" of process variables in such a system.

Regards,

Alex.

Re: [ANN] Player-Ada 2.0.3.0 released

[Dmitry A. Kazakov]

On Mon, 30 Oct 2006 09:12:24 +0100, Alex R. Mosteo wrote:

> Dmitry A. Kazakov wrote:
> 
>> Architectures like this were widely used in industrial automation 10 years
>> ago. History tends to repeat itself... (:-))
> 
> At least the move to USB will simplify/cheapify new systems?

Maybe, though I am not sure. USB is P2P. It could become a burden for an
application, no matter if there were a port per sensor or else all of them
were multiplexed on one port. In the latter case you quickly end up with
something like a TCP/IP stack. So why not just to take Ethernet?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de