Working with ArduPID for Motor Speed Control

@robotbuilder 

It's late (early morning) here but I will start make a thread with my goals and progress tomorrow. This would help for others to give advise offcourse. 

Hi @robotbuilder,

  Thanks. I was generally discussing my prejudice against using general library code in interrupt handlers.

I have a reasonable idea of what micros() is intended to achieve ... just never looked to see what the source code is  ... and that to me is not a 'safe' place to be for a routine called by an  interrupt handler, which I think has to be 'squeaky clean', etc. if the unexpected is to be avoided.

Looks like you might get away with it this time, but I note the article summarises with:

try to never use millis() and micros() as well.

I am happy with that!

Best wishes, Dave

@davee 

This makes me curious!!! This is a good subject for another topic when one should use it and when not and offcourse why! 🤣 

@davee @electricray1981

Sorry, I am not in a position to review your code, but I noticed this:

//Interrupt for left speed sensor
void IRAM_ATTR isrLeft()
{
  usLeft = micros();
  if ((usLeft - pulseUsLeft) > 7500)    

In particular the call to a library routine micros() from an interrupt handler.

Now, I have no idea what code micros() uses, and whilst it may be benign, it is sort of trick I would put on the 'dodgy suspects' list.

Dave is very correct, the general rule for ISR's is do as little as possible. Unless there is a very compelling reason, simply set a bool flag and in the main loop test the flag and if true, turn it off and do the rest of the statements.

 I see you do know to use the MACRO IRAM_ATTR, most do not.

@zander 

Well if I knew how to use it correctly I would not have these issues 🤣 😉 

I used and example but when you mention this it makes clear to me that I don't know how to use it at all.

I know and understand that in a interrupt one should make the code as short as possible. But with all the good help here and on other places I'm getting a bit lost and desperate.

Like I wrote tomorrow I'll post a e new topic with a good explanation on the hardware I hve and what I would like to accomplish. Cause this is not going to work how I want it. I appreciate everybodies help very much and I have leanred a lot but what I am doing now is the wrong way I guess.

@zander 

Your comments may be obvious for some people but i get lots reaing your comment. I'm verry sorry to write this but I don't understand it. This is obviously because my lag of understanding prgramming languages and working with uControllers i'm sorry . But I want to understand it so I'll dve into it and try to understand.

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

@zander 

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.

@robotbuilder 

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.

@zander 

Posted by: @zander

↑

@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?

Posted by: @zander

↑

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.

@electricray1981 

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.

@robotbuilder 

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

@electricray1981 NO, not RTC, I was showing you an example of how to code an ISR. Controlling a motor is NOT basic, working with resistors, capacitors, transistors is basic. Here is a website where you can practice on the web before building for real.

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

Hi @electricray1981,

  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