GPIO Pins don't read out right

JorenFrans

Hey everyone!

I'm currently working on an autonomous robot. When we started we used a Raspberry Pi to collect data from our rotary encoders on the GPIO pins. We wrote a python file that perfectly read out 73.736 pulses when we rotated our wheel exactly 1 time. We calculated this amount of pulses using the wheel-to-encoder ratio and the amount of pulses of 1 encoder rotation. The number was correct.

Later on, we noticed that our camera lost frames due to an SDK that didn't work that well on Raspbian. That's when we made the decision to step up to an UP Squared board. We installed Ubuntu 18.04 because we work with ROS Melodic, and the SDK works better with this OS. The UP Squared board works perfectly with the camera now and takes over the other tasks of the Pi just fine.

We tried our script to read out our encoders on the UP Squared. At first we didn't get any results due to a kernel that didn't support the GPIO and the RPi.GPIO package that isn't made for Ubuntu 18.04. We downgraded our kernel to 5.0.0 generic, and made three versions of our script: the original one, one using the mraa package, and one using the periphery package. We also managed to install an RPi.GPIO package for Ubuntu 18.04.

We got all three of them reading out our encoder data! But not in the right way... When we drive our robot really slow, they all 3 tend to the 73.736 pulses per rotation , but when we drive full power, they only manage to read out 17-24K pulses. The slower we drive, the more pulses we get through. Also, when we drive fast, the script thinks we drive forward, when we drive slow, it thinks we drive backwards. When we drive backwards it is the other way around.

We've been troubleshooting for a while now... here's some things we noticed and tried to catch:

• The current could be to low to power all devices connected to the up squared (it gets it's power from a power module). So we hooked it up to it's original charger, but no difference.
• We tried different pins from the GPIO, all general GPIO pins, no difference.
• We read somewhere that the UP Squared doesn't come with pull up/down resistors, so we put in our own hardware resistors in the robot, no difference.
• We tried to use the Linux GPIO pinout, the RPi pinout and the normal Pin numbers, only the normal pin numbers get data through, the rest gets errors that the pins don't exist.
• We've been looking in the BIOS settings to maybe be able to change some things, nothing found.

I provided our scripts to read out the encoders with this question, which work on the raspberry.

We think it may be due to the pulses coming in too fast, but I think if the Raspberry can handle it, the UP Squared should be able to do that too. Maybe there is a problem with processor counters/clocks or interrupts which have influence on our script? Does anybody have an idea why not all of the pulses come through?

thanks a lot in advance!
Joren

DCleri

We think it may be due to the pulses coming in too fast, but I think if the Raspberry can handle it, the UP Squared should be able to do that too

Hi @JorenFrans

That assumption is not correct. The GPIO of a Raspberry Pi are actually much faster, this is due to the GPIO controller available in Intel platforms.

If the behaviour changes depending on the system workload, I would suggest you to "pin" the process/GPIO read application (and not use for other purposes) to a specific core. If you do that, try to use core1, 2 or 3.
Core0, even if pinned, is used by the system for other low level tasks.

Also, avoid to drain too much power from the GPIO, they are not meant to power external devices (this is valid in general with most platforms, including RPi).

Regarding the numbering, are you using the table available on MRAA documentation for UP Squared?
https://github.com/eclipse/mraa/blob/master/docs/up2.md

JorenFrans

Hi @DCleri

First of all, Thanks for your answer. We tried your suggestion to dedicate a core (core 3) to our application. It made no difference though. About the power supply, we only drain power from the GPIO to power the Encoders, the rest of the devices are connected with USB. So I don't think that's the problem. We also used the numbering in the right way when we tried the different pinouts, according to the MRAA documentation.

So you think the GPIO just isn't fast enough to read out the encoders? We are thinking about implementing an Arduino to take over the encoders and to send out the pulse-counters over intervals to the UP board. Do you think this is a better idea? Or should it still be possible to get in done with the UP-board?

Thanks in advance,
Joren

DCleri

How much power do the encoder requires? You have to be careful as the GPIO can provide only 0.1/0.2A

I think for motor control, realtime, encoders, the best way would be to use a dedicated MCU if you need that kind of speed and reliability on GPIOs.
A small STM32 MCU can do the job and it is also arduino compatible, we have it already integrated in UP Xtreme (also Celeron Version).

Or you can connect a Bluepill module externally via UART or USB to achieve the same:
https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html

JorenFrans

The encoders take up a maximum of 15mA/encoder, we use 2 of them, so I don't think that'll be the problem.

A dedicated MCU is a possibility indeed. We are currently testing with an Arduino Nano we still had laying around. We can read out 1 encoder perfectly at all speeds, but when we try to read out the other one too, It's too much for the Arduino and we lose approximately half of the pulses. Maybe we can look at an alternative like the Bluepill you suggested. We'll keep this post updated when we make any progress.

Thanks a lot for the help. If you have any other suggestions, we are happy to hear.