You can subscribe to this list here.
2008 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(1) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
|
2010 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(2) |
2011 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alex M. <ale...@gm...> - 2009-11-18 05:08:35
|
It includes a few API changes and a few bug fixes in the libraries. The build system has been cleaned up to be suitable for packaging for Fedora. Thanks Rich! A list of all changes is here: http://gearbox.sourceforge.net/gbx_doc_history.html#gbx_doc_history_911 Cheers, Alex |
From: Anup K. <anu...@gm...> - 2009-11-01 17:21:54
|
Hi. The fix you did works good and is pretty much the same thing we did ourselves. Thanks Alex Brooks wrote: > Hi Anup, > > Thanks for the bug report. I checked what I think is a fix into svn just now, > but as AlexM points out it's not so easy for us to test it. Can you let me > know if it works for you? > > Alex > > On Sun, 1 Nov 2009, Alex Makarenko wrote: > >> Hi Anup, >> this appears to be an instance of tightening of screws on the part of GCC. >> thanks for bringing it up, >> alex m >> >> >> Alex, >> >> here's the relevant GCC page. >> http://gcc.gnu.org/gcc-4.4/porting_to.html >> search for: "Strict null-terminated sequence utilities" >> >> the "simple fix" they suggest cannot be applied to your code on lines >> 157-159. do you want to take a look? >> >> one problem: I don't think we can test it locally. >> for some reason I don't see this error with gcc-4.4.1 currently >> available in Debian. >> $ g++-4.4 --version >> g++-4.4 (Debian 4.4.1-4) 4.4.1 >> >> On Sun, Nov 1, 2009 at 12:30 PM, Anup Kotadia <anu...@gm...> >> > wrote: > >>> Hello, my name is Anup Kotadia and I am from the Chicago Engineering >>> Design Team and I think I found a bug in GearBox. I was running Ubuntu >>> 9.10 with G++ 4.4.1 and I tried to compile Gearbox and it was keep giving >>> a compile error. I have posted the error message below. I believe this is >>> due to new rules in G++ rather than any incompatibility with Ubuntu 9.10. >>> I have gotten the same error on Gearbox 9.07 and the latest SVN checkout >>> on both 32 bit and 64 bit systems. I had one of my colleagues fix the >>> unlock_dev() function and recompile it and the rest of the build was >>> successful. >>> Thanks >>> >>> Anup Kotadia >>> >>> /home/akotadia/Downloads/gearbox-9.07/src/gbxserialacfr/lockfile/lockfile >>> .cpp: In function ‘void >>> gbxserialacfr::lockfile::<unnamed>::unlock_dev(const char*, int)’: >>> /home/akotadia/Downloads/gearbox-9.07/src/gbxserialacfr/lockfile/lockfile >>> .cpp:159: error: invalid conversion from ‘const char*’ to ‘char*’ >>> >> --------------------------------------------------------------------------- >> --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is >> the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Gearbox-users mailing list >> Gea...@li... >> https://lists.sourceforge.net/lists/listinfo/gearbox-users >> > > > > |
From: Alex B. <a.b...@ma...> - 2009-11-01 12:07:13
|
Hi Anup, Thanks for the bug report. I checked what I think is a fix into svn just now, but as AlexM points out it's not so easy for us to test it. Can you let me know if it works for you? Alex On Sun, 1 Nov 2009, Alex Makarenko wrote: > Hi Anup, > this appears to be an instance of tightening of screws on the part of GCC. > thanks for bringing it up, > alex m > > > Alex, > > here's the relevant GCC page. > http://gcc.gnu.org/gcc-4.4/porting_to.html > search for: "Strict null-terminated sequence utilities" > > the "simple fix" they suggest cannot be applied to your code on lines > 157-159. do you want to take a look? > > one problem: I don't think we can test it locally. > for some reason I don't see this error with gcc-4.4.1 currently > available in Debian. > $ g++-4.4 --version > g++-4.4 (Debian 4.4.1-4) 4.4.1 > > On Sun, Nov 1, 2009 at 12:30 PM, Anup Kotadia <anu...@gm...> wrote: > > Hello, my name is Anup Kotadia and I am from the Chicago Engineering > > Design Team and I think I found a bug in GearBox. I was running Ubuntu > > 9.10 with G++ 4.4.1 and I tried to compile Gearbox and it was keep giving > > a compile error. I have posted the error message below. I believe this is > > due to new rules in G++ rather than any incompatibility with Ubuntu 9.10. > > I have gotten the same error on Gearbox 9.07 and the latest SVN checkout > > on both 32 bit and 64 bit systems. I had one of my colleagues fix the > > unlock_dev() function and recompile it and the rest of the build was > > successful. > > Thanks > > > > Anup Kotadia > > > > /home/akotadia/Downloads/gearbox-9.07/src/gbxserialacfr/lockfile/lockfile > >.cpp: In function ‘void > > gbxserialacfr::lockfile::<unnamed>::unlock_dev(const char*, int)’: > > /home/akotadia/Downloads/gearbox-9.07/src/gbxserialacfr/lockfile/lockfile > >.cpp:159: error: invalid conversion from ‘const char*’ to ‘char*’ > > --------------------------------------------------------------------------- >--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is > the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-users mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-users -- ------------------------------ Dr Alex Brooks Marathon Robotics Pty Ltd National Innovation Centre 4 Cornwallis Street Eveleigh, NSW 2015 Sydney, Australia Ph: +61 2 9209 4021 Web: www.marathon-robotics.com ------------------------------ |
From: Alex M. <al...@ca...> - 2009-11-01 11:47:10
|
Hi Anup, this appears to be an instance of tightening of screws on the part of GCC. thanks for bringing it up, alex m Alex, here's the relevant GCC page. http://gcc.gnu.org/gcc-4.4/porting_to.html search for: "Strict null-terminated sequence utilities" the "simple fix" they suggest cannot be applied to your code on lines 157-159. do you want to take a look? one problem: I don't think we can test it locally. for some reason I don't see this error with gcc-4.4.1 currently available in Debian. $ g++-4.4 --version g++-4.4 (Debian 4.4.1-4) 4.4.1 On Sun, Nov 1, 2009 at 12:30 PM, Anup Kotadia <anu...@gm...> wrote: > Hello, my name is Anup Kotadia and I am from the Chicago Engineering Design > Team and I think I found a bug in GearBox. I was running Ubuntu 9.10 with > G++ 4.4.1 and I tried to compile Gearbox and it was keep giving a compile > error. I have posted the error message below. I believe this is due to new > rules in G++ rather than any incompatibility with Ubuntu 9.10. I have gotten > the same error on Gearbox 9.07 and the latest SVN checkout on both 32 bit > and 64 bit systems. I had one of my colleagues fix the unlock_dev() function > and recompile it and the rest of the build was successful. > Thanks > > Anup Kotadia > > /home/akotadia/Downloads/gearbox-9.07/src/gbxserialacfr/lockfile/lockfile.cpp: > In function ‘void gbxserialacfr::lockfile::<unnamed>::unlock_dev(const > char*, int)’: > /home/akotadia/Downloads/gearbox-9.07/src/gbxserialacfr/lockfile/lockfile.cpp:159: > error: invalid conversion from ‘const char*’ to ‘char*’ > > > |
From: Geoffrey B. <geo...@ai...> - 2009-10-25 23:44:58
|
1) I am not aware of any firmware that makes the URG-04LX return intensity data. If you can't find one on Hokuyo's website, it either doesn't exist or is a firmware created by someone else. 2) The UTM-30LX should support intensity data. Can you put the driver into verbose mode and try again? That might give some clues as to what's going wrong. Geoff Luiz Gustavo Bizarro Mirisola wrote: > Hello, > > I asked these questions in the Orca list, but as they are not > orca-specific they should fit better here: > 1) I was told that to get intensities with a URG-04LX (Classic URG) a > special firmware is needed. With google I find people using this, but > I can not find the firmware. Is it available? Is there some drawback? > > 2) I can not set HighSensibility either to false or true, using the > UTM-30LX (Top-URG) with the GB driver under orca . I do not know if it > is a bug or if the device do not have this capability. I get the > following message when SetHighSensitivity is called: > > [ 10/22/09 12:45:45.405 palma/laser2d: info: HwThread: Creating driver... ] > [ MainThread: 10/22/09 12:45:45.571 palma/laser2d: error: Subsystem > - MainThread status=Initialising/Fault: (while initialising hardware driver) > - caught unexpected exception: > *** ERROR(driver.cpp:131): failed during initialisation of hokuyo_aist. > *** Errorcode: 3, Errordescription: Bad response to HS command: 0E > *** Undefined command 2 ] > > Obviously, not setting the HS is a simple workaround... it is just to > report and see if anybody knows, then the relevant drivers can be > fixed. |
From: Luiz G. B. M. <lui...@gm...> - 2009-10-23 11:22:03
|
Hello, I asked these questions in the Orca list, but as they are not orca-specific they should fit better here: 1) I was told that to get intensities with a URG-04LX (Classic URG) a special firmware is needed. With google I find people using this, but I can not find the firmware. Is it available? Is there some drawback? 2) I can not set HighSensibility either to false or true, using the UTM-30LX (Top-URG) with the GB driver under orca . I do not know if it is a bug or if the device do not have this capability. I get the following message when SetHighSensitivity is called: [ 10/22/09 12:45:45.405 palma/laser2d: info: HwThread: Creating driver... ] [ MainThread: 10/22/09 12:45:45.571 palma/laser2d: error: Subsystem - MainThread status=Initialising/Fault: (while initialising hardware driver) - caught unexpected exception: *** ERROR(driver.cpp:131): failed during initialisation of hokuyo_aist. *** Errorcode: 3, Errordescription: Bad response to HS command: 0E *** Undefined command 2 ] Obviously, not setting the HS is a simple workaround... it is just to report and see if anybody knows, then the relevant drivers can be fixed. ----------------------------- Luiz Gustavo Bizarro Mirisola |
From: Geoffrey B. <geo...@ai...> - 2009-08-28 00:25:44
|
My first comment is that you don't need to pass any parameters to the HokuyoData constructor. It will allocate enough memory itself automatically. Secondly, are you using a laser that produces intensity data, such as the UTM-30LX? If you are, then change the port type used by HokuyoLaser in your call to the Open() method to seriallog, set verbose mode on using HokuyoLaser.SetVerbose(true), and run your program again. This will produce two large output files called port.logr and port.logw and a lot of console output. Tar this all up and post it here. Geoff Geoff Biggs wrote: > I have forwarded your message to the Gearbox users mailing list, so that > other people may benefit from the solution when it is found. > > Geoff > > -------- Original Message -------- > Subject: Problem using GearBox - Hokuyo aist > Date: Thu, 27 Aug 2009 14:19:43 +0000 > From: Martí Morta <mar...@us...> > To: gb...@us... > CC: mar...@us... > > > Message body follows: > > Dear Mr.Biggs, > I'm trying to use GetNewRangesAndIntensities() but it gives > me the next exception: Caught exception: (3) Incorrect > paramaters prefix for ME data. > I suppose i don't give parameters properly, I do this: > > uint32_t ra; > uint32_t in; > unsigned int timei; > hokuyo_aist::HokuyoData datai(&ra,&in,1024,false,timei); > laser.GetNewRangesAndIntensities(&datai,-1,-1,clusterCount); > > I haven't been able to find any solution in mailing lists > neither internet, do you know where I'm mistaking? |
From: Geoff B. <gb...@ki...> - 2009-08-27 14:43:20
|
I have forwarded your message to the Gearbox users mailing list, so that other people may benefit from the solution when it is found. Geoff -------- Original Message -------- Subject: Problem using GearBox - Hokuyo aist Date: Thu, 27 Aug 2009 14:19:43 +0000 From: Martí Morta <mar...@us...> To: gb...@us... CC: mar...@us... Message body follows: Dear Mr.Biggs, I'm trying to use GetNewRangesAndIntensities() but it gives me the next exception: Caught exception: (3) Incorrect paramaters prefix for ME data. I suppose i don't give parameters properly, I do this: uint32_t ra; uint32_t in; unsigned int timei; hokuyo_aist::HokuyoData datai(&ra,&in,1024,false,timei); laser.GetNewRangesAndIntensities(&datai,-1,-1,clusterCount); I haven't been able to find any solution in mailing lists neither internet, do you know where I'm mistaking? I hope you could help me, Thanks a lot! Best Regards, Martí Morta - mm...@ir... Institut de robòtica i Informàtica industrial (Barcelona) Universitat Politècnica de Catalunya -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the "Reply" feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=2611888 |
From: Geoffrey B. <geo...@ai...> - 2009-06-29 07:26:15
|
Gearbox has so far been fairly stable in SVN, but of course that could change at any time. :) When you do find problems in trunk, such as not compiling, let us know so we can fix them. Otherwise we might not notice (sometimes things compile in one place but not in another). Geoff Eduard Trulls wrote: > Hi Geoff, > > Oh, sorry, I didn't have anything specific in mind, I just don't expect > SVN builds to be stable. The last one I retrieved (some weeks ago) > didn't even compile, if I recall correctly. Thank you for your answer > and your work. > > Best regards, > E. > > > > We are planning a release Real Soon Now so that we can get it into the > > next Ubuntu. > > > > What other things does SVN break? > > > > Geoff > |
From: Eduard T. <et...@ir...> - 2009-06-29 06:49:32
|
Hi Geoff, Oh, sorry, I didn't have anything specific in mind, I just don't expect SVN builds to be stable. The last one I retrieved (some weeks ago) didn't even compile, if I recall correctly. Thank you for your answer and your work. Best regards, E. > We are planning a release Real Soon Now so that we can get it into the > next Ubuntu. > > What other things does SVN break? > > Geoff -- Eduard Trulls Fortuny Institut de Robotica i Informatica Industrial (IRI) Parc Tecnologic de Barcelona, Edifici U C/ Llorens i Artigas 4-6, 2ª pl. 08028 Barcelona Tel: 934015780 |
From: Geoff B. <gb...@ki...> - 2009-06-27 11:45:09
|
We are planning a release Real Soon Now so that we can get it into the next Ubuntu. What other things does SVN break? Geoff Eduard Trulls wrote: > Hi, > > Do you plan to make an official release anytime soon? It's fully working > as far as I can tell, but SVN builds may (do) break other things. > > Best regards and thank you for your efforts, > E. > |
From: Eduard T. <et...@ir...> - 2009-06-22 09:57:16
|
Hi, Do you plan to make an official release anytime soon? It's fully working as far as I can tell, but SVN builds may (do) break other things. Best regards and thank you for your efforts, E. -- Eduard Trulls Fortuny Institut de Robotica i Informatica Industrial (IRI) Parc Tecnologic de Barcelona, Edifici U C/ Llorens i Artigas 4-6, 2ª pl. 08028 Barcelona Tel: 934015780 |
From: Matthias N. <mat...@ai...> - 2009-05-19 10:06:19
|
Hi, I've noticed some strange baud rates the hokuyo_aist driver was trying to set. The reason was an wrong stop condition in a for-loop in src/hokuyo_aist/hokuyo_aist.cpp. The appended patch solves the problem. Regards, Matthias Nieuwenhuisen --- src/hokuyo_aist/hokuyo_aist.cpp (Revision 409) +++ src/hokuyo_aist/hokuyo_aist.cpp (Arbeitskopie) @@ -970,7 +970,7 @@ // Failed at the default baud rate, so try again at the other rates // Note that a baud rate of 750000 or 250000 doesn't appear to be supported on any common OS const unsigned int bauds[] = {500000, 115200, 57600, 38400, 19200}; - const unsigned int numBauds = 7; + const unsigned int numBauds = 5; for (unsigned int ii = 0; ii < numBauds; ii++) { reinterpret_cast<SerialPort*> (_port)->SetBaudRate (bauds[ii]); |
From: Geoffrey B. <geo...@ai...> - 2009-04-22 07:55:40
|
I tracked this down to the hokuyo_aist library trying to tell the flexiport library to use baud rates that it didn't support. I've expanded flexiport's supported baud rates to match the full range available under linux (when __linux is defined), and cut back the selection of baud rates that hokuyo_aist tries when probing to exclude 750000 and 250000, which don't appear to be supported by any common OS. Geoff brice rebsamen wrote: > Hi. > > I get this error message from time to time when the hokuyo_aist driver > gets initialized. > > terminate called after throwing an instance of 'flexiport::PortException' > what(): SerialPort::BaudToConstant() Invalid baud rate: 750000 > > Usually it happens several times in a row and then suddenly it works > fine again. Using my own code to read from the laser works fine, so I > don't think it's a laser hardware issue. > > I once saw the verbose message, but there was no much information > besides it happens when calling OpenWithProbing. Unfortunately I do not > have that message anymore. I'll tried to get it again and will send to you. |
From: brice r. <bri...@gm...> - 2009-04-22 07:07:02
|
Hi. I get this error message from time to time when the hokuyo_aist driver gets initialized. terminate called after throwing an instance of 'flexiport::PortException' what(): SerialPort::BaudToConstant() Invalid baud rate: 750000 Usually it happens several times in a row and then suddenly it works fine again. Using my own code to read from the laser works fine, so I don't think it's a laser hardware issue. I once saw the verbose message, but there was no much information besides it happens when calling OpenWithProbing. Unfortunately I do not have that message anymore. I'll tried to get it again and will send to you. Brice |
From: brice r. <bri...@gm...> - 2009-04-15 08:54:41
|
OK I confirm this is working well with the UTM30LX. I think that your new way to parse the VV, PP and II command is a good solution. And now I can see the laser result in playerv. Thank you so much for your efforts Geoffrey Biggs wrote: > brice rebsamen wrote: >> I could not reproduce the last problem reported... This morning it was >> working as expected. > > Probably old data in one of the buffers then. I don't have a good > solution for this yet, as it's hard to know when the laser will spit out > some left-over data, and the user may set an infinite timeout for the port. > >> The checksum workaround you wrote yesterday was not working, because the >> variables _sensorIsUTM30LX and _enableCheckSumWorkaround where not set >> at the right place. Fixed now. > > Thanks for the fix. I've added it to trunk. It was rather ineffective in > the SCIP1 section.. > >> There is another problem in GetSensorInfo while parsing response to >> command II: the UTM30LX does not send a SBPS or "USM Only" line. So I >> added that we only look for that line if _sensorIsUTM30LX is false. > > I decided that, rather than putting a special case for the UTM-30LX in, > I would rearrange the code that reads the sensor info to be more > flexible. Now it doesn't rely on the lines arriving in a specific order, > and won't worry if a line is missing (it will use a default value from > the manual, so I hope their manual has correct defaults). It will throw > an exception when a line it doesn't know is encountered, but this can be > disabled by calling HokuyoLaser::IgnoreUnknowns(true). I've tested this > on my URG-04LX with no regressions; it should work on the UTM-30LX as well. > >> Then I proceeded to try with player (svn version) and I got the >> following error: > > This reminds me that I'm supposed to fix a similar problem with setting > the baud rate in the Player driver. I'll fix those soon (it's an easy > fix). Keep an eye on the Player mailing list. > > > Thanks very much for your work identifying these issues and testing the > fixes for them. > > Geoff |
From: brice r. <bri...@gm...> - 2009-04-15 03:32:55
|
Good morning Geoff, I could not reproduce the last problem reported... This morning it was working as expected. The checksum workaround you wrote yesterday was not working, because the variables _sensorIsUTM30LX and _enableCheckSumWorkaround where not set at the right place. Fixed now. There is another problem in GetSensorInfo while parsing response to command II: the UTM30LX does not send a SBPS or "USM Only" line. So I added that we only look for that line if _sensorIsUTM30LX is false. So with that, hokuyo_aist_example works as expected. Attached is the patch on hokuyo_aist.cpp. Since I am not too sure about creating patches, I am also attaching the full source file. Then I proceeded to try with player (svn version) and I got the following error: ... HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is CR, parameters length is 2 HokuyoLaser::ReadLine() Reading exactly 5 bytes. HokuyoLaser::ReadLine() Read 5 bytes. HokuyoLaser::ReadLine() Line is CR00 HokuyoLaser::ReadLine() Reading exactly 4 bytes. HokuyoLaser::ReadLine() Read 4 bytes. HokuyoLaser::ReadLine() Line is 04T HokuyoLaser::ReadLineWithCheck() Considering 2 bytes for checksum from a line length of 3 bytes. HokuyoLaser::ConfirmCheckSum() Calculated checksum = 84 (T), given checksum = 84 (T) HokuyoLaser::SendCommand() Command response status: 04 HokuyoLaser::SkipLines() Skipping 1 lines. error : hokuyo_aist: Failed to setup laser driver: (3) Bad response to CR command: 04 Not compatible with the sensor model error : Driver failed to Setup (-1) using the following configuration line: driver (name "hokuyo_aist" provides ["ranger:0"] verbose 1) Thank you Brice Geoffrey Biggs wrote: > That data in that layout is a close match for a response to the MD > command, which is used for retrieving data from the laser. The only > reason I can think of for getting that in response to the initial VV > command is that there is data left over from a previous communications > session that isn't getting flushed. I have noticed that my URG-04LX > tends to hold back data when communications are interrupted, then send > it once communications are re-established, leading to odd behaviour > occasionally that even a port flush won't prevent (because the data is > sent after flush is called after the port is opened). Have you tried > powering off the laser completely, then powering it on and running the > test program? > > Geoff > > brice rebsamen wrote: >> Thank you for the quick intervention. >> Another problem appeared: the laser replies random bytes to the VV / V >> commands... >> >> $ ./hokuyo_aist_example -v >> >> HokuyoLaser::Open() Creating and opening port using options: >> type=serial,device=/dev/ttyACM0,timeout=1 >> HokuyoLaser::Open() Connected using serial connection. >> Base status: >> Debug level: 0 Timeout: 1.000000 >> Will block: 1 Permissions: rw >> Serial-specific status: >> Device: /dev/ttyACM0 >> Baud rate: 9600 Data bits: 8 >> Stop bits: 1 Parity: None >> Hardware flow control: 0 >> Port is open >> HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. >> HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is VV, >> parameters length is 0 >> HokuyoLaser::ReadLine() Reading exactly 3 bytes. >> HokuyoLaser::ReadLine() Read 3 bytes. >> HokuyoLaser::ReadLine() Line is MD >> HokuyoLaser::GetAndSetSCIPVersion() Initial SCIP version 2 test failed. >> HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, >> parameters length is 0 >> HokuyoLaser::ReadLine() Reading exactly 2 bytes. >> HokuyoLaser::ReadLine() Read 2 bytes. >> HokuyoLaser::ReadLine() Line is 1 >> HokuyoLaser::ReadLine() Reading exactly 2 bytes. >> HokuyoLaser::ReadLine() Read 2 bytes. >> HokuyoLaser::ReadLine() Line is S >> Caught exception: (9) SCIP versions 1 and 2 failed. >> >> >> This time it replies MD and 1, but each time is different. >> Brice > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Gearbox-users mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-users |
From: Geoffrey B. <geo...@ai...> - 2009-04-15 00:54:21
|
That data in that layout is a close match for a response to the MD command, which is used for retrieving data from the laser. The only reason I can think of for getting that in response to the initial VV command is that there is data left over from a previous communications session that isn't getting flushed. I have noticed that my URG-04LX tends to hold back data when communications are interrupted, then send it once communications are re-established, leading to odd behaviour occasionally that even a port flush won't prevent (because the data is sent after flush is called after the port is opened). Have you tried powering off the laser completely, then powering it on and running the test program? Geoff brice rebsamen wrote: > Thank you for the quick intervention. > Another problem appeared: the laser replies random bytes to the VV / V > commands... > > $ ./hokuyo_aist_example -v > > HokuyoLaser::Open() Creating and opening port using options: > type=serial,device=/dev/ttyACM0,timeout=1 > HokuyoLaser::Open() Connected using serial connection. > Base status: > Debug level: 0 Timeout: 1.000000 > Will block: 1 Permissions: rw > Serial-specific status: > Device: /dev/ttyACM0 > Baud rate: 9600 Data bits: 8 > Stop bits: 1 Parity: None > Hardware flow control: 0 > Port is open > HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. > HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is VV, > parameters length is 0 > HokuyoLaser::ReadLine() Reading exactly 3 bytes. > HokuyoLaser::ReadLine() Read 3 bytes. > HokuyoLaser::ReadLine() Line is MD > HokuyoLaser::GetAndSetSCIPVersion() Initial SCIP version 2 test failed. > HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, > parameters length is 0 > HokuyoLaser::ReadLine() Reading exactly 2 bytes. > HokuyoLaser::ReadLine() Read 2 bytes. > HokuyoLaser::ReadLine() Line is 1 > HokuyoLaser::ReadLine() Reading exactly 2 bytes. > HokuyoLaser::ReadLine() Read 2 bytes. > HokuyoLaser::ReadLine() Line is S > Caught exception: (9) SCIP versions 1 and 2 failed. > > > This time it replies MD and 1, but each time is different. > Brice |
From: brice r. <bri...@gm...> - 2009-04-14 09:58:09
|
Thank you for the quick intervention. Another problem appeared: the laser replies random bytes to the VV / V commands... $ ./hokuyo_aist_example -v HokuyoLaser::Open() Creating and opening port using options: type=serial,device=/dev/ttyACM0,timeout=1 HokuyoLaser::Open() Connected using serial connection. Base status: Debug level: 0 Timeout: 1.000000 Will block: 1 Permissions: rw Serial-specific status: Device: /dev/ttyACM0 Baud rate: 9600 Data bits: 8 Stop bits: 1 Parity: None Hardware flow control: 0 Port is open HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is VV, parameters length is 0 HokuyoLaser::ReadLine() Reading exactly 3 bytes. HokuyoLaser::ReadLine() Read 3 bytes. HokuyoLaser::ReadLine() Line is MD HokuyoLaser::GetAndSetSCIPVersion() Initial SCIP version 2 test failed. HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, parameters length is 0 HokuyoLaser::ReadLine() Reading exactly 2 bytes. HokuyoLaser::ReadLine() Read 2 bytes. HokuyoLaser::ReadLine() Line is 1 HokuyoLaser::ReadLine() Reading exactly 2 bytes. HokuyoLaser::ReadLine() Read 2 bytes. HokuyoLaser::ReadLine() Line is S Caught exception: (9) SCIP versions 1 and 2 failed. This time it replies MD and 1, but each time is different. Brice Geoffrey Biggs wrote: > OK, here's a follow-up. > > I've changed the order of SCIP protocol version checks. It now defaults > to version 2. If that fails, it falls back to version 1, with a check to > see if it can bring the laser up to version 2. This should only apply to > the URG-04 variants, everything else should start in 2 by default since > that's all they're supposed to support. > > I added a self-activating workaround for the checksum issue. It > currently only enables itself when the laser is a UTM-30LX, the VV, PP > or II commands are being sent (to avoid incorrectly using it on laser > data that may coincidentally contain "<-" in the data bytes), and the > initial checksum calculation failed (should handle gracefully if the > firmware is updated to change the current behaviour). It's pretty nasty, > but hopefully, it will work. > > Since I don't have a UTM-30LX, if you could check these fixes work, that > would be a big help. If anyone has an 08 they can have a quick go with, > too... > > Geoff > > Geoffrey Biggs wrote: >> Is the response to the V message in the protocol manual you got with the >> laser? It's not in any of the manuals I have, and the UTM-30LX doesn't >> even support SCIP1 so it shouldn't be responding to a V command at all >> (since a single V would imply a malformed command under SCIP2). On top >> of that, the format of the response you're getting doesn't match the V >> response according to the SCIP1 manual, nor the VV response according to >> the SCIP2 manual... >> >> It shouldn't be too hard to work around this issue (I can make it try >> SCIP2 first, then fall back to SCIP1 on failure - to be honest this bit >> of code is not very good at the moment anyway, it's too >> URG-04LX-centric), but it seems odd that the laser is even responding to >> the V command. >> >> The other issue, I was made aware of recently. It is caused by the >> checksum calculation. It seems that contrary to what the SCIP manual >> implies (although it is slightly ambiguous on this point) and what >> Hokuyo's own sample protocol translator does, the UTM-30LX doesn't >> include comment-like bits of a line in the checksum calculation. These >> are the bits that begin with "<-". I haven't come up with a nice fix for >> this yet (suggestions welcome), but I'm of the opinion that it's a bug >> in the laser's firmware, since it contradicts Hokuyo's own software. >> >> Geoff >> >> brice rebsamen wrote: >>> I am trying to get data from the UTM-30LX. Apparently there is a problem >>> with the protocol implementation: >>> >>> >>> >>> $ ./hokuyo_aist_example -o type=serial,device=/dev/ttyACM0,timeout=1 -v >>> >>> HokuyoLaser::Open() Creating and opening port using options: >>> type=serial,device=/dev/ttyACM0,timeout=1 >>> HokuyoLaser::Open() Connected using serial connection. >>> Base status: >>> Debug level: 0 Timeout: 1.000000 >>> Will block: 1 Permissions: rw >>> Serial-specific status: >>> Device: /dev/ttyACM0 >>> Baud rate: 9600 Data bits: 8 >>> Stop bits: 1 Parity: None >>> Hardware flow control: 0 >>> Port is open >>> HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. >>> HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, >>> parameters length is 0 >>> HokuyoLaser::ReadLine() Reading exactly 2 bytes. >>> HokuyoLaser::ReadLine() Read 2 bytes. >>> HokuyoLaser::ReadLine() Line is V >>> HokuyoLaser::ReadLine() Reading exactly 2 bytes. >>> HokuyoLaser::ReadLine() Read 2 bytes. >>> HokuyoLaser::ReadLine() Line is 0 >>> HokuyoLaser::SendCommand() Command response status: 0 >>> HokuyoLaser::SkipLines() Skipping 2 lines. >>> HokuyoLaser::ReadLine() Reading up to 66 bytes. >>> HokuyoLaser::ReadLine() Read 14 bytes. >>> HokuyoLaser::ReadLine() Line is SERI:00800100 >>> Caught exception: (3) 'FIRM:' was not found when checking firmware version. >>> >>> >>> >>> >>> >>> I wrote my own driver for another framework last year... So I could do >>> some testings: here is what I receive when I send V / VV >>> >>> V >>> 0 >>> VEND:Hokuyo Automatic Co.,Ltd. >>> PROD:SOKUIKI Sensor TOP-URG UTM-30LX >>> SERI:00800100 >>> STAT:FW-bt [Final Distance ] >>> >>> VV >>> 00P >>> VEND:Hokuyo Automatic Co.,Ltd.;[ >>> PROD:SOKUIKI Sensor TOP-URG UTM-30LX;P >>> FIRM:L.1.59(21/Apr./2008);L >>> PROT:SCIP 2.0;N >>> SERI:00800100;f >>> >>> As you can see, the UTM responds to both V and VV. However the code in >>> hokuyo_aist.cpp does not check what type of response is received and >>> assumes that if we get an answer to V, then we are using SCIP1 and >>> proceeds to check the firmware version 3 lines below (in this case it's >>> the serial number). >>> >>> >>> >>> >>> So I proceeded to force SCIP2: in GetAndSetSCIPVersion() I set >>> scip1Failed = true and commented the first block: >>> if (_verbose) { ... } >>> try { SendCommand ("V", NULL, 0, NULL); } >>> catch (HokuyoError) { ... } >>> which results in forcing the function to assume that SCIP1 is not >>> supported, hence try to use SCIP2. >>> >>> After a lots of printing corresponding to result of commands VV and PP >>> processing the result of command II fails: >>> >>> HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is II, >>> parameters length is 0 >>> HokuyoLaser::ReadLine() Reading exactly 3 bytes. >>> HokuyoLaser::ReadLine() Read 3 bytes. >>> HokuyoLaser::ReadLine() Line is II >>> HokuyoLaser::ReadLine() Reading exactly 4 bytes. >>> HokuyoLaser::ReadLine() Read 4 bytes. >>> HokuyoLaser::ReadLine() Line is 00P >>> HokuyoLaser::ReadLineWithCheck() Considering 2 bytes for checksum from a >>> line length of 3 bytes. >>> HokuyoLaser::ReadLineWithCheck() Calculated checksum = 80 (P), given >>> checksum = 80 (P) >>> HokuyoLaser::SendCommand() Command response status: 00 >>> HokuyoLaser::SkipLines() Skipping 1 lines. >>> HokuyoLaser::ReadLine() Reading up to 67 bytes. >>> HokuyoLaser::ReadLine() Read 11 bytes. >>> HokuyoLaser::ReadLine() Line is LASR:OFF;7 >>> HokuyoLaser::ReadLineWithCheck() Considering 8 bytes for checksum from a >>> line length of 10 bytes. >>> HokuyoLaser::ReadLineWithCheck() Calculated checksum = 55 (7), given >>> checksum = 55 (7) >>> HokuyoLaser::ReadLine() Reading up to 67 bytes. >>> HokuyoLaser::ReadLine() Read 51 bytes. >>> HokuyoLaser::ReadLine() Line is SCSP:Initial(2400[rpm])<-Default setting >>> by user;K >>> HokuyoLaser::ReadLineWithCheck() Considering 48 bytes for checksum from >>> a line length of 50 bytes. >>> HokuyoLaser::ReadLineWithCheck() Calculated checksum = 49 (1), given >>> checksum = 75 (K) >>> Caught exception: (3) Invalid checksum - given: 75, calculated: 49 >>> >>> >>> >>> >>> If you do not have a UTM laser for testing, I can help testing the code. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Gearbox-users mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-users |
From: Geoffrey B. <geo...@ai...> - 2009-04-14 09:17:31
|
OK, here's a follow-up. I've changed the order of SCIP protocol version checks. It now defaults to version 2. If that fails, it falls back to version 1, with a check to see if it can bring the laser up to version 2. This should only apply to the URG-04 variants, everything else should start in 2 by default since that's all they're supposed to support. I added a self-activating workaround for the checksum issue. It currently only enables itself when the laser is a UTM-30LX, the VV, PP or II commands are being sent (to avoid incorrectly using it on laser data that may coincidentally contain "<-" in the data bytes), and the initial checksum calculation failed (should handle gracefully if the firmware is updated to change the current behaviour). It's pretty nasty, but hopefully, it will work. Since I don't have a UTM-30LX, if you could check these fixes work, that would be a big help. If anyone has an 08 they can have a quick go with, too... Geoff Geoffrey Biggs wrote: > Is the response to the V message in the protocol manual you got with the > laser? It's not in any of the manuals I have, and the UTM-30LX doesn't > even support SCIP1 so it shouldn't be responding to a V command at all > (since a single V would imply a malformed command under SCIP2). On top > of that, the format of the response you're getting doesn't match the V > response according to the SCIP1 manual, nor the VV response according to > the SCIP2 manual... > > It shouldn't be too hard to work around this issue (I can make it try > SCIP2 first, then fall back to SCIP1 on failure - to be honest this bit > of code is not very good at the moment anyway, it's too > URG-04LX-centric), but it seems odd that the laser is even responding to > the V command. > > The other issue, I was made aware of recently. It is caused by the > checksum calculation. It seems that contrary to what the SCIP manual > implies (although it is slightly ambiguous on this point) and what > Hokuyo's own sample protocol translator does, the UTM-30LX doesn't > include comment-like bits of a line in the checksum calculation. These > are the bits that begin with "<-". I haven't come up with a nice fix for > this yet (suggestions welcome), but I'm of the opinion that it's a bug > in the laser's firmware, since it contradicts Hokuyo's own software. > > Geoff > > brice rebsamen wrote: >> I am trying to get data from the UTM-30LX. Apparently there is a problem >> with the protocol implementation: >> >> >> >> $ ./hokuyo_aist_example -o type=serial,device=/dev/ttyACM0,timeout=1 -v >> >> HokuyoLaser::Open() Creating and opening port using options: >> type=serial,device=/dev/ttyACM0,timeout=1 >> HokuyoLaser::Open() Connected using serial connection. >> Base status: >> Debug level: 0 Timeout: 1.000000 >> Will block: 1 Permissions: rw >> Serial-specific status: >> Device: /dev/ttyACM0 >> Baud rate: 9600 Data bits: 8 >> Stop bits: 1 Parity: None >> Hardware flow control: 0 >> Port is open >> HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. >> HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, >> parameters length is 0 >> HokuyoLaser::ReadLine() Reading exactly 2 bytes. >> HokuyoLaser::ReadLine() Read 2 bytes. >> HokuyoLaser::ReadLine() Line is V >> HokuyoLaser::ReadLine() Reading exactly 2 bytes. >> HokuyoLaser::ReadLine() Read 2 bytes. >> HokuyoLaser::ReadLine() Line is 0 >> HokuyoLaser::SendCommand() Command response status: 0 >> HokuyoLaser::SkipLines() Skipping 2 lines. >> HokuyoLaser::ReadLine() Reading up to 66 bytes. >> HokuyoLaser::ReadLine() Read 14 bytes. >> HokuyoLaser::ReadLine() Line is SERI:00800100 >> Caught exception: (3) 'FIRM:' was not found when checking firmware version. >> >> >> >> >> >> I wrote my own driver for another framework last year... So I could do >> some testings: here is what I receive when I send V / VV >> >> V >> 0 >> VEND:Hokuyo Automatic Co.,Ltd. >> PROD:SOKUIKI Sensor TOP-URG UTM-30LX >> SERI:00800100 >> STAT:FW-bt [Final Distance ] >> >> VV >> 00P >> VEND:Hokuyo Automatic Co.,Ltd.;[ >> PROD:SOKUIKI Sensor TOP-URG UTM-30LX;P >> FIRM:L.1.59(21/Apr./2008);L >> PROT:SCIP 2.0;N >> SERI:00800100;f >> >> As you can see, the UTM responds to both V and VV. However the code in >> hokuyo_aist.cpp does not check what type of response is received and >> assumes that if we get an answer to V, then we are using SCIP1 and >> proceeds to check the firmware version 3 lines below (in this case it's >> the serial number). >> >> >> >> >> So I proceeded to force SCIP2: in GetAndSetSCIPVersion() I set >> scip1Failed = true and commented the first block: >> if (_verbose) { ... } >> try { SendCommand ("V", NULL, 0, NULL); } >> catch (HokuyoError) { ... } >> which results in forcing the function to assume that SCIP1 is not >> supported, hence try to use SCIP2. >> >> After a lots of printing corresponding to result of commands VV and PP >> processing the result of command II fails: >> >> HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is II, >> parameters length is 0 >> HokuyoLaser::ReadLine() Reading exactly 3 bytes. >> HokuyoLaser::ReadLine() Read 3 bytes. >> HokuyoLaser::ReadLine() Line is II >> HokuyoLaser::ReadLine() Reading exactly 4 bytes. >> HokuyoLaser::ReadLine() Read 4 bytes. >> HokuyoLaser::ReadLine() Line is 00P >> HokuyoLaser::ReadLineWithCheck() Considering 2 bytes for checksum from a >> line length of 3 bytes. >> HokuyoLaser::ReadLineWithCheck() Calculated checksum = 80 (P), given >> checksum = 80 (P) >> HokuyoLaser::SendCommand() Command response status: 00 >> HokuyoLaser::SkipLines() Skipping 1 lines. >> HokuyoLaser::ReadLine() Reading up to 67 bytes. >> HokuyoLaser::ReadLine() Read 11 bytes. >> HokuyoLaser::ReadLine() Line is LASR:OFF;7 >> HokuyoLaser::ReadLineWithCheck() Considering 8 bytes for checksum from a >> line length of 10 bytes. >> HokuyoLaser::ReadLineWithCheck() Calculated checksum = 55 (7), given >> checksum = 55 (7) >> HokuyoLaser::ReadLine() Reading up to 67 bytes. >> HokuyoLaser::ReadLine() Read 51 bytes. >> HokuyoLaser::ReadLine() Line is SCSP:Initial(2400[rpm])<-Default setting >> by user;K >> HokuyoLaser::ReadLineWithCheck() Considering 48 bytes for checksum from >> a line length of 50 bytes. >> HokuyoLaser::ReadLineWithCheck() Calculated checksum = 49 (1), given >> checksum = 75 (K) >> Caught exception: (3) Invalid checksum - given: 75, calculated: 49 >> >> >> >> >> If you do not have a UTM laser for testing, I can help testing the code. |
From: Geoffrey B. <geo...@ai...> - 2009-04-14 07:12:21
|
Is the response to the V message in the protocol manual you got with the laser? It's not in any of the manuals I have, and the UTM-30LX doesn't even support SCIP1 so it shouldn't be responding to a V command at all (since a single V would imply a malformed command under SCIP2). On top of that, the format of the response you're getting doesn't match the V response according to the SCIP1 manual, nor the VV response according to the SCIP2 manual... It shouldn't be too hard to work around this issue (I can make it try SCIP2 first, then fall back to SCIP1 on failure - to be honest this bit of code is not very good at the moment anyway, it's too URG-04LX-centric), but it seems odd that the laser is even responding to the V command. The other issue, I was made aware of recently. It is caused by the checksum calculation. It seems that contrary to what the SCIP manual implies (although it is slightly ambiguous on this point) and what Hokuyo's own sample protocol translator does, the UTM-30LX doesn't include comment-like bits of a line in the checksum calculation. These are the bits that begin with "<-". I haven't come up with a nice fix for this yet (suggestions welcome), but I'm of the opinion that it's a bug in the laser's firmware, since it contradicts Hokuyo's own software. Geoff brice rebsamen wrote: > I am trying to get data from the UTM-30LX. Apparently there is a problem > with the protocol implementation: > > > > $ ./hokuyo_aist_example -o type=serial,device=/dev/ttyACM0,timeout=1 -v > > HokuyoLaser::Open() Creating and opening port using options: > type=serial,device=/dev/ttyACM0,timeout=1 > HokuyoLaser::Open() Connected using serial connection. > Base status: > Debug level: 0 Timeout: 1.000000 > Will block: 1 Permissions: rw > Serial-specific status: > Device: /dev/ttyACM0 > Baud rate: 9600 Data bits: 8 > Stop bits: 1 Parity: None > Hardware flow control: 0 > Port is open > HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. > HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, > parameters length is 0 > HokuyoLaser::ReadLine() Reading exactly 2 bytes. > HokuyoLaser::ReadLine() Read 2 bytes. > HokuyoLaser::ReadLine() Line is V > HokuyoLaser::ReadLine() Reading exactly 2 bytes. > HokuyoLaser::ReadLine() Read 2 bytes. > HokuyoLaser::ReadLine() Line is 0 > HokuyoLaser::SendCommand() Command response status: 0 > HokuyoLaser::SkipLines() Skipping 2 lines. > HokuyoLaser::ReadLine() Reading up to 66 bytes. > HokuyoLaser::ReadLine() Read 14 bytes. > HokuyoLaser::ReadLine() Line is SERI:00800100 > Caught exception: (3) 'FIRM:' was not found when checking firmware version. > > > > > > I wrote my own driver for another framework last year... So I could do > some testings: here is what I receive when I send V / VV > > V > 0 > VEND:Hokuyo Automatic Co.,Ltd. > PROD:SOKUIKI Sensor TOP-URG UTM-30LX > SERI:00800100 > STAT:FW-bt [Final Distance ] > > VV > 00P > VEND:Hokuyo Automatic Co.,Ltd.;[ > PROD:SOKUIKI Sensor TOP-URG UTM-30LX;P > FIRM:L.1.59(21/Apr./2008);L > PROT:SCIP 2.0;N > SERI:00800100;f > > As you can see, the UTM responds to both V and VV. However the code in > hokuyo_aist.cpp does not check what type of response is received and > assumes that if we get an answer to V, then we are using SCIP1 and > proceeds to check the firmware version 3 lines below (in this case it's > the serial number). > > > > > So I proceeded to force SCIP2: in GetAndSetSCIPVersion() I set > scip1Failed = true and commented the first block: > if (_verbose) { ... } > try { SendCommand ("V", NULL, 0, NULL); } > catch (HokuyoError) { ... } > which results in forcing the function to assume that SCIP1 is not > supported, hence try to use SCIP2. > > After a lots of printing corresponding to result of commands VV and PP > processing the result of command II fails: > > HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is II, > parameters length is 0 > HokuyoLaser::ReadLine() Reading exactly 3 bytes. > HokuyoLaser::ReadLine() Read 3 bytes. > HokuyoLaser::ReadLine() Line is II > HokuyoLaser::ReadLine() Reading exactly 4 bytes. > HokuyoLaser::ReadLine() Read 4 bytes. > HokuyoLaser::ReadLine() Line is 00P > HokuyoLaser::ReadLineWithCheck() Considering 2 bytes for checksum from a > line length of 3 bytes. > HokuyoLaser::ReadLineWithCheck() Calculated checksum = 80 (P), given > checksum = 80 (P) > HokuyoLaser::SendCommand() Command response status: 00 > HokuyoLaser::SkipLines() Skipping 1 lines. > HokuyoLaser::ReadLine() Reading up to 67 bytes. > HokuyoLaser::ReadLine() Read 11 bytes. > HokuyoLaser::ReadLine() Line is LASR:OFF;7 > HokuyoLaser::ReadLineWithCheck() Considering 8 bytes for checksum from a > line length of 10 bytes. > HokuyoLaser::ReadLineWithCheck() Calculated checksum = 55 (7), given > checksum = 55 (7) > HokuyoLaser::ReadLine() Reading up to 67 bytes. > HokuyoLaser::ReadLine() Read 51 bytes. > HokuyoLaser::ReadLine() Line is SCSP:Initial(2400[rpm])<-Default setting > by user;K > HokuyoLaser::ReadLineWithCheck() Considering 48 bytes for checksum from > a line length of 50 bytes. > HokuyoLaser::ReadLineWithCheck() Calculated checksum = 49 (1), given > checksum = 75 (K) > Caught exception: (3) Invalid checksum - given: 75, calculated: 49 > > > > > If you do not have a UTM laser for testing, I can help testing the code. |
From: brice r. <bri...@gm...> - 2009-04-14 06:10:08
|
I am trying to get data from the UTM-30LX. Apparently there is a problem with the protocol implementation: $ ./hokuyo_aist_example -o type=serial,device=/dev/ttyACM0,timeout=1 -v HokuyoLaser::Open() Creating and opening port using options: type=serial,device=/dev/ttyACM0,timeout=1 HokuyoLaser::Open() Connected using serial connection. Base status: Debug level: 0 Timeout: 1.000000 Will block: 1 Permissions: rw Serial-specific status: Device: /dev/ttyACM0 Baud rate: 9600 Data bits: 8 Stop bits: 1 Parity: None Hardware flow control: 0 Port is open HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, parameters length is 0 HokuyoLaser::ReadLine() Reading exactly 2 bytes. HokuyoLaser::ReadLine() Read 2 bytes. HokuyoLaser::ReadLine() Line is V HokuyoLaser::ReadLine() Reading exactly 2 bytes. HokuyoLaser::ReadLine() Read 2 bytes. HokuyoLaser::ReadLine() Line is 0 HokuyoLaser::SendCommand() Command response status: 0 HokuyoLaser::SkipLines() Skipping 2 lines. HokuyoLaser::ReadLine() Reading up to 66 bytes. HokuyoLaser::ReadLine() Read 14 bytes. HokuyoLaser::ReadLine() Line is SERI:00800100 Caught exception: (3) 'FIRM:' was not found when checking firmware version. I wrote my own driver for another framework last year... So I could do some testings: here is what I receive when I send V / VV V 0 VEND:Hokuyo Automatic Co.,Ltd. PROD:SOKUIKI Sensor TOP-URG UTM-30LX SERI:00800100 STAT:FW-bt [Final Distance ] VV 00P VEND:Hokuyo Automatic Co.,Ltd.;[ PROD:SOKUIKI Sensor TOP-URG UTM-30LX;P FIRM:L.1.59(21/Apr./2008);L PROT:SCIP 2.0;N SERI:00800100;f As you can see, the UTM responds to both V and VV. However the code in hokuyo_aist.cpp does not check what type of response is received and assumes that if we get an answer to V, then we are using SCIP1 and proceeds to check the firmware version 3 lines below (in this case it's the serial number). So I proceeded to force SCIP2: in GetAndSetSCIPVersion() I set scip1Failed = true and commented the first block: if (_verbose) { ... } try { SendCommand ("V", NULL, 0, NULL); } catch (HokuyoError) { ... } which results in forcing the function to assume that SCIP1 is not supported, hence try to use SCIP2. After a lots of printing corresponding to result of commands VV and PP processing the result of command II fails: HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is II, parameters length is 0 HokuyoLaser::ReadLine() Reading exactly 3 bytes. HokuyoLaser::ReadLine() Read 3 bytes. HokuyoLaser::ReadLine() Line is II HokuyoLaser::ReadLine() Reading exactly 4 bytes. HokuyoLaser::ReadLine() Read 4 bytes. HokuyoLaser::ReadLine() Line is 00P HokuyoLaser::ReadLineWithCheck() Considering 2 bytes for checksum from a line length of 3 bytes. HokuyoLaser::ReadLineWithCheck() Calculated checksum = 80 (P), given checksum = 80 (P) HokuyoLaser::SendCommand() Command response status: 00 HokuyoLaser::SkipLines() Skipping 1 lines. HokuyoLaser::ReadLine() Reading up to 67 bytes. HokuyoLaser::ReadLine() Read 11 bytes. HokuyoLaser::ReadLine() Line is LASR:OFF;7 HokuyoLaser::ReadLineWithCheck() Considering 8 bytes for checksum from a line length of 10 bytes. HokuyoLaser::ReadLineWithCheck() Calculated checksum = 55 (7), given checksum = 55 (7) HokuyoLaser::ReadLine() Reading up to 67 bytes. HokuyoLaser::ReadLine() Read 51 bytes. HokuyoLaser::ReadLine() Line is SCSP:Initial(2400[rpm])<-Default setting by user;K HokuyoLaser::ReadLineWithCheck() Considering 48 bytes for checksum from a line length of 50 bytes. HokuyoLaser::ReadLineWithCheck() Calculated checksum = 49 (1), given checksum = 75 (K) Caught exception: (3) Invalid checksum - given: 75, calculated: 49 If you do not have a UTM laser for testing, I can help testing the code. Regards, Brice |
From: Geoffrey B. <geo...@ai...> - 2009-04-01 01:11:06
|
The first thing you should do is add "debug=3" to the list of port options sent to laser->Open(). This will print considerably more output to the terminal, which you can then paste here so we can see what is happening on the port just before it generates the exception. From there we can see what to look for next, or what to fix. Geoff > Hello, > > I'm using gearbox so as to drive an Hokuyo laser URG-04LX on a linux > system (Ubuntu). I succeed in connecting with an USB connection, but now > I have to use the serial connection and it doesn't work anymore.. > > It is what I do in the code : > hokuyo_aist::HokuyoLaser *laser = new hokuyo_aist::HokuyoLaser(); > laser->SetVerbose (true); > laser->Open("type=serial,timeout=1,device=/dev/ttyS0"); > > At the last step, it raises the following exception > "flexiport::PortException" : "SCIP versions 1 and 2 failed". > > The verbose mode shows the following informations in terminal : > > HokuyoLaser::Open() Creating and opening port using options: > type=serial,timeout=1,device=/dev/ttyS0 > HokuyoLaser::Open() Connected using serial connection. > Base status: > Debug level: 0 Timeout: 1.000000 > Will block: 1 Permissions: rw > Serial-specific status: > Device: /dev/ttyS0 > Baud rate: 9600 Data bits: 8 > Stop bits: 1 Parity: None > Hardware flow control: 0 > Port is open > HokuyoLaser::GetAndSetSCIPVersion() Testing SCIP protocol version. > HokuyoLaser::SendCommand() Writing in SCIP1 mode. Command is V, > parameters length is 0 > HokuyoLaser::ReadLine() Reading exactly 2 bytes. > HokuyoLaser::GetAndSetSCIPVersion() Initial SCIP version 1 test failed. > HokuyoLaser::SendCommand() Writing in SCIP2 mode. Command is VV, > parameters length is 0 > HokuyoLaser::ReadLine() Reading exactly 3 bytes. |
From: Geoffrey B. <gb...@ki...> - 2008-11-14 15:35:08
|
If CMake has installed correctly, you should have a link to it in your start menu. Use that to launch CMake and you'll get the GUI version, which will give you the option to select your correct compiler when it starts, with the best one it has detected as available selected by default. I've compiled Gearbox using Visual Studio .NET 2002 and Visual Studio 2008 (although with .NET 2002 I have to manually remove the -Wall option from the extra compile options for each project in the solution, or it pours thousands of irrelevant warnings out, slowing down the compile significantly). Once it's compiled, build the "INSTALL" target to install it, and add the lib and bin directories to your PATH environment variable so that other programs can find them, and add the include and lib directories to your compiler's search paths so it can find the link libraries and headers. Geoff Alexei Makarenko wrote: > Hi Alex, > I'd like to help but I've never built gearbox on Windows. > > I'm forwarding this to the mailing list where it has more changes being answered. > > alex > > > -------- Original Message -------- > Subject: Gearbox setup on Windows > Date: Thu, 13 Nov 2008 09:18:49 +0100 > From: Gabus Alexandre <Ale...@he...> > To: <geo...@ai...>, <a.m...@ca...> > > Hi, > I'm trying to build your great gearbox project on Windows XP platform. > Unfortunately, I can't get it work. Here is what I did : > > 1. Install CMake 2.6 > > 2. Un-tar archive gearbox-x.x.x.tar.gz > > 3. Run "cmake ." in folder "gearbox" created after step 2. > > 4. And I got the following message in my console : > CMake Error: CMake was unable to find a build program corresponding to "Visual S > tudio 6". CMAKE_MAKE_PROGRAM is not set. You probably need to select a differe > nt build tool. > CMake Error: Could not find cmake module file:C:/TD/SVN/Sources/CI/_Environnemen > t/Gearbox/LINUX/gearbox/CMakeFiles/CMakeCCompiler.cmake > CMake Error: Could not find cmake module file:C:/TD/SVN/Sources/CI/_Environnemen > t/Gearbox/LINUX/gearbox/CMakeFiles/CMakeCXXCompiler.cmake > -- Configuring incomplete, errors occurred! > > I don't understand why he is looking for "Visual Studio 6". This soft doesn't > even work on XP platform. Should I reset manually the CMAKE_MAKE_PROGRAM variable? > What should I do? |
From: Alexei M. <al...@ca...> - 2008-11-14 15:14:30
|
Hi Alex, I'd like to help but I've never built gearbox on Windows. I'm forwarding this to the mailing list where it has more changes being answered. alex -------- Original Message -------- Subject: Gearbox setup on Windows Date: Thu, 13 Nov 2008 09:18:49 +0100 From: Gabus Alexandre <Ale...@he...> To: <geo...@ai...>, <a.m...@ca...> Hi, I'm trying to build your great gearbox project on Windows XP platform. Unfortunately, I can't get it work. Here is what I did : 1. Install CMake 2.6 2. Un-tar archive gearbox-x.x.x.tar.gz 3. Run "cmake ." in folder "gearbox" created after step 2. 4. And I got the following message in my console : CMake Error: CMake was unable to find a build program corresponding to "Visual S tudio 6". CMAKE_MAKE_PROGRAM is not set. You probably need to select a differe nt build tool. CMake Error: Could not find cmake module file:C:/TD/SVN/Sources/CI/_Environnemen t/Gearbox/LINUX/gearbox/CMakeFiles/CMakeCCompiler.cmake CMake Error: Could not find cmake module file:C:/TD/SVN/Sources/CI/_Environnemen t/Gearbox/LINUX/gearbox/CMakeFiles/CMakeCXXCompiler.cmake -- Configuring incomplete, errors occurred! I don't understand why he is looking for "Visual Studio 6". This soft doesn't even work on XP platform. Should I reset manually the CMAKE_MAKE_PROGRAM variable? What should I do? Thank you for your help, Best regards, Alexandre Gabus __________________________ Passage Reine-Berthe 1 2610 St-Imier Switzerland Tél. 0041 (0)76 303 53 49 E-mail : ale...@he... <mailto:ale...@he...> |