No output from xv11test

[bmegli]

@bobmcfoo wrote:

Hi @bmegli, Thanks for replying so quickly to my questions! I followed the your instructions above on setting the mode Output A port and now the LIDAR sensor's motor is spinning! (though I think the duty_cycle_sp should be set to -40 not 40) However when I tried to run the xv11test program again, it again did not do anything. Is there something else that I could possibly be doing wrong? Thanks again @bmegli!

[bmegli]

Hi @bobmcfoo,

though I think the duty_cycle_sp should be set to -40 not 40

This depends how you solder the connector, but if you followowed the tutorial it's 40 to rotate CCW. I have photographic documentation and 2 LIDAR units, one pair of cables soldered this week so I am pretty sure! ;-)

Whichever way you soldered doesn't really matter but make it spin counterclockwise, otherwise internal LIDAR speed calculation gets confused (kind of works but with a lot of errors).

However when I tried to run the xv11test program again, it again did not do anything. Is there something else that I could possibly be doing wrong?

Make sure you have changed the input port mode to other-uart. (this has to be done once, each time you boot)

Almost always the mapping is the following:

• port 0 -> input 1 (/dev/tty_in1)
• port 1 -> input 2 (/dev/tty_in2)
• port 2 -> input 3 (/dev/tty_in3)
• port 3 -> input 4 (/dev/tty_in4)

Again in theory this depends on the order the kernel loads the drivers of ports but I have not yet seen different order.

So:

First make the motor spin CCW, then:

echo other-uart > /sys/class/lego-port/port0/mode #for port 1
#wait a second, it may take kernel some time to react
./xv11test /dev/tty_in1

If you get nothing on the console then you may try:

Increase duty cycle

Try increasing duty_cycle_sp, to say 45, the LIDAR doesn't output any data if its RPM is lower then 180.

The effective speed the LIDAR is rotatating depends on:

