Velodyne poll() timeout

[Kei Okada]

Hi,

I'm trying to use velodyne_node with 32E model,

        $ rosrun velodyne_driver vdump pcap- eth0

seems ok ( I can replay weith _pcap:= and convert to pointcloud), but

        $ rosrun velodyne_driver velodyne_node  model:=32E _pcap:=""

returns following error.  The device is connected from eth0 of my Ubuntu/11.10/64bit laptop, from previous this node reads the data UDP 2368, but how do I confirm that the data is actually transmitted on the UDP port?

$ rosrun velodyne_driver velodyne_node  _model:=32E _pcap:=""
[ INFO] [1337826767.584699183]: Velodyne HDL-32E rotating at 600 RPM
[ INFO] [1337826767.587163814]: publishing 181 packets per scan
[ INFO] [1337826767.591342085]: expected frequency: 10.000 (Hz)
[ INFO] [1337826767.591714872]: Opening UDP socket: port 2368
[ WARN] [1337826768.596216180]: Velodyne poll() timeout
[ WARN] [1337826769.597411821]: Velodyne poll() timeout
[ WARN] [1337826770.597792376]: Velodyne poll() timeout

[Kei Okada]

I have to set the ip to 193.168.3.255, (this explain in the manual), sorry for the spam question.

sudo ifconfig eth0  192.168.3.255 netmask 255.255.0.0


2012年5月24日木曜日 11時43分05秒 UTC+9 Kei Okada:

[Kei Okada]

Hi

According to the reference manual,( see 8 page of
http://velodynelidar.com/lidar/products/manual/63-9113%20HDL-32E%20manual_Rev%20C_FEB2012%20web.pdf),

For all HDL-32E units, the destination IP address remains fixed at
192.168.3.255.

This means that the 32E sensor send packets directory to the fixed IP,
192.168.3.255, not multi-cast way, and the IP of the device is set to
the 192.168.x.x. (this is also fixed), thus, we need to set
255.255.0.0 netmask.

>> sudo ifconfig eth0 192.168.3.255 netmask 255.255.0.0

does not work well on lucid, since default network manager try to get
IP from dhcp server, currently I set the IP from GUI network manager.

I also add 1 ticket for the calibration.cc :

Index: src/lib/calibration.cc
===================================================================
--- src/lib/calibration.cc (revision 2433)
+++ src/lib/calibration.cc (working copy)
@@ -59,7 +59,7 @@
*pName >> correction.second.min_intensity;
else
correction.second.min_intensity = 0;
- node[MIN_INTENSITY] >> correction.second.min_intensity;
+ //node[MIN_INTENSITY] >> correction.second.min_intensity;
node[FOCAL_DISTANCE] >> correction.second.focal_distance;
node[FOCAL_SLOPE] >> correction.second.focal_slope;

Anyway, thank you very much for developing the nice driver, this
really save my time.

On Thu, May 24, 2012 at 11:08 PM, Jack O'Quin <jack....@gmail.com> wrote:

> On Thu, May 24, 2012 at 1:43 AM, Kei Okada <kei....@gmail.com> wrote:
>> I have to set the ip to 193.168.3.255, (this explain in the manual), sorry
>> for the spam question.
>>
>> sudo ifconfig eth0  192.168.3.255 netmask 255.255.0.0
>

> Glad you asked, actually.
>
> Several people have reported similar problems. They seem to go away
> after a while, but I don't have access to a 32E (ours is an old
> 2007-model 64E), and have not been able to figure out exactly what the
> problem is.
>
> For future reference can you explain the IP setting problem? I would
> like to document the requirement, so others don't stumble over it in
> the future.
>
> It looks like a matter of configuring your ethernet port to listen on
> subnet 192.168.3.x. Is that right? If so, the netmask should probably
> be 255.255.255.0, although 255.255.0.0 probably works as long as no
> other ethernet interface needs to handle 192.168.x.x packets.

>
>> 2012年5月24日木曜日 11時43分05秒 UTC+9 Kei Okada:
>>>
>>> Hi,
>>>
>>> I'm trying to use velodyne_node with 32E model,
>>>
>>>         $ rosrun velodyne_driver vdump pcap- eth0
>>>
>>> seems ok ( I can replay weith _pcap:= and convert to pointcloud), but
>>>
>>>         $ rosrun velodyne_driver velodyne_node  model:=32E _pcap:=""
>>>
>>> returns following error.  The device is connected from eth0 of my
>>> Ubuntu/11.10/64bit laptop, from previous this node reads the data UDP 2368,
>>> but how do I confirm that the data is actually transmitted on the UDP port?
>>>
>>> $ rosrun velodyne_driver velodyne_node  _model:=32E _pcap:=""
>>> [ INFO] [1337826767.584699183]: Velodyne HDL-32E rotating at 600 RPM
>>> [ INFO] [1337826767.587163814]: publishing 181 packets per scan
>>> [ INFO] [1337826767.591342085]: expected frequency: 10.000 (Hz)
>>> [ INFO] [1337826767.591714872]: Opening UDP socket: port 2368
>>> [ WARN] [1337826768.596216180]: Velodyne poll() timeout
>>> [ WARN] [1337826769.597411821]: Velodyne poll() timeout
>>> [ WARN] [1337826770.597792376]: Velodyne poll() timeout
>>>
>>
>

