USB permissions for educational robots

Paul Fox pgf at laptop.org
Tue Jan 3 10:56:12 EST 2012


andres wrote:
 > Here in uruguay xo`s are distributed with no permission to install rpm or
 > modify udev rules, so is very important to have this rules added to work
 > with butiá 2.0 and nxt in a near future.

we can add it, but clearly it would be best if deployments or even
local classrooms could add new device capabilities on their own.
because as soon as we say "great, we're done", someone will create
a new USB device that kids and teachers everywhere will want to use.

i would greatly appreciate someone coming up with a scheme to allow
the end-user, or a deployment, to add devices on their own.

perhaps the user should be given r/w permission for any USB device.
(yes, i understand there are big risks with that.  feel free to
propose exceptions that would make this safe.)

paul

 > Regards
 > Andrés
 > Enviado desde mi teléfono móvil, disculpe los errores de tipeo.
 > El 03/01/2012 12:12, "Paul Fox" <pgf at laptop.org> escribió:
 > 
 > > roughly speaking, we chose the "dialout" group because a) it's a
 > > traditional group for access to UNIX serial devices, b) many USB
 > > devices that activities need access to are actually serial devices,
 > > and c) the "olpc" user is already a member of "dialout".  is it
 > > important that Lego devices be protected by a separate group
 > > membership?
 > >
 > > the current udev rule isn't added by Sugar -- it's in the olpc-utils
 > > rpm distributed by OLPC.  we can add a modified rule once we agree
 > > on what it should look like.
 > >
 > > i can't remember at the moment where the default passwd and group
 > > files come from -- if the rule needs a new group, we'll need to modify
 > > those files as well.
 > >
 > > paul
 > >
 > > alan jhonn aguiar schwyn wrote:
 > >  >
 > >  > Hi,
 > >  > In a few of months, all our High Schools (of Uruguay) will receive and
 > > robotic
 > >  > kit (Lego).
 > >  > At "Universidad de la República", "Facultad de Ingeniería" we are
 > > workingwith
 > >  > it and the XO...
 > >  > http://www.youtube.com/watch?v=S8HRbDLO7LM
 > >  >
 > >  > In other parallel road, we are working on a 2.0 version of the Butia
 > > Robot
 > >  > www.fing.edu.uy/inco/proyectos/butia
 > >  >
 > >  > That uses USB4all IO board  which resulted from a thesis given at
 > > ourUniversity
 > >  > (also will have arduino compatibility)
 > >  > http://www.fing.edu.uy/inco/grupos/mina/pGrado/pgusb/
 > >  >
 > >  > USB4all is based on 18f4550 pic.The vendor is Microchip,
 > >  > SYSFS{idVendor}=="04d8"And have: productID=0x000b //bootloader
 > >  > productID=0x000c //pic18f4550 generic comunication
 > >  >
 > >  > The actual Sugar image, only have permissions for LEGO WeDo.
 > >  > If you see in: /etc/udev/rules.d you find the correspondient:
 > >  > "30-olpc-wedo.rules".
 > >  > The file add this rule:
 > >  > SYSFS{idVendor}=="0694", SYSFS{idProduct}=="0003", GROUP="dialout",
 > > MODE="0660"
 > >  > This means: 0694 is LEGO                   0003 the model: WeDo
 > >  > To the NXT we need add: {idProduct}=="0002"
 > >  > But, for each model add a new line.. not is a good form..
 > >  > Exist another way, a generic rule:
 > >  > BUS=="usb", SYSFS{idVendor}=="0694", GROUP="lego", MODE="0660"
 > >  > That says: if is USB and fabricated by 0694 (LEGO) lets 0660 (4: read+
 > > 2: write)
 > >  > If add this permissions to "lego" group, we need create it..
 > >  > But, we don't make it, an use an existing group like "root"? Or
 > > another...
 > >  > Suggestions?
 > >  > We can make a generic group "robot" that have permissions for: lego
 > > wedo, lego
 > >  > nxt, butia, etc...
 > >  > Regards!
 > >  > Alan                                           part 2     text/plain
 > >               129
 > >  > _______________________________________________
 > >  > Devel mailing list
 > >  > Devel at lists.laptop.org
 > >  > http://lists.laptop.org/listinfo/devel
 > >
 > > =---------------------
 > >  paul fox, pgf at laptop.org
 > >

=---------------------
 paul fox, pgf at laptop.org



More information about the Devel mailing list