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
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
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
On Wed, Mar 9, 2011 at 1:04 PM, Tim Niemueller tim@niemueller.de 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
On 09.03.2011 19:08, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:04 PM, Tim Niemueller tim@niemueller.de 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
On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller tim@niemueller.de 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
On 09.03.2011 19:33, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller tim@niemueller.de 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
On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller tim@niemueller.de wrote:
On 09.03.2011 19:33, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller tim@niemueller.de 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 Langhoff martin@laptop.org*/ wrote on 03/10/2011 1:23:40 AM +0350:
On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller tim@niemueller.de wrote:
On 09.03.2011 19:33, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller tim@niemueller.de 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
On 09.03.2011 22:53, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller tim@niemueller.de wrote:
On 09.03.2011 19:33, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller tim@niemueller.de 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
On Wed, Mar 9, 2011 at 5:19 PM, Tim Niemueller tim@niemueller.de 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
robotics@lists.fedoraproject.org