> --
>  joq

[Jack O'Quin]

On Thu, May 24, 2012 at 1:43 AM, Kei Okada <kei....@gmail.com> wrote:

> I have to set the ip to 193.168.3.255, (this explain in the manual), sorry
> for the spam question.
>
> sudo ifconfig eth0 192.168.3.255 netmask 255.255.0.0

Glad you asked, actually.

Several people have reported similar problems. They seem to go away
after a while, but I don't have access to a 32E (ours is an old
2007-model 64E), and have not been able to figure out exactly what the
problem is.

For future reference can you explain the IP setting problem? I would
like to document the requirement, so others don't stumble over it in
the future.

It looks like a matter of configuring your ethernet port to listen on
subnet 192.168.3.x. Is that right? If so, the netmask should probably
be 255.255.255.0, although 255.255.0.0 probably works as long as no
other ethernet interface needs to handle 192.168.x.x packets.

> 2012年5月24日木曜日 11時43分05秒 UTC+9 Kei Okada:
>>
>> Hi,
>>
>> I'm trying to use velodyne_node with 32E model,
>>
>> $ rosrun velodyne_driver vdump pcap- eth0
>>
>> seems ok ( I can replay weith _pcap:= and convert to pointcloud), but
>>
>> $ rosrun velodyne_driver velodyne_node model:=32E _pcap:=""
>>
>> returns following error. The device is connected from eth0 of my
>> Ubuntu/11.10/64bit laptop, from previous this node reads the data UDP 2368,
>> but how do I confirm that the data is actually transmitted on the UDP port?
>>
>> $ rosrun velodyne_driver velodyne_node _model:=32E _pcap:=""
>> [ INFO] [1337826767.584699183]: Velodyne HDL-32E rotating at 600 RPM
>> [ INFO] [1337826767.587163814]: publishing 181 packets per scan
>> [ INFO] [1337826767.591342085]: expected frequency: 10.000 (Hz)
>> [ INFO] [1337826767.591714872]: Opening UDP socket: port 2368
>> [ WARN] [1337826768.596216180]: Velodyne poll() timeout
>> [ WARN] [1337826769.597411821]: Velodyne poll() timeout
>> [ WARN] [1337826770.597792376]: Velodyne poll() timeout
>>
>

--
joq

[Jack O'Quin]

On Thu, May 24, 2012 at 9:24 AM, Kei Okada <k-o...@jsk.t.u-tokyo.ac.jp> wrote:
> Hi
>
> According to  the reference manual,( see 8 page of
> http://velodynelidar.com/lidar/products/manual/63-9113%20HDL-32E%20manual_Rev%20C_FEB2012%20web.pdf),
>
>   For all HDL-32E units, the destination IP address remains fixed at
> 192.168.3.255.
>
> This means that the 32E sensor send packets directory to the fixed IP,
> 192.168.3.255, not multi-cast way, and the IP of the device is set to
> the 192.168.x.x. (this is also fixed), thus, we need to set
> 255.255.0.0 netmask.
>
>>> sudo ifconfig eth0  192.168.3.255 netmask 255.255.0.0
>
> does not work well on lucid, since default network manager try to get
> IP from dhcp server, currently I set the IP from GUI network manager.

As always, network configuration is a complex topic. Thanks for the
clarification. I had forgotten that the 32E does not broadcast like
the 64E does. That definitely affects configuration.

I want to create a Troubleshooting page on the wiki for this package.
This is a problem many people will encounter. When I have a draft
available, I will ask you and others to review it for me.

> I also add 1 ticket for the calibration.cc :
>
> Index: src/lib/calibration.cc
> ===================================================================
> --- src/lib/calibration.cc      (revision 2433)
> +++ src/lib/calibration.cc      (working copy)
> @@ -59,7 +59,7 @@
>       *pName >> correction.second.min_intensity;
>     else
>       correction.second.min_intensity = 0;
> -    node[MIN_INTENSITY] >> correction.second.min_intensity;
> +    //node[MIN_INTENSITY] >> correction.second.min_intensity;
>     node[FOCAL_DISTANCE] >> correction.second.focal_distance;
>     node[FOCAL_SLOPE] >> correction.second.focal_slope;

Thanks for the bug report and the fix. I committed your patch to SVN.
It passes the unit tests. I will regression test with our 64E tomorrow
(but do not anticipate any problems).

I am concerned that my unit tests did not cover this case. I think I
know what is missing. Just to be sure, would you be willing to send me
copies of your 32db.yaml and 32db.xml files?

> Anyway, thank you very much for developing the nice driver, this
> really save my time.

You are welcome. I am happy for more people to use it. When we share
code it improves, because you and others provide valuable testing and
bug fixes.

Regards,
--
 joq

[Kei Okada]

Hi,

find attachment for 32db.{xml,yaml} files,

best

[Jack O'Quin]

On Thu, May 24, 2012 at 11:08 AM, Kei Okada <k-o...@jsk.t.u-tokyo.ac.jp> wrote:
> Hi,
>
> find attachment for 32db.{xml,yaml} files,

Thanks. That was helpful, because my guess as to the root cause of the
test case deficiency was quite wrong.

The actual problem is that none of my automated tests use 32E data.
That needs to be remedied right away.
--
 joq