robots-udevrules package for nbc and nxt_python, wedo and similar

[Martin Langhoff]

Hi Folks,

I am doing some work on nbc, nxt_python and other related projects. I
need to decouple the udev rules from the package that drives the USB
robot / board so we can have more than one package that drives it.

nbc and nxt_python are a good example of this situation, and the first
I'm working with.

So I've prepared a tiny robots-udevrules package for this purpose, and
I'll be requesting it be included in Fedora. I am also preparign
revisions to the nbc and nxt_python packages that depend on it.

spec, sources
http://dev.laptop.org/git/packages/robots-udevrules/tree/?h=f14/master

RPM, SRPM
http://dev.laptop.org/~martin/public_rpms/f14/?C=M;O=D

[ I don't get copied of list traffic, CCs welcome :-) ]

cheers,


m
-- 
 martin(a)laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Hedayat Vatankhah]

Hi Martin,
Have you created a review request for it? If it's ready, go with it.

Thanks and keep up the good work! :)
Hedayat

On ۱۱/۰۳/۰۹  09:25, Martin Langhoff wrote:
>  Hi Folks,
>
>  I am doing some work on nbc, nxt_python and other related projects. I
>  need to decouple the udev rules from the package that drives the USB
>  robot / board so we can have more than one package that drives it.
>
>  nbc and nxt_python are a good example of this situation, and the first
>  I'm working with.
>
>  So I've prepared a tiny robots-udevrules package for this purpose, and
>  I'll be requesting it be included in Fedora. I am also preparign
>  revisions to the nbc and nxt_python packages that depend on it.
>
>  spec, sources
>  http://dev.laptop.org/git/packages/robots-udevrules/tree/?h=f14/master
>
>  RPM, SRPM
>  http://dev.laptop.org/~martin/public_rpms/f14/?C=M;O=D
>
>  [ I don't get copied of list traffic, CCs welcome :-) ]
>
>  cheers,
>
>
>  m

[Tim Niemueller]

On 09.03.2011 18:55, Martin Langhoff wrote:
>  Hi Folks,
>  
>  I am doing some work on nbc, nxt_python and other related projects. I
>  need to decouple the udev rules from the package that drives the USB
>  robot / board so we can have more than one package that drives it.
>  
>  nbc and nxt_python are a good example of this situation, and the first
>  I'm working with.
>  
>  So I've prepared a tiny robots-udevrules package for this purpose, and
>  I'll be requesting it be included in Fedora. I am also preparign
>  revisions to the nbc and nxt_python packages that depend on it.
>  
>  spec, sources
>  http://dev.laptop.org/git/packages/robots-udevrules/tree/?h=f14/master 
As I suggested earlier, I'm strict against a catch-all robots-udevrules
package. Please create a nxt-udevrules package. The field of robots is
just too wide, in particular if you have full fledged service robots
you'll find that more often you have packages for a particular sensor
carrying the appropriate rules, and not one package for the complete robot.

	Tim


-- 
    Tim Niemueller <tim(a)niemueller.de&gt;      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)

[Martin Langhoff]

On Wed, Mar 9, 2011 at 1:04 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
>  As I suggested earlier, I'm strict against a catch-all
> robots-udevrules 
Happy to rename it to something narrower. Can you look at this list
http://wiki.laptop.org/go/11.2.0/Robotics_plan#Test_matrix and help me
figure out how we can refine the name? These robots and boards have a
few things in common:

 - they are usb (some bluetooth)
 - they have an education focus

edurobots-udevrules?




m
-- 
 martin(a)laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Tim Niemueller]

On 09.03.2011 19:08, Martin Langhoff wrote:
>  On Wed, Mar 9, 2011 at 1:04 PM, Tim Niemueller
> <tim(a)niemueller.de&gt; wrote:
> > As I suggested earlier, I'm strict against a catch-all robots-udevrules
>  
>  Happy to rename it to something narrower. Can you look at this list
>  http://wiki.laptop.org/go/11.2.0/Robotics_plan#Test_matrix and help me
>  figure out how we can refine the name? These robots and boards have a
>  few things in common:
>  
>   - they are usb (some bluetooth)
>   - they have an education focus
>  
>  edurobots-udevrules? 
That still is way to vague. I suggest creating a package per
robot/board/platform/sensor/actuator. If there is a canonical software
package for a particular robot, e.g. a library most commonly used to
access it, pack the rules in there (examples are libphidget or
libunicap). Arduinos are not even robot-specific, so it would be even
more terrible to stuff that into this package. There seems to be an
arduino package. Having a noarch arduino-udevrules sub-package seems to
be the most sensible, or at least a separate package of that name.
Please do not try to pocket all kinds of hardware into a single package
just because that's they way you use it in your context.

	Tim

