Experiences from Microb...

I include a message from Regis Houde of the Microb project, in which
he gives an overview of their experiences in building a flexible robot
control package.
 (Microb <http://www.robotique.ca/microb/> is code developed by the
  Institut de Recherche Électrique du Québec)

Herman

---------- Forwarded message ----------
Date: Thu, 23 Aug 2001 12:19:45 -0400
From: "Houde, Regis" <[email protected]>
To: 'Herman Bruyninckx' <[email protected]>
Subject: RE: The Orocos Project

Here are some of my thoughts :

- From the beginning Microb dit not address the user interface
	side of the robotics applications which reveal later to
	be a good decision. I saw that you have the same approach
	with Orocos.

- Supporting 7 OS was a lot of effort but it worth it. The code
	is more robust, we can do demos on Windows station, simulate
	on Solaris and use a realtime as QNX to control the real
	robot. On the counterpart it is more difficult to take
	advantage of special features an OS could have. This is not
	such a bad thing because using a feature that just an OS
	has can lead you to a trap when you want to change OS or
	the OS is no longer supported.

- We`re using a server/client approach which shown to be very useful
	in the development stages and give a lot of versatility to
	the applications (ex : the user interfaces work tranparently
	with the real server or the simulation server, using the same
	client in different applications for plotting data)

- We never tried to develop standard drivers for sensors or actuators.
	This would have taken an huge effort that we could not afford.
	You cannot buy all possible actuators, IO card, sensors available
	so if you want to have standard drivers you have to be big enough
	so the manufacturers will provide the drivers. There is almost no
	chances that this will happen with a robot control library. Just
look
	at the number of companies that offers rtos drivers for their
	products.

- The development of Microb was often dictated by the needs of the moment
instead
	of a global vision from the start as you want to do. This results in
	a lot of reengineering from time to time. It was a lot of work and
	it was possible for us to do it because we did`nt have a lot of
	external "clients" at that time. The approach of designing before
	coding might avoid unecessary work. On the other hand, real problems
	and real needs often only show with real applications.
	I might add that we had a vision at the beginning of the project
	because we were using a controller that was develop on 1 vxWorks
	plateform and for 1 application. This controller was difficult to
	support and to port to new CPU cards.

Enough of thoughts, I have to go back at work... :)

Bye

Regis