Many users complain about having to pull in so many dependencies with
joystick_drivers (below is a list) but breaking it up is not as simple as
uniary stacks because both spacenav and wiimote pull in third party packages
that have not made their way up stream yet. However it is possible to start
breaking them up with the recent move of the joy msg to sensor_msgs. To me
it doesn't make sense to break the drivers apart until we can get wiimote
and spacenav directly using system dependencies but i"m all ears if someone
has ideas for making it possible.
Additionally I have work to do with respect to joystick_drivers mainly
around getting the rumble features of the wiimote and the ps3joy on the same
msg and working towards not requiring sudo to use the ps3joy which causes no
end of problems. Recently I spent some time trying to figure out how to get
ps3joy using the standard linux bluetooth hid interface and remove the need
for sudo but the linux driver is not there yet. I also tried to add rumble
and the like to the ps3joy but the sudo issue foiled me with respect to the
PR2 and had to roll back the changes for stability. My goal for fuerte is to
sort out these issues and absorb the patch from chad into the wiimote.
<rosdep name="libusb"/>
<rosdep name="joystick"/>
<rosdep name="bluez"/>
<rosdep name="python-bluez"/>
<rosdep name="libx11-dev" />
<rosdep name="autoconf"/>
<rosdep name="automake"/>
<rosdep name="python"/>
<rosdep name="libbluetooth-dev"/>
<rosdep name="bluez"/>
<rosdep name="flex"/>
<rosdep name="bison"/>
<rosdep name="pkg-config"/>
<rosdep name="gtk2"/>
<rosdep name="joystick"/>
-Melonee
On Tue, Sep 20, 2011 at 8:33 PM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
> On Tue, Sep 20, 2011 at 8:50 PM, Eric Perko <wisesage5001@gmail.com>
> wrote:
> > On Tue, Sep 20, 2011 at 9:10 PM, Jack O'Quin <jack.oquin@gmail.com>
> wrote:
> >> Are there other drivers we should repackage in this way? Let's try to
> >> compile a (fairly) complete list.
> >
> > Here's my list (I envision the current stack would continue on in some
> sort
> > of "meta-package" manner as discussed above):
> > Laser Drivers:
> >
> > Hokuyo_node goes to a unary stack
> > Sick_driver stack that contains the sicktoolbox and sicktoolbox_wrapper
> > packages.
>
> That makes sense to me. We need to contact the maintainers to see if
> they want to do it.
>
> > IMU Drivers:
> >
> > We've only got the Microstrain driver, but I think keeping around an
> > imu_drivers meta-package would be consistent with the laser and camera
> > drivers.
> >
> >
> > Is there any intention of splitting the joystick_drivers into unary
> stacks?
>
> They can if they want. Thoughts, Melonee?
>
> My feeling is that driver stacks which seldom change probably do not
> need to repackage. The reason camera_drivers should is because there
> are always a lot of bug fixes and new features in every release, and
> it becomes awkward to synchronize releases for all those drivers at
> once. Since users normally only depend on drivers for the specific
> devices they use, that synchronization is artificial and unnecessary.
> We should be able to release each camera driver when it is ready,
> without affecting the others.
> --
> joq
> _______________________________________________
> Ros-sig-drivers mailing list
> Ros-sig-drivers@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-sig-drivers
>
--
Senior Engineer
Intern Program Director
Willow Garage
68 Willow Rd.
Menlo Park, Ca 94025
Many users complain about having to pull in so many dependencies with joystick_drivers (below is a list) but breaking it up is not as simple as uniary stacks because both spacenav and wiimote pull in third party packages that have not made their way up stream yet. However it is possible to start breaking them up with the recent move of the joy msg to sensor_msgs. To me it doesn't make sense to break the drivers apart until we can get wiimote and spacenav directly using system dependencies but i"m all ears if someone has ideas for making it possible.
Additionally I have work to do with respect to joystick_drivers mainly around getting the rumble features of the wiimote and the ps3joy on the same msg and working towards not requiring sudo to use the ps3joy which causes no end of problems. Recently I spent some time trying to figure out how to get ps3joy using the standard linux bluetooth hid interface and remove the need for sudo but the linux driver is not there yet. I also tried to add rumble and the like to the ps3joy but the sudo issue foiled me with respect to the PR2 and had to roll back the changes for stability. My goal for fuerte is to sort out these issues and absorb the patch from chad into the wiimote.
<rosdep name="libusb"/>
<rosdep name="joystick"/>
<rosdep name="bluez"/>
<rosdep name="python-bluez"/>
<rosdep name="libx11-dev" />
<rosdep name="autoconf"/>
<rosdep name="automake"/>
<rosdep name="python"/>
<rosdep name="libbluetooth-dev"/>
<rosdep name="bluez"/>
<rosdep name="flex"/>
<rosdep name="bison"/><rosdep name="pkg-config"/>
<rosdep name="gtk2"/>
<rosdep name="joystick"/>
-MeloneeOn Tue, Sep 20, 2011 at 8:33 PM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
On Tue, Sep 20, 2011 at 8:50 PM, Eric Perko <
wisesage5001@gmail.com> wrote:
> On Tue, Sep 20, 2011 at 9:10 PM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
>> Are there other drivers we should repackage in this way? Let's try to
>> compile a (fairly) complete list.
>
> Here's my list (I envision the current stack would continue on in some sort
> of "meta-package" manner as discussed above):
> Laser Drivers:
>
> Hokuyo_node goes to a unary stack
> Sick_driver stack that contains the sicktoolbox and sicktoolbox_wrapper
> packages.
That makes sense to me. We need to contact the maintainers to see if
they want to do it.
> IMU Drivers:
>
> We've only got the Microstrain driver, but I think keeping around an
> imu_drivers meta-package would be consistent with the laser and camera
> drivers.
>
>
> Is there any intention of splitting the joystick_drivers into unary stacks?
They can if they want. Thoughts, Melonee?
My feeling is that driver stacks which seldom change probably do not
need to repackage. The reason camera_drivers should is because there
are always a lot of bug fixes and new features in every release, and
it becomes awkward to synchronize releases for all those drivers at
once. Since users normally only depend on drivers for the specific
devices they use, that synchronization is artificial and unnecessary.
We should be able to release each camera driver when it is ready,
without affecting the others.
--
joq
_______________________________________________
Ros-sig-drivers mailing list
Ros-sig-drivers@code.ros.org
https://code.ros.org/mailman/listinfo/ros-sig-drivers
-- Senior EngineerIntern Program DirectorWillow Garage68 Willow Rd.Menlo Park, Ca 94025
(text/plain)