LM393 speed sensor

[Russ76]

Note that this sensor is deprecated in the current version of DiffBot because it isn’t a quadrature encoder.

Is there a package we can install that is quadrature enabled? Wouldn't that be better?

Russ

[fjp]

Note that this sensor is deprecated in the current version of DiffBot because it isn’t a quadrature encoder.

That's true

Is there a package we can install that is quadrature enabled? Wouldn't that be better?

No, not directly a package on its own currently. The code for the encoders is running on the Teensy 4.0 (or 3.2) microcontroller. This script is part of the diffbot_base package. Please note that I am using the Encoder Library available on Arduino/Teensy boards. But I guess this should also work on other microcontroller boards.

[Russ76]

I believe the hardware on my "tank" is quadrature, so I'll try to get software to match that. My previous robot didn't have that, and it caused problems moving backward.

[fjp]

I fully agree with you on quadrature encoders and my last comment missed that point a bit. As you mentioned, it is possible to read the direction using quadrature encoders and the motors that I use DG01D-E have one built inside. As far as I am aware, the Teensy Encoder lib that I use makes use of quadrature encoders: counting both edges (rising and falling) on both channels to make use of the counts per revolution (CPR) and therefore yield a high resolution.

source

Unfortunately I don't know if there exist a specific ROS package for quadrature encoders already but it would be interesting to know.

[Russ76]

I see, it is just your hardware that isn't quad, the software is capable! That is good to know. I will continue to install the software.

[Russ76]

Seems like that would be best, to let the Teensy deal with the ticks and free up the Raspberry to deal with cameras and navigation and communications. At this point, (in your documentation) the Raspberry is wired with I2C connections to encoders. I don't understand how the Teensy also deals with this counting?

[fjp]

I see, it is just your hardware that isn't quad, the software is capable! That is good to know. I will continue to install the software.

The ones I use are also quadrature encoders. So I can confirm that it works with the software that I use :-)

Seems like that would be best, to let the Teensy deal with the ticks and free up the Raspberry to deal with cameras and navigation and communications.

Exactly, on the Teensy I also make use of hardware interrupts (done by the Teensy Encoder Library).

At this point, (in your documentation) the Raspberry is wired with I2C connections to encoders. I don't understand how the Teensy also deals with this counting?

This is not the case, otherwise the documentation is wrong. The two "Hall effect pins" (H1 and H2) of each encoder are directly connected to hardware interrupt capable pins on the Teensy. This is documented here but I should add the schematic showing how it is done. I hope to finish that soon.

[Russ76]

From:
https://fjp.at/projects/diffbot/hardware-interfaces/

The LM393 speed sensors also use a single digital GPIO pin each. These pins will be setup using software interrupts with the RPi.GPIO library.
Prepare I2C ConnectionPermalink
The I2C connections are used for multiple components such as the motor driver and the oled display.
Using these ports on the Raspberry Pi 4 B, requires that we enable the I2C interface.

[fjp]

Thank you! That part of the docs, regarding the LM393 speed sensors, is outdated. Also I don't use software interrupts. Now that you showed me I will update it :-)

But it is true that the Grove I2C Motor Driver is connected via I2C to the Rasperry Pi. This motor driver powers the two motors (M+, M-). However, the encoders (H1, H2) are directly connected to the pins on the Teensy, hence no I2C used for them.

[Russ76]

I checked into the Grove I2C motor driver but it was out-of-stock. I got an Ardumoto from SparkFun. But I figured out that their sample program for controlling it was incorrect. They tried to use just one sense line to change direction of motor, and two are required by the L298. In the "spin" portion of the code, they happened to send the two, and the robot will spin, but they failed to note that in the other segments, forward and reverse were not operating properly. In2 and In4 are also needed, and are not wired to the edge of the board, but are accessible in the center portion. I will use the Teensy to drive the Ardumoto board and this should work. Thanks for your guidance!

[Russ76]

Franz, I wonder if you forgot to include the header file for the Teensy encoder program?
https://github.com/PaulStoffregen/Encoder/blob/master/Encoder.h
This is a long one, and includes assembly language, too.

[fjp]

Hi Russ, yes you are right I didn't include the Encoder.h header from the Teensy Encoder library explicitly in my repository. But I am making use of it. When building the Encoder script of this repository it will get linked/included. To make this more clear how it is done: After installing the Teensyduino addon for the Arduino IDE (please see the docs here for more details) you the Encoder library is "ready to use" and can the header can simply be included. This is more or less what I have written briefly here in the docs. I agree this part can also be improved.

Now after you raised this question I am thinking of including the Teensy Encoder library, because as this would make the (next) tag more robust to changes in the Encoder library. I think this is what Linorobot did and it seems that he includes the whole rosserial library too, which I also don't do currently.

On the other hand I am not really a fan of copying complete code sections from another source, because this will likely lead to missing updates in the external libraries. However, to cope with braking upstream changes, I think it would be better to state which tag of the external library/dependency was used or is needed in order to build a specific tag.

I think I will go this way, and add the exact version of the rosserial lib and the Teensy Encoder library to the documentation and also add a comment into the Encoder script of my repository.

[Russ76]

That is interesting, I didn't know it was already included! That makes it easier, yes. What about the switch for Teensy, making it faster:
#define ENCODER_OPTIMIZE_INTERRUPTS // comment this out on Non-Teensy boards
#include "Encoder.h"
I may have to test this and see if it works with Diffbot code.