The original segwayrmp driver isn't compatible with the Segway USB
controller board. The RMP's USB interface board is providing a USB to
serial (not USB to CAN) converter, which is why you see ttyUSB0 (a USB
serial port). The driver is looking for a CAN device, and failing
because you don't have one connected. The original RMP's didn't have a
USB port, just a CAN connection. You had to get some sort of USB to CAN
converter like one from Kvaser in order to communicate with the RMPs.
That's what the original segwayrmp driver was designed to do. To use
the USB interface board, you have to open a serial connection at
/dev/ttyUSBx, and send CAN packets over the serial connection. It is a
Luckily, Player 3.0 contains an updated RMP driver with a USB interface
option. We built it to work with the RMP200 and 400, but my
understanding is that all of the RMPs have the same USB interface board.
The RMP Interface guide says that the RMP50 & 100 use some different
velocity, torque, and position scaling factors than the RMP200 & 400,
but that'll only affect the readings you get out of the driver. You can
modify the scaling factors at the top of rmp_frame.h. It wouldn't be
too hard to backport the 3.0 "segwayrmp" driver to Player 2.1 and use it
as a plugin. I used it extensively with the RMP400 in player 2.1, with
the stock FTDI driver in Fedora 11 (I created a udev rule to modprobe
ftdi_sio with the correct product and vendor IDs). Then ported it to
3.0 and tested it briefly before contributing the patch.
It looks like the documentation page is way out of date, so I'm adding a
sample configuration file if you succeed in backporting the driver or
upgrading to Player 3.0. And looking over segwayrmp.cc, it seems like
it's possible to remove all association with canio_kvaser so you don't
need their canlib headers and libraries.
provides ["position2d:0" "position3d:0" "power:0"]
On 12/17/2009 05:15 PM, Drew_S wrote:
> Any luck resolving this error? (I'm getting the same error)
> Based on the Knowledgebase at ftdichip.com, I updated my version of
> canio_rmpusb.cc to list all the connected devices. Turns out that I have no
> I suspect that this is the root of the "error (-1)" problem that I'm having,
> but I'm not sure how to fix it. My Segway is turned on and connected. The
> results of "dmesg | grep FTDI" look promising. After that, I'm not sure
> what else to do to debug the problem...
> My code is exactly the same as the documentation found on this site:
> ListDevices Function Documentation
> The results of the dmesg test:
> $ dmesg | grep FTDI
> [ 123.146256] USB Serial support registered for FTDI USB Serial Device
> [ 123.146325] ftdi_sio 1-6.3:1.0: FTDI USB Serial Device converter detected
> [ 123.146540] usb 1-6.3: FTDI USB Serial Device converter now attached to
> [ 123.146559] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver
> Todd Flyr wrote:
>> I have an RMP 100 that I've been following the instructions for (using
>> ubuntu) and encountered the same issue you mentioned. I made the changes
>> that you suggested but I'm still not getting the connection completely set
>> up. When attempting to run the joystick.cfg, I'm getting "error (-1)
>> reading packet on channel 0" and "error on write" messages after
>> attempting to send the 0 speed information. I am not certain if this is a
>> canbus error or from player itself, but it is clearly not working. All
>> other aspects of the instructions seemed to work. I have the devices
>> connected via USB successfully. I'm wondering if there's something
>> obvious I've done wrong or if this is something you've encountered or if
>> this might be something specific to using the RMP 100. I am trying to use
>> it in balance mode, which might be making a difference.
>> Any insight would help. Thanks in advance.
>> Joshua S wrote:
>>> I have gotten things working, which required a slightly different setup.
>>> Because I didn't have any Makefile references to -lcanbus I had to
>>> initially modify<player-dir>/server/Makefile line to:
>>> LIBS = -lpthread -lrt -lnsl -lcrypto -lraw1394 -lz -lltdl -ldl -ljpeg
>>> -lGL -lGLU -lftd2xx
>>> I had problems at runtime because check_device exists in both
>>> player(setpwc_api) and in ftd2xx. I modified the function check_device()
>>> as it is defined in setpwc_api.[c/h] to setpwc_check_device() to keep
>>> ftd2xx from calling the wrong check_device. Next time I compile I will
>>> try to target the ftd2xx linking with more precision to avoid this
>>> Thanks to everyone who worked on getting this together.