The red line is the desired setpoint we see it here go up from zero to the desired value at the moment I have connection But there is not yet power supply to the motor driver board. At the moment I turn on the power supply we see the green and magenta line go up. The green and magenta lines are the speed measurements. So these values need to end up on the red line which is the setpoint. 
This seems to work there is indeed a big overshoot and I think I know how to reduce this but that is for later work (I will explain). I'm verry happy that the control circuit reaches its setpoint. This is done with a PID controller and a Arduino NANO 33 IoT. In fact it is only a PI controller and tuning without the Ki I get a huge difference between setpoint and measured value tuning the I makes me come to this result.

This huge overshoot I could reduce more by working with the Kd gain but I have waited with that for now cause these tests were done unloaded. I mean by that that the wheels don't feel any inertia from the wight of the bot. I will tune it more. I just wanted to share that I was eventually able to make a PID control working with a Arduino and encoders. There is a bit more to tune I know.

Now how I appriached this is that I count in a interval of 100ms the amount of pulses the enconder counts (with interrupts) with this value I comput the rpm value. This value I use for the PID regulation, but the PID regulation has also a time to do its calculations. And this is a important thing to take into acount. 
The library I used has a setting where you can set it's sample time and it basicallly meanse how many times per second it computes it's algorithm and send new outputs. This MUST match with the speed you sample the speed. And this was a bit of tuning.

Maybe for many people this is a easy thing to tackle for me it took a while and learned a lot of things  Again the overshoot I can reduce I think and maybe it is not even to much of an issue when seeing the bot driving I will see

It was more about understanding the algorithms hidden in the libraries.

Thanks for clarifying ... I tried to give my understanding of how the terms originated, which may have detracted from describing the need to look at the algorithms.

I totally agree with your comment, and hence I suggested implementing PID as explicit code.

Best wishes, Dave

It was more about understanding the algorithms hidden in the libraries.

Perhaps assembler is a bit low level although it used to be my language of choice before the Windows OS came along.

Arduino c++ uses functions such as pinMode() digitalRead() attachInterrupt() and so on to make programming the microprocessor much easier so you don't have to understand how it works at the hardware level.

  This note will not directly help your motors rotate at the same speed, but I hope it gives a little perspective to different programming approaches that you can generally find helpful.

---

  When @robotbuilder mentioned "highest level" and  "lower level", I think the "high" and "low" level referred to the programming level.

In the past, programming in assembly language, and before that machine level, where you are manually specifying the individual machine level instructions of the processor was referred to low level programming. Here the human programmers have to imagine exactly what the processor will do, often delving down to the bit level of 1s and 0s.

High level programming meant programming in a language that was more 'human centric', and tried to hide the '1s and 0s' world of the machine processing. One of the older and more successful 'high level' languages, which is still in use, is Fortran ... apparently named from FORmula TRANslation. This provided a means of readily implementing mathematical formulas in a form that was similar to the original mathematical expression.

It should be noted that languages like Fortran began the shift away from emphasising efficiency of the program from the machine's perspective, by also considering the cost in time, labour, etc. of the programmer. That is, the execution time of a Fortran program may have been longer than a carefully hand optimised assembler program that performed the same task, but the Fortran program would have required far less human effort to write and test it.

Of course, this dates back to the 1960s, perhaps earlier, and things have hugely expanded since then, so the relatively simple distinction between high and low level languages and programming is a lot more blurred.

For example, the C programming language was specifically designed to provide 'high level' abstraction from the machine's internals that assembly language approach demanded, whilst retaining (at least) the majority of flexibility and direct access to the processor's internal structure needed in some cases. The extension of C into C++ has further expanded the language into the 'high level' domain, whilst retaining the 'low level' operations for the programmer who needs it.

In more recent times, the 'low' and 'high' level terms seem to be applied not only to programming languages, but also some of the related tools, code libraries, and so on, which provide access to computing functions. It could be suggested that using a spreadsheet like Excel, or CAE program based on Spice to simulate an electronic circuit, are examples of a very high level approach, though I suspect some people might think this is over stretching the definition.

However, I think it illustrates the range of choices that are now available. The spreadsheet enables someone who does not know what a 'traditional' computer programme looks like, and struggles with basic mathematical operations like division, (at least without using a calculator,) to perform relatively complex arithmetical tasks, such as calculating their company and personal financial accounts.

This means that the high level approach can be greatly empowering. However, the 'danger' is that the user does not understand the implications of the task they are requiring the machine to do, and may not realise when it is inappropriate or even failing. We have all read of cases of a single person living a small house, has been sent an electricity bill equivalent to millions of dollars. Obviously, this is an extreme case, but I hope you see the point.

-------

Hence, I think @robotbuilder ws suggesting you would find it useful to start with a 'low level' approach to your project ... certainly I would support that view.

My view does not mean I suggest you do everything in assembler, but rather that you aim to build at a level that you feel you really understand and can "see" what is happening at the "machine" ... the controller and motors in your case ... level.

e.g. I suggested you code a simple mathematical expression to 'manually' implement the proportional control, because I think it gives a much better understanding and visibility as to what is happening, compared to calling up an obscure library. It might also be more efficient from the processor's viewpoint! When you are ready to build in the I & D parts of the PID, I think the same applies.

Of course, the disadvantage is that it may take you longer to do it this way. In the future, you may justifiably decide you don't need to go to such a low level, and something like using a prewritten library is the more efficient process. That is fine ... but hopefully, your earlier experience will also provide you with the knowledge and experience to avoid the equivalent of sending the multi-million dollar electricity bill!

Good luck and best wishes, Dave

https://www.falstad.com/circuit/circuitjs.html

No worries everybody is here helping me and I learn from everybody something. 

I don't understand your comment fully. I think I'm doing a real basic thing and that is controlling a motor.

After some thought I realized the post probably was of no help to you but the hour had passed and I couldn't delete it. I won't try and explain as it is really off topic for this thread. We all have to run our own race and do it our way.  If someone can't help you do it your own way then they aren't of much use to you.

@electricray1981 We have all been there, don't worry it will come. I am attaching a couple of screen grabs. I am working with real-time clock code that uses interrupts, have a look at how they do it, and note they did NOT use the fast memory macro IRAM_ATTR so you are well ahead of the game. Also note the use of volatile for the ISR flag, without that it will not work, look it up in Arduino.cc docs to find out why.

So basically they do the same as what I am doing but they use a Real Time Clock?

Oh, I didn't know you were not a programmer.

Some basic proramming I know we have spoken about that the more advanced stuff I am not familiar with...thats why I'm here to learnmore stuff. The code I wrote for my project is all done by myself no copy paste from other projects, but offcourse I ooked at examples on how to do certain things.

I dont understand your comment fully. I think I'm doing a real basic thing and that is controlling a motor. So in order to let the bot drive straight. IMHO that is a basic thing. Yes I have had different libraries to filter the measurement and yesterday I have tried a different approach on that. Further there are two libraries in my code in orer to use MegunoLink.

Yes I kind of think maybe @electricray1981 would benefit by starting much simpler without the libraries to get a feel of how things work at a basic level the way I am doing in another thread. At the highest level I guess you would start with ROS without any understanding at all about lower level operations.