Write driver packages for sensors

[fjp]

Sensors

• [x] RPi Camera - UbiquityRobotics/raspicam_node
• [ ] Ultrasonic distance sensor
• [x] disc wheel encoder
• [ ] Inertial measurement unit

[ghost]

Hi Franz, there are drivers for the ultrasonic sensors. Take a look at https://github.com/htl-ooe/ros/blob/main/htl_ooe_smart_car/src/sonar.cpp I just try to build something like a "car" for HTL students with ROS and I am happy to read your github pages... The driver uses a kernel module from Andreas Klinger, which is not included to the standard kernels. I just build it according to the instructions on https://github.com/htl-ooe/ros, they are based on the UbiquityRobotics/pi_sonar package, and they are very accurate. You can find circuit diagrams on https://github.com/htl-ooe/board, no need for an extra microcontroller. Nice thing is to add as many sensors as you want to in the devicetree and the driver will publish them all according to their DT name. You could also try the encoders attaching directly to the rpi with dtoverlay=rotary-encoder,= and get the information via sysfs just like the sonar info. Franz

[fjp]

Hi Franz, great, thanks a lot for sharing, this is very helpful! I am planning to add two or more sonars in the future, so this should come in handy. I hope to get back to this soon becaue currently I am mainly working on improving the documentation. Any feedback or PRs on this or other tasks is also highly appreciated.

You could also try the encoders attaching directly to the rpi with dtoverlay=rotary-encoder,= and get the information via sysfs just like the sonar info.

This would be great because its hard to find space for the extra microcontroller in the new robot design that I am working on. So far I'm also having troubles with the accuracy of the encoders that are built inside the DG01D-E motors - although its ok (a video of that will follow soon in the documentation). Anyway, would be interesting to know if attaching the encoders directly to the rpi would improve the accuracy of the odometry. But I guess the resolution of the encoders (approx 550 ticks) is the bottleneck here. One of my high priority todos is to make use of the imu and merge its data with the encoder data.

Thanks again for your valuable input. Best regards Franz

[ghost]

Hi Franz, looked around and found interesting things: First one is https://www.raspberrypi.org/forums/viewtopic.php?t=234579, which mentions the 80-character limit in the DT Files. Take care about that. Then the encoder shows up as event device, so you could implement it just like my IR event device https://github.com/htl-ooe/ros/blob/main/htl_ooe_smart_car/scripts/ir.py. This one is not event triggered, but with ROS polling could make more sense? Ciao Franz

[ghost]

Hi Franz, if you are still interested: I tried your motors with

rotary-V1-0-overlay.dts -> content

// Definitions for rotary encoder V1.0 Module /dts-v1/; /plugin/; / { compatible = "brcm,bcm2835"; fragment@0 { target-path = "/"; overlay { rotary@0 { compatible = "rotary-encoder"; gpios = <&gpio 17 0>, <&gpio 18 0>; linux,axis = <0>; / ABS_X / rotary-encoder,steps = <0x7fffffff>; rotary-encoder,encoding = "gray"; rotary-encoder,rollover; }; }; }; };

compile with sudo dtc -@ -H epapr -O dtb -o "/boot/overlays/rotary-V1-0.dtbo" -W no-unit_address_vs_reg './rotary-V1-0-overlay.dts' and add dtoverlay=rotary-V1-0 to your /boot/config.txt I did not miss a single pulse (one motor)! Ciao Franz

[fjp]

Thank you Franz, this looks very interesting! I will get back to this when I find more time to work on the project again and finish other open issues.