ESP32_ Annex32 learns to fly :-)

Place your projects here
User avatar
Nighthawk
Posts: 7
Joined: Fri Feb 19, 2021 5:23 pm
Has thanked: 20 times
Been thanked: 2 times

Re: ESP32_ Annex32 learns to fly :-)

Post by Nighthawk »

I love this project Peter!

You are right 'may' not have practical application but then again I'm betting the learning experience and pushing Annex code and esp modules to the limit is, IMHO, not at all a waste of time.

now to find those Hall Effect Sensors I bought a few years ago.

thanks for sharing this.
Keep us updated on your progress.
Dwight
AndyGadget
Posts: 222
Joined: Mon Feb 15, 2021 1:44 pm
Has thanked: 120 times
Been thanked: 132 times

Re: ESP32_ Annex32 learns to fly :-)

Post by AndyGadget »

Probably only a tiny difference if any, but have you tried replacing the DO LOOP with a GOTO?
User avatar
PeterN
Posts: 366
Joined: Mon Feb 08, 2021 7:56 pm
Location: Krefeld, Germany
Has thanked: 171 times
Been thanked: 203 times
Contact:

Re: ESP32_ Annex32 learns to fly :-)

Post by PeterN »

Thanks Andy,
Yes I tried it with GOTO and WHILE 1 - and DO ...LOOP was the best way.
But trying this showed, that optimizing this (constant) delays is not the game changer. There are irregular occuring delays that seem to have much more influence (garbage Collection??? Etc)
User avatar
PeterN
Posts: 366
Joined: Mon Feb 08, 2021 7:56 pm
Location: Krefeld, Germany
Has thanked: 171 times
Been thanked: 203 times
Contact:

Re: ESP32_ Annex32 learns to fly :-)

Post by PeterN »

Thank you for your kind interest Dwight.

Be careful with the Hall-sensor. I had no success with the cheap SS49-Hall-Sensors that you can find on the breadboard-ready-PCBs, but I never really found out why they failed. But the A1302 and A1308 did the job. The analog version with the LM311 is a good test for the hardware setup. It is worth a quick test on a breadboard! And keep in mind the good quality of the 5V-supply - my Notebook's USB-5V are ugly and very unstable.

[flash=]May 2021,ADDITIONAL EDIT AFTER WRITING THE ABOVE ABOUT THE HALL-SENSOR:
I did some more and very successful tests with the cheap and well known Hall sensor SS49E. You find it very often at hall-sensor-boards for breadbords. But take a second look at the quality of the supply voltage![/flash]




Today I had a good idea of how to make the code one step faster by changing the central IF-THEN-ELSE clause to a very simple one-liner.
This is the complete ANNEX32-code now:

Code: [Local Link Removed for Guests]

option.wlog   1
wlog time$
bluetooth.delete
x=can.stop
spi.stop
option.lowram 0
option.wdt    0
option.wlog   0
onerror       ignore

pin.mode 23, output

do : pin(23)=adc(33)<2480
loop

end


That made the code again a lot faster and with that ...
I finally could keep the payload in flight for more than 10 minutes!!!

I took a short timelapse-Video of the 10minutes-flight and here is an animated GIF of that:
(Please observe the stopwatch in the background; it shows the minutes)

Image
Last edited by PeterN on Sun May 02, 2021 5:41 am, edited 2 times in total.
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: ESP32_ Annex32 learns to fly :-)

Post by Electroguard »

An idea for a potentially beneficial use of your flying contraption...

Nothing beats gravity, so 'flight duration' is eventually signaled by 'the drop'... therefore the drop could be used to measure 'flight time'
Schrödinger might poke his cats tail through the loop to make it yelp when the object falls on it, but there are other ways to measure flight time.
Once able to measure flight time, 'comment out' all the features which have been disabled in the script, then do a few 'flights' to get an average 'baseline' (was previously 10 sec max).

Then walk through the commented lines one by one to un-comment one line at a time to get an averaged flight time with just that feature disabled.
Afterwards, deducting the 'baseline' figure from those values will provide a comparison list of relative performance gains for all the disabled features.
A relative performance gain chart for disabled features could be very handy for projects requiring critical performance and repeatability.
(eg: a flying drone, or perhaps a 2-wheeled self-balancing robot, or a PTZ camera platform)

Some food for thought:
You could also include disabled wifi in the performance gain list, by autorunning the script rather than starting it from a browser.
If the performance gain was great enough with wifi disabled, wifi could still be used to control that device by adding a second device just for the wifi control link. The 2 devices could communicate with each other serially, and perhaps even utilising CAN BUS by connecting gpio pins directly without needing transceiver modules (haven't had a chance to try it yet, but could offer real advantages if was possible).

A performance gains chart of disabled features could actually be quite a worthwhile contribution, because it would allow users to see at a glance what features they could turn off and for what sort of benefit they could expect.
User avatar
PeterN
Posts: 366
Joined: Mon Feb 08, 2021 7:56 pm
Location: Krefeld, Germany
Has thanked: 171 times
Been thanked: 203 times
Contact:

Re: ESP32_ Annex32 learns to fly :-)

Post by PeterN »

Thank you Electroguard,

i will leave Schrödingers cat's box unopened, as that might influence my measurements :-)
Although ... maybe quantum mechanical fluctuations actually have limited the flight time.

I found out that there are two game changers :
- the speed of the loop but with less effect than expected
- the jitter in the loop repetition time with a strong influence to the stability of flight level

To test the effect of the optimisations I took this ANNEX-code:

Code: [Local Link Removed for Guests]

option.wlog   1
wlog time$
'bluetooth.delete
'x=can.stop
'spi.stop
'option.lowram 0
'option.wdt    0
'option.wlog   0
onerror       ignore

pin.mode 23, output

do : pin(23)=1-pin(23)
loop

end
This creates a 4.8 Khz signal at pin 23. To observe the jitter I took a digital oscilloscope and accumulated the signal for 5 minutes.
The first picture shows the signal with the above not optimised code - second pic is with the optimisation lines.

Image

Image

This shows that there seems to be no direct effect on the speed of the (very short!) code.
But without the optimisations there are more and longer sporadic extensions of the processing time, which then lead to crashes of the payload.


Btw: I used "ONERROR IGNORE" in both cases as only this allowed the one-liner statement "DO : PIN(23)=1-PIN(23)"
Post Reply