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
> Gearbox-users@...
> https://lists.sourceforge.net/lists/listinfo/gearbox-users
|