-- 
    Tim Niemueller <tim(a)niemueller.de&gt;      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)

[Martin Langhoff]

On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
>  That still is way to vague. I suggest creating a package per
>  robot/board/platform/sensor/actuator. If there is a canonical software 
We are talking about 1 package for a 1-line file. That's very OCD :-)

One single package simplifies maintenance for this maintainer, reduces
metadata load on fedora infra, cuts your "yum downloading metadata"
times.

Look at rpms that bundle printer drivers. Or look at the rules as
shipped today, for example /etc/udev/rules.d/97-bluetooth-serial.rules

cheers,


m
-- 
 martin(a)laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Tim Niemueller]

On 09.03.2011 19:33, Martin Langhoff wrote:
>  On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller
> <tim(a)niemueller.de&gt; wrote:
> > That still is way to vague. I suggest creating a package per
> > robot/board/platform/sensor/actuator. If there is a canonical software
>  
>  We are talking about 1 package for a 1-line file. That's very OCD :-) 
>  One single package simplifies maintenance for this maintainer,
> reduces
>  metadata load on fedora infra, cuts your "yum downloading metadata"
>  times. 
I know, but one catch-all package is just not the proper way.

>  Look at rpms that bundle printer drivers. Or look at the rules as
>  shipped today, for example /etc/udev/rules.d/97-bluetooth-serial.rules 
These are all for one class of devices. But you are grouping different
classes of devices. At the very least, move rules for which a package
exists to that package, then group by device classes, e.g.
microcontroller boards an "edurobots". robots is certainly not a
suitable grouping, it's too vague. Even edurobots is very vague. The Nao
is also for educational purposes, as is the PR2, or the Pioneer, or even
the Roomba. But they are also service robots, soccer robots, outdoor
explorers, and for research.

I understand why you want to keep it in one package, but it seems
totally wrong to me. Consider bigger robots, where you have components,
rather than one integrated block. I have kind of dislike presenting NXT
toys as "these are robots". It's one kind of a robot, but there are so
many more and very different ones. Besides classification disagreement
that's another reason why I do not like the implication of such "one"
package for all.

Ideally, I'd like to have "microcontroller-udevrules" and
"legorobots-udevrules". I guess the latter is not possible due to
trademark constraints, but some other common term should be found
explicitly describing what this is about, maybe "brickrobots" ;-) If
after a few suggestions nothing better comes up, we can re-think
edurobots, but let's try to come up with something better, which does
not classify other robots inadequately or neglects them. Adding the
boards there remains a no-go for me.

	Tim

-- 
    Tim Niemueller <tim(a)niemueller.de&gt;      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)

[Martin Langhoff]

On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
>  On 09.03.2011 19:33, Martin Langhoff wrote:
> > On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
> >> That still is way to vague. I suggest creating a package per
> >> robot/board/platform/sensor/actuator. If there is a canonical software
> >
> > We are talking about 1 package for a 1-line file. That's very OCD :-)
>
> > One single package simplifies maintenance for this maintainer, reduces
> > metadata load on fedora infra, cuts your "yum downloading metadata"
> > times.
>
>  I know, but one catch-all package is just not the proper way. 
Well that's just an unfounded statement.

I have an NXT, a GoGo board, a Pico/Scratch board all on my desk right
now. I'll get my hands on a wedo and arduino kit soon.

They are _extremely_ similar, they are actually are all variations on
a theme; just like printers are. All have 3 to 5 inputs (usually read
as an unsigned int) and 3 to 5 "controller" ports. Some have a cpu you
get to program, plus a tiny bit of RAM. They all cost < USD 100  (or
around $250 in a kit with sensors and motors).

If the API (and CPU/RAM) allows, you can copy some bytecode files to
the device and execute them independently. Otherwise you read the
inputs and write commands to the controller ports.

They are _so_ similar, that we control them all from TurtleArt, or
from Scratch. Their sensors are mostly the same across different
boards.

Is there any problem if we end up with a package with udev rules for
50 similar-ish robots that can be controlled by more than one library?
Why are the bluetooth and printer rpm maintainers not hitting that
problem? File a bug against their packages too ;-)



m
-- 
 martin(a)laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Hedayat Vatankhah]

