ESP32_ Annex32 learns to fly :-)

[PeterN]

Annex32 learns to fly
Some times ago I tested a magnetic levitation project with Arduino-code and had the dream to do that with Annex32 as well.
So I did find now the possibilities and limitations of an interpreter based language and I have to confess that the final inflight time was only about 10 seconds.
BUT IT WORKS! as you can see here:


or as a video : https://vimeo.com/521144739

I used this schematic with a HALL-sensor, a M5 Atom lite (= ESP32pico) an electromagnet and some strong stacked permanent magnets in the "payload" :


The electromagnet is a modified 5V-relay with a 3v3-input. Schematic and modification are described _here_

The ANNEX32-code is very minimalistic for max performance. As the interpreter causes some "jitter" I did not manage to keep the "payload" in the air for more than 10 s.
Any ideas for making this code faster and jitter free are very welcome. My final idea is to deactivate the WIFI now .
But I guess that I have reached the speed limits of the interpreter

Code: [Local Link Removed for Guests]

bluetooth.delete
wlog can.stop
spi.stop

pin.mode 23, output
do
  if adc(33)> 2543 then
    pin(23)=0
  else
    pin(23)=1
  endif
loop

end

[cicciocb]

Very nice application.
Yes, disabling the WIFI might improve a little bit but, in fact, all the network activity uses the core 0 whilst the interpreter runs on the core 1.

[bugs]

Hi Peter,
I don't know anything about the internal workings of Annex but I used to play with BASIC interpreters at the machine code (6800) level. It might just make a slight difference if the interpreter does not have to work out numbers each time through the loop.
For example the 2543, the adc and the pin it has to read 2...5...4...3 and create a value.
You could try setting constants with short names e.g a=23, b=2543 and see if it makes any difference.
Of course interpreters may have grown up since I last dabbled with them.

[Electroguard]

You could turning off unwanted OPTIONS...
OPTION.LOWRAM 0 will disable low mem checking
OPTION.WDT 0 will disable watchdog checking
OPTION.WLOG 0 will disable logging

It also might help to turn error checking off...
ONERROR IGNORE

[bugs]

OK - forget my suggestion of changing the numbers to constants. A quick test showed too tiny a difference to make it worthwhile.
If you need a faster response then might have to add an op amp or comparator with the Hall as one input and the ESP providing a PWM or DAC voltage to the other.

[PeterN]

Thank you Bugs,
I did the same variable test and came to the same conclusion - but it was worth a try.
It seems that it is not a lack of speed but the jitter that makes the payload jump. And as there is only a range of about 2mm in this hardware setup where the height of the magnetic payload can be controlled, it needs only a very small time to get out of this range.

If I use Arduino-code there is almost no jitter, and in combination with more speed I can even use a code-based hysteresis.

I have built the pure analog version of this "magnetic-levitation" with a LM311 comparator.

Following the jitter-thought I used Electroguards hints. AND THAT HELPED A LOT
This optimized ANNEX32 code leads it now to a flight duration of minimum 60seconds:

Code: [Local Link Removed for Guests]

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

pin.mode 23, output
do
  if adc(33)>2542 then
    pin(23)=0
  else
    pin(23)=1
  endif
loop
end

[cicciocb]

Hi Peter,
probably killing the wifi should remove all the jitter but you lose the control of the module

[GSontag]

Hi Peter,
Did you have a try with the PID controler and as Bugs suggest, output a PWM which will smooth the output and may reduce the jitter.
Gérard

[PeterN]

Hi Gerard,
thanks, you are absolutely right ... if there was not the very small range of controllable height of only 2mm of the magnet payload. That makes it necessary to be very very fast. And additionally the PID works best only with a regulated continuous output-signal (PWD or analog).
I remember ciccioCB's code-example for a fan speed controll, There the PID with its transient response is the perfect solution.

So I think, if we were on the Moon with its lower gravity it should definitely work this way

[PeterN]

Hi Francesco
I regard this iust as a challenge to do things that are at first sight obviously out of the the range.
I could now try to use an output constant in frequency, but modulated in its puls-width . So the puls width should no more be jittering , but switch between two values.
Not a project with practical value at first sight - but it may help to know the limits of usability.

Hi Peter,
probably killing the wifi should remove all the jitter but you lose the control of the module