LD19 + ESP32

[tbalatka]

I ordered a Waveshare general driver board to simplify my setup. It contains compass and IMU circuitry. I also ordered an LD19 lidar module as this can easily be plugged into the board and the whole setup can run as a node without an onboard computer.

Question: If I want to use a regular ESP32 with the LD19 directly (no serial board), what pins on the ESP32 should I use for the data information? And do I need to use resistors?

Thanks!

[hippo5329]

You can use any pin to receive lidar serial data except strapping pins, 0 5 12 14 15.

LD19 4 pin headers, txd pwm gnd 5v. keep pwm unconnected. connect txd from LD19 to your LIDAR_RXD.

In my esp32_wifi_config.h, I use 14. Change it, if you use the other pin.

#define USE_LIDAR_UDP
#define LIDAR_RXD 14
// #define LIDAR_PWM 15
#define LIDAR_SERIAL 1 // uart number
#define LIDAR_BAUDRATE 230400
#define LIDAR_SERVER { 192,168,1,100 } // eg IP of the desktop computer
#define LIDAR_PORT 8889

[hippo5329]

On waveshare general driver for robots board. A wire is needed to connect lidar serial data.

lidar 4, add a jumper wire from LIDAR to IO4 on middle header

[hippo5329]

For resistors, do you mean the 10R resistors in series on esp32 i/o pins? They are used to improve signal integrity. It can be 10R, 33R , 110R or others depend on systems. They are often used in productions. It is not required for hobbyist.

[tbalatka]

I was looking at the schematic for the General Driver for Robots board and the LD19 data pin CP_RX is connected to a UART via a 1K resistor. It is not directly connected to the onboard esp32.

[hippo5329]

The 1K resistor is used for protection to the serial USB bridge. The Waveshare General Driver for Robots board is a production quality board. I did follow the same design rules in my past carrier. However, it is not required for hobbyist. The bridge is almost the same function as the small USB adapter comes with the LD19 package. It is used to connect the Pi or robot PC. The CP_RX is not connected to esp32. So we need to add a jumper wire to io4 for the UDP lidar forwarder.

[tbalatka]

I think I get it now. On the middle header you connected a jumper wire from the pin marked "LIDAR" to the pin marked "IO4". Is that correct. Please see attached image.

[hippo5329]

yes

[tbalatka]

I assembled a new, smaller robot to test your forks of the Linorobot2 hardware and software project. I'm now using the Waveshare General Driver board, with an LD19 lidar, and everything is powered by a Waveshare UPS. The two encoder motors are 12v JGA25-371 running at 40 rpm. Lessons learned from this simplified setup will be applied to my larger robot.

The map generated with my new setup is by far the most accurate since I started testing Linorobot2 many months ago. No multiple spiral images in Slam when the robot turns. Also room measurements in meters are bang on. Navigation is a bit hit and miss right now, but I'm sure that will be figured out.

I do have a few questions I hope you can help me with.

1. I uploaded the test_motors firmware to my Waveshare board to get the Counts_Per_Rev value. I pasted this value (250 in my case) into the gendrv_wifi_config.h file and changed the other values to reflect my robot's characteristics. I then uploaded the file and ran Slam (ros2 launch linorobot2_navigation slam.launch.py rviz:=true). The results were very poor. Similar to my larger robot, multiple spiral images were generated when turning. I then played around with the Counts_Per_Rev value and discovered that when I increase it to 2000, the mapping greatly improved. Not perfect, but very close. Is there something I am missing here?

2. When I navigate the robot around the room using teleop_twist_keyboard, if it get's snagged, like on a chair leg, the Slam software continues to move the virtual robot along the grid in RVIZ2, resulting in a messed up map. I have both QMI8658_IMU and AK09918_MAG uncommented in the gendrv_wifi_config.h file, so Slam should be detecting that there is no motion when the robot wheels are spinning on the spot, correct?

3. In the gendrv_wifi_config.h file, what is the purpose of line 196 (#define LIDAR_PWM 5)? Can this be used to start and stop the LD19 lidar so that it is not always spinning?

Thank you so much for your help. It's greatly appreciated.

[hippo5329]

I am very happy to see your progress.

1. Count per revolution, is depended on your gear motor and encoder hardware. It is gear ratio timed encoder pulses per revolution. You will have to lookup the datasheets. However, the encoder parameters are often missing. You should calibrate the rpm reading with a digital tachometer and adjust the COUNTS_PER_REV.

You might change line 148 of test_motors/src/firmware.cpp, to higher value to help the test.
const unsigned run_time = 8; // run time of each motor

You may find tachometers on Amazon. This is the one I used.
https://www.amazon.com/gp/product/B0BYPC2Y5V

2. When you use teleop and snagged, the wheels slipped and odometry went wrong. The slam will corrupt for sure. It could be amended with the other algorithms though I don't know.

3. LIDAR_PWM is not used. This feature is not implemented. I shall remove it later.

[hippo5329]

https://github.com/hippo5329/linorobot2_hardware/wiki#enable-magnetometer

The ekf parameters needs update to enable linear acceleration x y of IMU and yaw of magnetometer. However, it won't help the snagged case.

[shiba-8ro]

@tbalatka Hi, I like this design. What kind of a caster do you use?

[tbalatka]

The robot is on a slight angle like R2D2 so as to minimize forward jerking movement when stopping. The caster is 2" and purchased from a local hardware store. Body, wheels and TPU tires were printed on my Creality K1 Max printer.

[shiba-8ro]

Looks Kawaii. Thanks.