/*Martin Langhoff <martin(a)laptop.org&gt;*/ wrote on 03/10/2011 1:23:40 AM
+0350:
>  On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller
> <tim(a)niemueller.de&gt; wrote:
> > On 09.03.2011 19:33, Martin Langhoff wrote:
> >> On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
> >>> That still is way to vague. I suggest creating a package per
> >>> robot/board/platform/sensor/actuator. If there is a canonical software
> >> We are talking about 1 package for a 1-line file. That's very OCD :-)
> >> One single package simplifies maintenance for this maintainer, reduces
> >> metadata load on fedora infra, cuts your "yum downloading metadata"
> >> times.
> > I know, but one catch-all package is just not the proper way.
>  Well that's just an unfounded statement.
>
>  I have an NXT, a GoGo board, a Pico/Scratch board all on my desk right
>  now. I'll get my hands on a wedo and arduino kit soon.
>
>  They are _extremely_ similar, they are actually are all variations on
>  a theme; just like printers are. All have 3 to 5 inputs (usually read
>  as an unsigned int) and 3 to 5 "controller" ports. Some have a cpu you
>  get to program, plus a tiny bit of RAM. They all cost < USD 100  (or
>  around $250 in a kit with sensors and motors).
>
>  If the API (and CPU/RAM) allows, you can copy some bytecode files to
>  the device and execute them independently. Otherwise you read the
>  inputs and write commands to the controller ports.
>
>  They are _so_ similar, that we control them all from TurtleArt, or
>  from Scratch. Their sensors are mostly the same across different
>  boards.
>
>  Is there any problem if we end up with a package with udev rules for
>  50 similar-ish robots that can be controlled by more than one library?
>  Why are the bluetooth and printer rpm maintainers not hitting that
>  problem? File a bug against their packages too ;-) 
Well, Isn't there any
suitable common name for those 50 similar-ish
robots? There might be lots of robots similar to these, but there are
certainly lots of other robots which are totally different. So, it would
be nice if we can assign a category name to the robots you mention, and
provide a package for them.

Thanks,
Hedayat

>  m

[Tim Niemueller]

On 09.03.2011 22:53, Martin Langhoff wrote:
>  On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller
> <tim(a)niemueller.de&gt; wrote:
> > On 09.03.2011 19:33, Martin Langhoff wrote:
> >> On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
> >>> That still is way to vague. I suggest creating a package per
> >>> robot/board/platform/sensor/actuator. If there is a canonical software
> >>
> >> We are talking about 1 package for a 1-line file. That's very OCD :-)
> >
> >> One single package simplifies maintenance for this maintainer, reduces
> >> metadata load on fedora infra, cuts your "yum downloading metadata"
> >> times.
> >
> > I know, but one catch-all package is just not the proper way.
>  
>  Well that's just an unfounded statement.
>  
>  I have an NXT, a GoGo board, a Pico/Scratch board all on my desk right
>  now. I'll get my hands on a wedo and arduino kit soon. 
The pico board is a generic sensor board. People could use it for their
physics project to measure temperature or whatnot. It's not robotic per
se. Arduino is also on the wiki page, which is even less robot-specific.
I'd classify such boards not by their number of inputs or outputs, but
what they are used for. And many of these kits are open-ended. Some at
least have robotics as their primary purpose, but the only way to
properly group them is "microcontroller boards", but even then they are
so diverse that I'd argue they do not easily fit under one umbrella, and
certainly not robotics.

It also still neglects that you are looking at a tiny fraction of
robotics, namely toy robotics for young education. But serious research
robots or more powerful platforms are neglected by giving this udev
rules package such a vague name.

Come up with sensible classification and names, which is narrowly
focused on the purpose of the packages and does take into account that
it does not represent the whole field of robot hardware, and not even a
large fraction.

	Tim

-- 
    Tim Niemueller <tim(a)niemueller.de&gt;      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)

[Martin Langhoff]

On Wed, Mar 9, 2011 at 5:19 PM, Tim Niemueller <tim(a)niemueller.de&gt; wrote:
>  The pico board is a generic sensor board. People could use it for
> their
>  physics project to measure temperature or whatnot. It's not robotic 
right! Stick your neck out -- propose a name. educontrollerboards-udev?

Does it matter? It's actually
controller-boards-that-are-driven-by-multiple-libs . That's the "job
description" of this rpm. No user will ever install it. Packages will
depend on it to avoid a conflict.

>  Come up with sensible classification and names 
Unfortunately, I don't belong to the robotics field. You ask me to
solve an impossible riddle, in a foreign field, before we can talk
about a package for a 10 line file.

I am working to ensure that for some interesting boards there are
multiple libraries that can drive them; so they all coexist. Several
long-term Fedorans recommended this "udevrules" package approach.

It's sensible, it's practical, and it's merely a means to keep things
simple and straightforward. Again, users won't normally install or
care about this rpm, and it's a 10 line file. I'm already laughing the
idea of a package for a single 10 line file.

cheers,


m
-- 
 martin(a)laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff