pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 9:21 am

I have got on pretty well developing a dc motor driver using s simple H bridge and rotary encoder and pigpio, all written in Python. Functionally it works well as fast as my little motors will go (about 13000rpm) with very low error rates (so far indistinguishable from zero), however the cpu utilisation gets pretty high (on a raspberry pi zero), and I am wondering what I might do to improve the cpu utilisation.

Below are details of what I have found and 1 alternative I tried, plus a couple of thoughts as to what else I might try. I would appreciate views on these, or any other, ways I might improve the performance without using extra hardware.

I'm running this on a raspbian-lite install on a pi zero-W.

In outline the approach I have taken runs the motor controller in a separate python process using a pipe from the control process.

To handle the rotary encoder I use a pigpio callback with no callback function and merely read the tally count at appropriate intervals - I know which way the motor (should) be turning so I don't need to do clever things with the 2 quad inputs, just counting all the edges gives me pretty good accuracy. The little class that I use for this part is on github here.

The motor runs at ~13,000 rpm and I use both pins of a 3 pole / rev quad encoder. This means the maximum edge period is ~0.75 milliseconds or ~ 1,300 edges per second.

It seems that pigpio fires off callback data from it's daemon down its internal connection to my process, where pigpio python code picks up the data and updates a local tally count. I can then read the tally count at my convenience. (for pid style feedback 50 millisecond intervals works pretty well)

The cpu utilisation I see on a pi zero is:

* no monitoring of encoder - any motor speed: cpu ~ 10%
* monitoring on, motor stationary: cpu 10%
* 1 motor at 1,600 rpm (about slowest reliable speed) cpu: 28%
* 1 motor at 6,000 rpm: cpu: 60%
* 1 motor flat out (13,000 rpm): cpu: 84%
* 2 motors at 1,600 rpm) cpu: 30%
* 2 motors at 6,000 rpm: cpu: 60%
* 2 motors flat out cpu: 84%

Clearly there is some smart stuff going on that increases the efficiency of processing the callbacks as the rate increases.

I have also checked with top to see where the cpu is going. At idle the pigpio daemon uses ~7.5% cpu. 2 motors flat out the pigpio daemon uses ~ 20% cpu. The rest is the python process. In these tests I was not running any extra code to read the tally counts or do other processing so I believe my process' cpu is pretty much entirely the pigpio callback processing.

I tried writing a C process to monitor the pins using wiringpi, running in a separate process using shared memory which I could watch from another process running python, but while this had much lower cpu utilisation, it was pretty hopeless and started dropping a few edges at 2,000rpm, and quickly got a LOT worse.

The other ideas I thought might improve things are:
  1. use the C interface to pigpio in my code - I'd write a small C wrapper so most of my code would still be python, but pigpio's code to pick up the edge callbacks would now be C and hopefully lots faster!
  2. implement an extension to pigpio's daemon code specifically geared to this type of use which would count edges and send messages back based on a timer, which would invoke a callback in my code (at say 10 or 20 times a second). This would drastically reduce the message rate between the daemon and my code and hopefully make a big reduction in overall cpu utilisation. However this would be MUCH harder than option 1!
  3. totally roll my own and replace pigpio. Not at all keen on this idea - there is clearly a lot of very smart stuff going on in pigpio that I would rather not have to understand in detail!
I'll probably have a go at option 1 in the meantime anyway, just to see if it looks at all promising.

User avatar
joan
Posts: 13558
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 9:41 am

The bottleneck will be the Python callback processing code. It's not big, perhaps 20 or 30 lines of code but it's all Python and takes time.

Doing the same with the C pigpiod_if2 interface might be hundreds of times faster for that code.

PiGraham
Posts: 3401
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 9:43 am

You can use pigpio from c which should hep a bit.
Yu are pushing the limits of what's practical under Linux. You could offload the counting to hardware. There ate quadrature counter ics that can cope with high rate encoder counting. Your coide could then just query the position when it needs it using i2c.
You might also use a microcontroller or dedicated device to do the motor control and talk to that as needed from your application code.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 9:53 am

joan wrote:
Tue May 15, 2018 9:41 am
The bottleneck will be the Python callback processing code. It's not big, perhaps 20 or 30 lines of code but it's all Python and takes time.

Doing the same with the C pigpiod_if2 interface might be hundreds of times faster for that code.
I suspected the first bit, but even ten times faster would be a dramatic improvement! I'll give it a go.

Thanks for the advice.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 10:09 am

PiGraham wrote:
Tue May 15, 2018 9:43 am
Yu are pushing the limits of what's practical under Linux. You could offload the counting to hardware. There ate quadrature counter ics that can cope with high rate encoder counting. Your coide could then just query the position when it needs it using i2c.
Pushing? Yes, reached? No. So why add more hardware? Also my experience of using i2c for anything remotely approaching real time has shown it to be flakey at best.
PiGraham wrote:
Tue May 15, 2018 9:43 am
You might also use a microcontroller or dedicated device to do the motor control and talk to that as needed from your application code.
But if it runs now on a pi zero (and especially if I can get 30% or so of the cpu load) it will be a nice clean, simple, low cost solution. Plus when Pi 4 comes out the load should drop significantly 8-) .

A Pi Zero with an explorer pHAT is a really nice small, low power solution for this - it already works, I just want to have more free cpu for some more functionality.

User avatar
joan
Posts: 13558
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 12:30 pm

pootle wrote:
Tue May 15, 2018 9:53 am
joan wrote:
Tue May 15, 2018 9:41 am
The bottleneck will be the Python callback processing code. It's not big, perhaps 20 or 30 lines of code but it's all Python and takes time.

Doing the same with the C pigpiod_if2 interface might be hundreds of times faster for that code.
I suspected the first bit, but even ten times faster would be a dramatic improvement! I'll give it a go.

Thanks for the advice.
Just to clarify. The speed improvement would be in the pure Python which handles the callbacks. If you rewrote all the Python to use pigpiod_if2 there would be an improvement but not quite so dramatic. Mostly Python code is a mixture of pure Python and calling external libraries which are already written in something like C (think numpy, opencv etc).

PiGraham
Posts: 3401
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 6:43 pm

pootle wrote:
Tue May 15, 2018 10:09 am
PiGraham wrote:
Tue May 15, 2018 9:43 am
Yu are pushing the limits of what's practical under Linux. You could offload the counting to hardware. There ate quadrature counter ics that can cope with high rate encoder counting. Your coide could then just query the position when it needs it using i2c.
Pushing? Yes, reached? No. So why add more hardware?
...
I just want to have more free cpu for some more functionality.
It seems you have hit this concern early in your development. It would be wise to keep well away from those limits and keep some headroom for when things start to get difficult. Why battle problems you don't have to? Work on core functionality not worrying about every CPU cycle just to make it barely work.
Clearly you can have as much free CPU as you like in this regard by doing the hard real-time bits on hard real-time hardware. But the choice is yours.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 11:06 pm

First cut c code looks pretty promising. I have just re-written the quad capture code along the lines of the pigpiod_if2 rotary encoder example.

I can track a single motor at 13,000 rpm with zero missed pulses with total cpu around 43%. The c process is around 12% according to top.

I think I'll interface back to the python code using c-types and shared memory.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 15, 2018 11:18 pm

PiGraham wrote:
Tue May 15, 2018 6:43 pm
But the choice is yours.
Quite so, I enjoy the challenge.

People Who Say It Cannot Be Done Should Not Interrupt Those Who Are Doing It

User avatar
OutoftheBOTS
Posts: 660
Joined: Tue Aug 01, 2017 10:06 am

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 16, 2018 6:57 am

@poote I am following your development as it is quite interesting to me to see what you can come up with.
PiGraham wrote: ↑
Wed May 16, 2018 4:43 am
But the choice is yours.

Quite so, I enjoy the challenge.
I understand your thirst for the challenge. There is going to be a lot more challenge yet as reading the encoders is just first layer of processing, you then need to run the PID to control the motors based upon the encoder feed back and as you know the motor speed isn't linear so a single PID won't do a very good job so this will also chew up a lot of CPU as well. Once you have that working then this is just the very fist low level step of a robot normally there will be many other higher level functions like maybe reading other sensors and working out actions to take based upon these other sensor, maybe computer vision, maybe wifi or blue tooth interface, maybe graphics or sound. In the end if you make it work then all your processing power will be chewed up on just very first level of code and this willm mean any robot using this system will be very limited on doing anything else.. It is normal that when ever possible to off load over heads of low level fuctions off the main processor on to another embedded processor so to free up the main processor for higher level functions

User avatar
joan
Posts: 13558
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 16, 2018 7:27 am

My take is finding ways of doing things on the Pi without having to resort to additional hardware is a win win situation.

The person doing the development learns a lot and it lowers the entry cost for everyone else wanting to experiment in the area - they may not need to spend money and time buying and testing additional hardware.

PiGraham
Posts: 3401
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 16, 2018 8:14 am

joan wrote:
Wed May 16, 2018 7:27 am
My take is finding ways of doing things on the Pi without having to resort to additional hardware is a win win situation.

The person doing the development learns a lot and it lowers the entry cost for everyone else wanting to experiment in the area - they may not need to spend money and time buying and testing additional hardware.
Ars Gratia Artis is fair enough. Do these things just for the challenge or to learn or to contribute to a community. These are fine ideals.
It doesn't follow that you should constrain yourself to a harder path on the way to some other goal just because the possibility is there. It is valuable in all these ways to create a motor control library, whatever encoder interface is used.

There is something to be said for a reliable solution that doesn't demand a lot of CPU time and still loses counts here and there. Make it work. Make it robust, then value engineer it to work just with gpio under userspace on Linux. Then people can choose those options and not have to compromise their own designs.

No criticism intended, not that there is a wrong way or a right way to do this, just voicing a different view.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 16, 2018 8:41 am

OutoftheBOTS wrote:
Wed May 16, 2018 6:57 am
@poote I am following your development as it is quite interesting to me to see what you can come up with.

I understand your thirst for the challenge. There is going to be a lot more challenge yet as reading the encoders is just first layer of processing, you then need to run the PID to control the motors based upon the encoder feed back and as you know the motor speed isn't linear so a single PID won't do a very good job so this will also chew up a lot of CPU as well. Once you have that working then this is just the very fist low level step of a robot normally there will be many other higher level functions like maybe reading other sensors and working out actions to take based upon these other sensor, maybe computer vision, maybe wifi or blue tooth interface, maybe graphics or sound. In the end if you make it work then all your processing power will be chewed up on just very first level of code and this willm mean any robot using this system will be very limited on doing anything else.. It is normal that when ever possible to off load over heads of low level fuctions off the main processor on to another embedded processor so to free up the main processor for higher level functions
First I think you overstate the level of problem. The rotary encoder monitoring is pretty certainly the most onerous task in the many layered set of things needed as it needs to accurately monitor stuff going on with sub millisecond timings. All the higher order stuff will be running at least an order of magnitude slower, I already have pid feedback control working with the original all python version, but it was a bit flakey with 2 motors running together, with 3 times the free cpu it should work properly once I have interfaced the new C process back to the motor control software.

My overall approach is pretty much along these lines.

Secondly I don't really expect to get all the way on a pi Zero, but the Zero is a great proving ground to check on both overall load and tolerance to running in a pre-emptive OS environment. If it runs OK on a Zero, it will be pretty flawless on a pi 3. Or alternatively I can use the Zero to front end another pi doing the higher end stuff.

A pi zero plus an explorer pHAT at £15 total cost for full feedback control of 2 motors is hard to beat, even if it does nothing else.

I just don't understand why my 1st code cut always seems to end up like it's been in a tumble dryer?

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 16, 2018 1:27 pm

I've cleaned up the C code a bit and made it properly handle more than 1 encoder, and the results are:
  • all stopped :11% cpu
  • 1 motor 1,600rpm: 20%
  • 1 motor 2,400rpm: 31%
  • 1 motor 3,200rpm: 39%
  • 1 motor 4,000rpm: 42%
  • 1 motor 6,000rpm: 42%
  • 1 motor 10,000rpm: 43%
  • 1 motor 13,000rpm: 43%
  • 2 motors at any speed above 1,600rpm: 43%
Once the utilisation reaches just over 40% (1 motor ~3,400rpm) it does not increase further with extra motors or higher speeds.

Just need to hook it up to my pid control class now......

Moe
Posts: 230
Joined: Sun Jan 25, 2015 2:44 pm

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Sun May 27, 2018 2:43 pm

Following this with much interest - I'm doing a similar thing but at a very early stage.

The motors I'm using are JGB37-3530 Chinese knock-off gear motors, advertised as 80rpm but they all seem to be different. Obviously the encoder is on the motor not the output shaft, I don't know the gear ratio and have to measure revs visually. However, my scope measures 2.72KHz when run at full speed, which roughly corresponds to 2100 pulses / rev.

I have a counter circuit from a previous project I could use to divide this down, but I'd rather not lose the precision.

Am I likely to run into trouble at these speeds, using raw python on a Pi3?
Submarine communication systems engineer and amateur robot enthusiast.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Mon May 28, 2018 7:51 am

Moe wrote:
Sun May 27, 2018 2:43 pm
The motors I'm using are JGB37-3530 Chinese knock-off gear motors, advertised as 80rpm but they all seem to be different. Obviously the encoder is on the motor not the output shaft, I don't know the gear ratio and have to measure revs visually. However, my scope measures 2.72KHz when run at full speed, which roughly corresponds to 2100 pulses / rev.

I have a counter circuit from a previous project I could use to divide this down, but I'd rather not lose the precision.

Am I likely to run into trouble at these speeds, using raw python on a Pi3?
Using pigpio and straight python I was reaching the limit with a 17,000 rpm motor with a 3 pole quad encoder - around 200,000 edges per second, so just slightly faster than I expect you will see. However the pure python version was only counting edges (using pigpio), so needed to know separately which way the motor was turning. My new approach uses a small C program that interfaces with pigpio, and updates the motor's position in a memory mapped file, which I then poll from python on a simple timer loop. It seems to work very robustly with no sign of dropping any data.

I run a pid controller in the timer loop (10 or 20 a second) and it works well so far.

Especially if you want to run the motor more slowly at times you really don't want to use an external divider. The slowest my motors can sensibly run is about 1,600 rpm (before the gearbox), and at this speed and a 1/20th second tick there are only a dozen or so pulses per tick, so every pulse is important!

I'm still messing with the code - I'm putting a web front end on it - but there are 3 files in particular on my github repo that deal with the encoder feedback:
  • the C program that can watch multiple motor encoders. It maintains the position of each motor in a memory mapped file. The C program is run automatically from....
  • a Python module that runs the C program in a separate process, and memory maps the same file. The class quadfastwrapper can handle 2 motors' quad encoders (more once I get my brain around arrays of structs in ctypes!), and once setup provides a method that returns 1 motor's position and a timestamp of the last update on demand. This is called from....
  • a Python module with a class (fastencoder) that I use once per motor. It uses an iterator called on a regular tick. It picks up the position and timestamp from quadfast and does some analysis to produce the sort of info a pid controller needs.
I've got a new version of this where the C program converts the timestamp into a 64bit integer to avoid the 72 minute wrapround inherent in the timer used by pigpio.

Moe
Posts: 230
Joined: Sun Jan 25, 2015 2:44 pm

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Tue May 29, 2018 9:14 pm

Thanks pootle. I'm not a great programmer so most of that is way beyond me :o but I think I get the jist. I'll probaby just use standard GPIO callbacks for the encoders and then do the PID as you have - your third link (python module with class) doesn't seem to work?

I have the advantage that I already know which direction the motors are going because I've told them to go that way, but the distinct disadvantage that one motor is twice as fast as the other, so the PID controller is going to have its work cut out...
Submarine communication systems engineer and amateur robot enthusiast.

User avatar
OutoftheBOTS
Posts: 660
Joined: Tue Aug 01, 2017 10:06 am

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 30, 2018 6:25 am

I'll probaby just use standard GPIO callbacks for the encoders and then do the PID as you have
You will find the GPIO call back will miss so many pulses that any sort of speed control or position control just won't work. At 2100 pulses per revolution at a max speed of 80RPM is 168,000 pulses per second per motor. Try hooking up your encoders to your scope while running the software counter based upon GPIO call back and see the difference between the scope count and the software count.

Pootle software counter based upon a low level C implementation of a interrupt using DMA is quite impressive at the speed in which it counts the pulses.

The other way you can do it if you aren't capable of implementing Pootle method is to use and external encoder counter chip like the LS7366R that is capable of counting pulses at speeds up to 40MHz, the manufacture does made a dev board with 6 counter chips see https://lsicsi.com/#/products/Developme ... /LS7366RSh. You can then just poll the counter chip when your updating the PID speed control (usually 10hz is good)

Moe
Posts: 230
Joined: Sun Jan 25, 2015 2:44 pm

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 30, 2018 6:48 pm

I'm measuing 2.72 kHz at (roughly) 80rpm, which is how I derived the figure of 2100 pulses per rev. So callbacks should be OK?
Submarine communication systems engineer and amateur robot enthusiast.

User avatar
OutoftheBOTS
Posts: 660
Joined: Tue Aug 01, 2017 10:06 am

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Wed May 30, 2018 9:08 pm

I'm measuing 2.72 kHz at (roughly) 80rpm, which is how I derived the figure of 2100 pulses per rev. So callbacks should be OK?
Write your software callback and hook it up to both your scope and software call back at same time and compare the 2, if they both count the same number of pulses then all is good but if your callback counts much lower number of pulses then it is missing some. Remember if you hook up more than 1 motor then it need to count more than 1 motor so the callback need to count even more.

Remember with quadrature encoders there is 4 pulses per cycle so if your scope is reading 2.72kHz on 1 pin then this is 2 pulses on that pin as it is a complete cycle of on and off then you will also get the same number of pulses on the other pin on the other pin. If you don't need high precision or direction detection then you could just count the rising edge on 1 pin only and this would reduce the needed counts by 1/4.

If you decide to go with not detecting direction of rotation then this very much cuts down much of what you can do with the motor. One of the common things you want to do with a robot is tell the wheels to turn x amount e.g rotate 2000 ticks forward the PID will accelerate the wheels to get it heading towards desired count but when it gets very close to desired count the PID will reverse the power to brake the motor so that it doesn't roll past the desired count, so now the motor power is in opposite direction to travel of motor and slowing down to stop where it can easily change direction due to power in opposite direction.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Thu May 31, 2018 12:08 pm

If you know the direction the motor is turning, you don't need to use a callback with python and pigpio. Just use pigpio to count the pulses and read the tally at whatever interval you want. This won't drop any pulses as long as the cpu utilisation stays below 80% or so. This should be good for about 1,000 edges per second total for all motors - probably twice that will work on a pi3. You can set pigpio to just count rising edges instead of both to double the effective rate before running into problems - or even just monitor 1 of the 2 quad feedback pins.

Code: Select all

edgectr = pi.callback(pn, pigpio.EITHER_EDGE) # no callback function provided
and then in your timed loop:

Code: Select all

edgectr.s.tally()  #  returns the current count.
The 3rd module uses a generator to fetch the data, so is a bit obscure to use. Maybe I should change that!

Of course this won't work if you want to do the smart stuff OutoftheBOTS describes.

Moe
Posts: 230
Joined: Sun Jan 25, 2015 2:44 pm

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Fri Jun 01, 2018 2:21 pm

Write your software callback and hook it up to both your scope and software call back at same time and compare the 2, if they both count the same number of pulses then all is good but if your callback counts much lower number of pulses then it is missing some.
Results to date are commensurate with what the scope is telling me, but the scope is simply measuring frequency not counting pulses so its not 100% clear. There are many variables (including battery state). My current code is simply sampling the GPIO on a loop, comparing it with previous value, and incrementing the counter if different. It also maintains a count of iterations (i.e. samples). So, on a 30-second full-speed run I get:
Frequency on scope: 2.70kHz
Encoder ticks: 159,492, which is 5,316 edges per second or 2,658Hz.
Samples: 3,403,943, or ~21 times pulse rate.
Runtime: 30.00s

If then turn that on its head and run it for 159,492 ticks, I get
Frequency on scope: 2.70kHz
Encoder ticks: 159,492 (obviously).
Samples: 296,016
Runtime: 29.75s

Which is all pretty consistent, so I reckon its working. What is bizarre though, is the second loop runs ten times slower. The only different is the while loop condition, which has gone from:

Code: Select all

while (Time < 30)
To

Code: Select all

while (Count < distance)
:o :o :o :o
Submarine communication systems engineer and amateur robot enthusiast.

Moe
Posts: 230
Joined: Sun Jan 25, 2015 2:44 pm

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Fri Jun 01, 2018 3:01 pm

Just use pigpio to count the pulses and read the tally at whatever interval you want.
OK, that sounds like a nice simple plan. But I'm not using pigpio for anything else - will it mess with the rest of my code that uses RPi-GPIO and board numbering (I'm a hardware person)?

(Sorry to hijack the thread with noob stuff)
Submarine communication systems engineer and amateur robot enthusiast.

User avatar
OutoftheBOTS
Posts: 660
Joined: Tue Aug 01, 2017 10:06 am

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Fri Jun 01, 2018 9:36 pm

Frequency on scope: 2.70kHz
Encoder ticks: 159,492, which is 5,316 edges per second or 2,658Hz.
Samples: 3,403,943, or ~21 times pulse rate.
Runtime: 30.00s

If then turn that on its head and run it for 159,492 ticks, I get
Frequency on scope: 2.70kHz
Encoder ticks: 159,492 (obviously).
Samples: 296,016
Runtime: 29.75s
Number of read ticks of your software is very close to number of ticks read by your scope. The pigpio library in theory should get better performance than RGPIO.

If your robot has 2 motors running at once and you need to be counting both encoders at once then redo your experiment with the scope and software but with both motors hooked up and counting both motors at once.

pootle
Posts: 270
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: monitoring rotary encoder on fast motor with pigpio - improving performance?

Fri Jun 01, 2018 10:20 pm

Moe wrote:
Fri Jun 01, 2018 3:01 pm
But I'm not using pigpio for anything else - will it mess with the rest of my code that uses RPi-GPIO and board numbering (I'm a hardware person)
As long as the pins are different I believe it should all be OK, (wcpbw?)

Return to “Automation, sensing and robotics”

Who is online

Users browsing this forum: No registered users and 11 guests