Hey guys, i am trying to make a drone with arduino uno, mpu6050 and a hc-12 wireless communication module. I am pretty much done with the code and waiting for my brushless motor to arrive.
I have some minor problems in my code yet. Now i am presently trying to make the loop time (refresh rate) consistent. But i am not able to do it and i am not able to figure it how i can change it.
Can anyone help me pls.
I have attached the code.
drone_receiver.ino (13.6 KB)
PROBOT135:
Now i am presently trying to make the loop time (refresh rate) consistent.
What do you mean by "consistent"?
You are measuring the loop() time - how long is it taking?
What problems are you experiencing that you need to fix?
I see "slow" code in your program including the % operator and the map() function.
Do all the functions need to be called in every iteration of loop()?
...R
Hi,
Please read the post at the start of any forum , entitled "How to use this Forum".
OR
http://forum.arduino.cc/index.php/topic,148850.0.html.
Then look down to item #7 about how to post your code.
It will be formatted in a scrolling window that makes it easier to read.
Thanks.. Tom... 
I want the loop time not to fluctuate, I attached a screenshot of the loop time the arduino outputs.
The loop time is as posted in the attachment.(its varying from 2000 to 12000 micro sec)
The map function was to measure the battery voltage, actually i might not need to use the map function at all, si i can remove it.
The % in the loop was written to read the value from the receiver not everytime, even that has been changed now.
I actually didnt post the code in the intended format as it rejected it saying it crosssed the 9000word limit.
Basically i just need to improve my code a little.
Picture.pdf (53.9 KB)
If you just want to display an image please post it as a JPG or PNG and make it visible in your Post. I don't feel like cluttering up my PC with PDF files that are of no interest to me. See this Simple Image Posting Guide
You have not told us what problem is caused by the variation in loop() time.
...R
Hope this is better, sorry for the inconvenience.
I dont want the loop time to fluctuate like in the image.
I want it to be flat and steady.
PROBOT135:
Hope this is better, sorry for the inconvenience.
Please make it visible. I gave you a link to the instructions.
I dont want the loop time to fluctuate like in the image.
I want it to be flat and steady.
Please tell us why that matters - if it doesn't matter then don't waste time optimising it.
...R
If it dosen't matter i guess i woudlnt need it then, for some reasons i taught it needs to be perfect.
Anyway thanks
PROBOT135:
If it dosen't matter i guess i woudlnt need it then,
You are the only person who knows whether it matters - is the drone behaving properly with the inconsistent code?
...R
Use Serial Minitor and print out the loop execution times and show us. How frequently are the abnormalities appearin?
Railroader:
Use Serial Minitor and print out the loop execution times and show us. How frequently are the abnormalities appearin?
See Reply #3.
So far the OP has not given any indication that the inconsistency matters.
...R
@Robin2
My idea was to se the pattern of the abnormalities. Maybe that could be connected to certain other activities being heavy now and then in loop.
I once dealt with a question like this for a satellite command receiver prototype.
Railroader:
My idea was to se the pattern of the abnormalities.
Fair enough.
But if they are not actually causing a problem why bother?
And without a good description of the problem (if there is one) the relationship between the pattern and the problem will not be meaningful.
...R
Railroader:
Use Serial Minitor and print out the loop execution times and show us. How frequently are the abnormalities appearin?
If you try and do that at 2 ms per loop you would soon fill the serial output buffer and choke the sketch.
What -is- possible if there is enough RAM is to collect 40 or more timestamps, the low 16 bits will do, in an array and then print the elapsed times between array values (end - start = elapsed).
When I write non-blocking code I want loop() running fast, 10's of times per milli.
To that end I break my tasks down to run short pieces only as long pieces, especially inner loops are execution-blocking =at the speeds I want loop to run.=
Literally when I process an array or button matrix or like, I process only one element per pass through loop if I can -- sometimes I can't, the data is required immediately.
Break a long process stretch up using a switch-case/state machine.
Don't use floats. AVR has no FPU. Make your working units smaller than your desired precision and integers will do just fine.
Consider Arduino time is in millis and micros(4-granular). If I want to see 2-place seconds I work in millis and have 1 place to round-off that doesn't matter. If I want 3 places, my units become micros.
Consider how in electronics we work in milliamps, not fractional amps, and use microamps when mA isn't small enough.
Use the smallest integers that can do the job -- but don't do mixed math in equations, cast the little ones up then.
If you have long calculations that you can table solutions to in PROGMEM and replace all those calculation cycles with a fetch or maybe 2 fetches and an interpolation. If you learned math on calculators you may need to look that up.
A lookup table of ints can hold sine * 10000. Using it is 100x faster than using sin(). Sine x fixed radius would save more cycles, etc. The sin() function runs a series calculation with a lot of divides, all in floats, it's a Cycle Hog.
@GoForSmike
Using 115200 baud, a 2 digit, last 100 ms, a CrLf printout it looks possible to me.
Your strategic thinking is excellent anyway. It's only to find the bottlenecks.
115200 baud is 11520 chars/sec, 89 micros each. 2digits plus '\n' (newline, don't need Cr as well) is less than 300 micros.
A 20KHz void loop(), 50 usecs, could not print those for long.
I did the store samples in an array and print later to catch switch bounces down to 8 and 12 micros.
Printing binary stored values in decimal, the conversion must happen to get the chars to stuff into the output buffer. Printing decimal values does chew up cycles, printing hex is likely a lot quicker. Getting rid of excess prints is a way to speed slow code up.
