From: Alexei M. <al...@ca...> - 2009-04-02 01:17:23
|
That doesn't sound good. One thing to check is which kernel v.4.16 is supposed to be compatible with. If it's something older than your 2.6.27 than you may need to downgrade the kernel. Otherwise, you could send a bug report to the FTDI guys, I've dealt with them before and they'd been responsive. Sorry for the limited options and let us know how it goes, Alex Ellen Klingbeil wrote: > Hi Alex, > > Initially, we tried the newest version of libftd2xx (4.16) and had the > segfault problem so we installed the older one. > > Thanks, > Ellen > > > > On Tue, Mar 31, 2009 at 5:55 PM, Alexei Makarenko <al...@ca... > <mailto:al...@ca...>> wrote: > > Ellen, > > the segfault seems to be outside of our code: probably somewhere > deep in the Linux USB library. > > I suspect that the problem is caused by the use of a new kernel and > an old version of libftd2xx. > > In our own work we use the CAN version of the driver so the USB > version has not been tested since the following combination: kernel > 2.6.20 + libftd2xx 0.4.13. > > I suggest that you install the latest version of libftd2xx (0.4.16), > recompile our driver and see what happens. Most likely this will > solve the problem you are having and if something needs to be fixed > in our driver we can help you with that. > > alex > > > > Ellen Klingbeil wrote: > > Hi Alex, > > Thanks so much for the quick response! > > We are using Ubuntu (kernel version 2.6.27), the most recent > version of Orca available on sourceforge, and the version of the > ftd2xx library that the website says the driver code was tested > on (version 4.13). > I wrote a simple executable (attached) that just uses the > functions in segwayrmpafcr/driver.cpp. > > This is the output I get per your instructions: > > in readData() Driver::readData(): timed out 5 times while > waiting for CAN data. > in read()Driver::read(): Driver::readData(): timed out 5 times > while waiting for CAN data. > TRACE(test.cpp): Caught exception trying to read from rear: > Driver::read(): Driver::readData(): timed out 5 times while > waiting for CAN data. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb7089b90 (LWP 30395)] > 0xb78c18f5 in ProcessBulkInData (fd=0x8439fa8, Buffer=0x848d000 > <Address 0x848d000 out of bounds>, BufSiz=-199123) > at bulk_in.c:309 > 309 bulk_in.c: No such file or directory. > in bulk_in.c > Current language: auto; currently c > (gdb) where > #0 0xb78c18f5 in ProcessBulkInData (fd=0x8439fa8, > Buffer=0x848d000 <Address 0x848d000 out of bounds>, BufSiz=-199123) > at bulk_in.c:309 > #1 0xb78c2118 in reader_thread (in_data=0x8439fa8) at bulk_in.c:709 > #2 0xb791c50f in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #3 0xb7ae57ee in clone () from /lib/tls/i686/cmov/libc.so.6 > > > Thanks! > > Ellen > > > On Tue, Mar 31, 2009 at 4:27 PM, Alexei Makarenko > <al...@ca... <mailto:al...@ca...> > <mailto:al...@ca... <mailto:al...@ca...>>> wrote: > > Hi Ellen, > we'll need more info to debug this. > > what's you setup: OS, version of Orca, components in your system? > > we'd need to know where the segfault happens. Assuming that > you are > just running the segwayrmp component, here's how you do it: > > $ gdb segwayrmp > $ set args --Orca.Config=segwayrmp.cfg > $ run > > after it segfaults, type this and send us the output: > > $ where > > thanks, > alex > > p.s. I'm forwarding this to the mailing list. you can sign up > to here: > http://sourceforge.net/mail/?group_id=111647 > > > > > > Ellen Klingbeil wrote: > > Hi Alex, > > I am trying to use the Segway driver in the orca-robotics > package to drive our new Segway Rmp 50 Omni, which has a usb > interface. > For now, I am just trying to send commands / read data > from one > half of the rmp (the 50 Omni is just two rmp's bolted > together). > Specifically, I am trying to write commands to it at a > rate of > just under 100 Hz and read commands continuously. When I run > it, it works for awhile but after a bit of time, it > segmentation > faults. The timing of when this segmentation fault > occurs does > not seem to be predictable.....i.e., sometimes it seems > to run > for 30 sec or more and sometimes it seg faults much > sooner. So > far, I have been unable to track down where this segmentation > fault is occurring, and no information is printed to the > screen > when it occurs. > > Any suggestions or advice you have on what might be happening > would be greatly appreciated!! > > Sincerely, > Ellen Klingbeil > > > -- ------------------------------------ > Ellen Klingbeil > Ph.D. Candidate > Stanford University > Artificial Intelligence Lab > ------------------------------------ > > > -- -------------------------- > Dr. Alex Makarenko > Research Fellow > Centre for Autonomous Systems > (Australian Centre for Field Robotics) > Dept. of Mechanical & Mechatronic Engineering > J04 The University of Sydney 2006 NSW, AUSTRALIA > alexei[at]cas.edu.au <http://cas.edu.au> <http://cas.edu.au> > www.cas.edu.au <http://www.cas.edu.au> <http://www.cas.edu.au> > > +61 (0)2 9036 7057 (tel) > +61 (0)2 9351 7474 (fax) > > > > > -- > ------------------------------------ > Ellen Klingbeil > Ph.D. Candidate > Stanford University > Artificial Intelligence Lab > ------------------------------------ > > > > > -- > ------------------------------------ > Ellen Klingbeil > Ph.D. Candidate > Stanford University > Artificial Intelligence Lab > ------------------------------------ |