• how much batteries are charged (voltage drops when discharging, the power that duty_cycle_sp gives depends on that
• on the unit (I have 2 units, both run with somewhat different speeds with the same duty_cycle)

Test with picocom

xv11test will try to synchronize.

picocom will output anything there is on the line so:

apt-get install picocom
echo other-uart > /sys/class/lego-port/port0/mode # for input 1
picocom -b 115200 /dev/tty_in1

Then start spinning the LIDAR. If it is soldered correctly you should get message along the line:

`Spin! Press esc 3 times to cancel...' and then continous binary garbage like here

If you get nothing then it's either not that port or there may be problem with soldering.

Double check soldering

I tend to take a photo whenever I solder something before heat shrink tubing so that I can check if I have doubts.

Make sure the cable colours match the ones in tutorial

Specifically look at the photo, image 5 and 8 if you haven't soldered it the other way around (like possibly with motor if you have -40 instead of 40!)

---

Nothing more comes to my mind at this moment.

[bmegli]

Ok @bobmcfoo , I have one more idea to troubleshoot.

The laser pulses are triggered by additional encoder trail on the LIDAR. It is enough for the LIDAR to spin to generate laser pulses, you don't have to read the data.

Those pulses are extremely short (200 microseconds) and are in the visible range of light.

Safe Way I (DSLR)

You need DSLR camera or other camera with adjustable exposure time.

Make the LIDAR spin, put it in a dark room. Set the camera for long exposure time (e.g. 1 minute, maybe longer) triggered after delay pointing the wall near the LIDAR.

When the process finishes you should have a photo of laser dots on the wall.

I did that in the past, with a friend from work, to test the angular accuracy of the LIDAR, I can't find the photo now (locally on some forgotten computer).

Safe Way II (any camera with LCD screen)

I haven't tried that one, it should work. Point the camera with LCD screen directly at LIDAR on LIDAR level in a dark room. You should see a red dot on every revolution. You can use your mobile phone camera.

Unless the electronics do some averaging and the pulse duration is too short. I can try that tommorow.

Desperate Way

_AT YOUR OWN RISK!!!_

The laser is in the visible range of light. It's possible to see the laser dot (blinking shortly on every revolution) with naked eye if you look at exactly correct angle (on LIDAR level).

From theory, specification and Neato claims it is safe but those are claims and specs for operation with original unit.

I did it more than once. This doesn't mean that it is safe! Only that I believe it to be safe. Like everyody else I make errors all the time.

So if you do it this way, do it at your own risk, readup technical parameters of the unit, readup on safety classes and only then make informed decision.

Summary

This will only tell you if the laser is powered, you may still need to troubleshot UART communication. Anyway, first try ideas from the first post.

Additional Ideas

1. Have you plugged USB cable for LIDAR power?
2. Do you have means to measure the current consumption? LIDAR takes around 45 mA when idle and 135 mA when spinning, from USB.
3. Do you use some exotic Wi-Fi dongle? I am using nano type that takes only 10 mA but I also have high power long-range Wi-Fi that takes 500 mA that would not probably work with the lidar from the passive USB hub.

---

Edit: added Safe Way II and "maybe longer" exposure time

[cxqzhou8]

Thanks again for answering so quickly @bmegli! I seem to be having an issue installing picocom.

 robot@ev3dev:~$ sudo apt-get install picocom
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  picocom
0 upgraded, 1 newly installed, 0 to remove and 126 not upgraded.
Need to get 23.0 kB of archives.
After this operation, 82.9 kB of additional disk space will be used.
Err http://ftp.debian.org/debian/ jessie/main picocom armel 1.7-1
  Temporary failure resolving 'ftp.debian.org'
E: Failed to fetch http://ftp.debian.org/debian/pool/main/p/picocom/picocom_1.7-1_armel.deb  Temporary failure resolving 'ftp.debian.org'

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
robot@ev3dev:~$ picocom
-bash: picocom: command not found
robot@ev3dev:~$

Are there any solutions to my problem? Thanks!

[bmegli]

Try:

sudo apt-get update before

You need internet connection for both. This will update package lists which the second command instals from.

You're probably using old ev3dev image or havent updated yet.

Update: fixed typos from mobile

[bmegli]

Also answer those questions:

1. You should solder according to colour coding here, not the pinout. Have you?
2. Have you used original Mindstorms EV3/NXT cable? It doesn't matter if it's original but third party cables have different colour coding (same pinout).
3. Are you certain you haven't flipped the XV11 connector when soldering? (upside down). I do it all the time if I don't bash myself with a hammer and triple check.
4. What is ev3dev version you're using? You can check it from Brickman or type uname -a in the console

[bmegli]

As for the simple way to check if the laser is powered:

Safe Way II (any camera with LCD screen)

I haven't tried that one, it should work. Point the camera with LCD screen directly at LIDAR on LIDAR level in a dark room. You should see a red dot on every revolution. You can use your mobile phone camera.

Unless the electronics do some averaging and the pulse duration is too short. I can try that tommorow.

It works. The green diodes are of other device, the red dot is the LIDAR laser.

_It is difficult_ to put the camera (mobile phone in this case) in the right plane. It is even more difficult to shoot a photo (1 in 5 catches the laser). But don't shoot a photo, just look through LCD screen.

[bmegli]

As for checking if the laser is powered with DSLR I have found the photos we took:

Safe Way I (DSLR)

You need DSLR camera or other camera with adjustable exposure time.

Make the LIDAR spin, put it in a dark room. Set the camera for long exposure time (e.g. 1 minute, maybe longer) triggered after delay pointing the wall near the LIDAR.

From photo metadata:

• exposure time was 77 seconds
• ISO was 1600

[cxqzhou8]

Thank you @bmegli for all the comprehensive replies! I have tried using picocom, but all I get is this:

robot@ev3dev:~$ picocom -b 115200 /dev/tty_in1
picocom v1.7

port is        : /dev/tty_in1
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        :
omap is        :
emap is        : crcrlf,delbs,

Terminal ready

Is there any reason I am not getting anything else?

[bmegli]

@bobmcfoo

Spin the motor. picocom will output anything that there is on the line (UART), provided that there is something on the line.

Just in case I am pasting you my bash session and:

• the cables were soldered this week, the photos of those are on ev3dev.org
• the data is connected to in1, motor to outC, USB hub is plugged to EV3, LIDAR power comes from this hub

root@ev3dev:~# cat /sys/class/lego-port/port6/address
outC
root@ev3dev:~# echo dc-motor > /sys/class/lego-port/port6/mode
root@ev3dev:~# dmesg | tail
[...]
[  543.709614] lego-port port6: Added new device 'outC:rcx-motor'
[  544.062369] dc-motor motor0: Registered 'rcx-motor' on 'outC'.
root@ev3dev:~# cat /sys/class/lego-port/port
port0/ port1/ port2/ port3/ port4/ port5/ port6/ port7/
root@ev3dev:~# cat /sys/class/lego-port/port0/address
in1
root@ev3dev:~# echo other-uart > /sys/class/lego-port/port0/mode
root@ev3dev:~# dmesg | tail
[...]
[  543.709614] lego-port port6: Added new device 'outC:rcx-motor'
[  544.062369] dc-motor motor0: Registered 'rcx-motor' on 'outC'.
[  602.615266] lego-port port0: Removed device 'in1:nxt-i2c-host'
root@ev3dev:~# echo 44 > /sys/class/dc-motor/motor0/duty_cycle_sp

Now is the time to start picocom (you can do it in the second terminal)

root@ev3dev:~# picocom -b 115200 /dev/tty_in1
picocom v1.7

port is        : /dev/tty_in1
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        :
omap is        :
emap is        : crcrlf,delbs,

Terminal ready

Now it's time to spin the motor in the first terminal:

root@ev3dev:~# echo run-direct > /sys/class/dc-motor/motor0/command
root@ev3dev:~# echo stop > /sys/class/dc-motor/motor0/command
root@ev3dev:~#

On the terminal with picocom, this is what you should get:

root@ev3dev:~# picocom -b 115200 /dev/tty_in1
picocom v1.7

port is        : /dev/tty_in1
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        :
omap is        :
emap is        : crcrlf,delbs,

Terminal ready
Spin...3 ESCs or BREAK to abort...R▒R▒R▒R▒R▒R▒R▒R▒R▒R▒R▒R▒R▒qj▒▒'R
R▒▒▒b+R▒R▒R▒R▒"▒"▒"▒"▒"▒"▒M▒Ч/"▒▒F▒/"▒"▒U▒80"▒▒▒▒0"▒"▒"▒"▒
▒o▒u1"▒"▒"▒"▒▒▒u1"#▒u1P▒P▒P▒P▒#▒u1P▒P▒P▒P▒#▒u1P▒P▒PP▒#▒u▒%i▒1P▒P▒P▒P▒)i▒1P▒P▒P▒P▒i▒1P▒P▒P▒P▒1i▒1P▒P▒P▒P▒5i▒2P▒2P▒P▒

Binary garbage continues forever.

[bmegli]

Is there any reason I am not getting anything else?

Yes! We just don't know the reason yet... ;-)

If picocom does not output anything it means that there nothing on the line.

This may mean that:

• you are using wrong input port (/dev/tty_in1 is not where you plugged the LIDAR)
• you have not set other-uart mode
• you have not soldered correctly
• you have not powered correctly
• something else I am missing now

Go over this list double checking.

If I were to guess I would say it's not soldered correctly. If you send a photo of your soldering I can check if it is ok.

The most common error would be soldering:

• the connector upside down
• uart rx/tx the opposite way
• short-circuiting something

I did all of the above when soldering the cables, even for XV11 even though I know what to do.

As for the power - USB hub (if you're using one) should be plugged to EV3, not to something else. It is also a reference potential for the UART lines.

In case you're wondering - to exit picocom hit ctrl+a followed by ctrl+q

[cxqzhou8]

Hi @bmegli I finally got the LIDAR sensor to work! It turns out like you said, the LIDAR sensor needs to be plugged into the EV3's USB port, not an external battery pack as I had been. Thank you for all your comprehensive replies to my questions!

[cxqzhou8]

Hi @bmegli, I have one more question. How do you interpret the data collected from the LIDAR sensor? I have gone to this website http://xv11hacking.wikispaces.com/LIDAR+Sensor but the data from the Python program I have written doesn't seem to match up with the format that is shown on the the xv11 wiki page. Here is the data my Python program has outputted:

b'Spin...3 ESCs or BREAK to abort...R\x80&\x00R\x80&\x00R\x80&\x00R\x80&\x00\xbcC\xfa\xed$&'

Is there something that I am not seeing about the data from my program? Thanks again for being so patient with me!

[bmegli]

@bobmcfoo wrote:

Hi @bmegli I finally got the LIDAR sensor to work! It turns out like you said, the LIDAR sensor needs to be plugged into the EV3's USB port, not an external battery pack as I had been

Awesome! I will update the docs to be clear about the reference voltage potential, sorry about that, I must have made assumption that one plugs it to EV3.

Is there something that I am not seeing about the data from my program?

Let's open-up new issue #5 issue for that.