Angle mode about yamspy HOT 39 CLOSED

Ricardo, Thanks for the detailed information and prioritization. I will learn the material and update on the appropriate solution. Lets keep ion touch :)
Regards,
John

from yamspy.

Sure, next week I will get my drone back and update!
John

from yamspy.

Be careful with the simpleUI.py example. All it does is to enable / disable a switch (aux1, 2...), so it will only enable "Angle mode" if your flight controller was configured to enable it on that switch. When you push "m" or "M", simpleUI is checking the current state of "aux2" and changing accordingly to this:

                elif char == ord('m') or char == ord('M'):
                    if CMDS['aux2'] <= 1300:
                        cursor_msg = 'Horizon Mode...'
                        CMDS['aux2'] = 1500
                    elif 1700 > CMDS['aux2'] > 1300:
                        cursor_msg = 'Flip Mode...'
                        CMDS['aux2'] = 2000
                    elif CMDS['aux2'] >= 1700:
                        cursor_msg = 'Angle Mode...'
                        CMDS['aux2'] = 1000

In addition, you need to make sure your receiver is configured to use the correct channel map. AETR (Aileron, Elevator, Throttle and Rudder) is the default for YAMSPy and all RC commands will be expected to start with Roll, Pitch, Throttle and Yaw, exactly in this order. Additionally, the auxiliary channels will come just after Yaw following their own numbering (Aux1, Aux2... for Betaflight or CH5, CH6... for iNAV).

Finally, considering you have done everything correctly, angle mode has a max tilt angle setting that tells the flight controller how much the drone can tilt and using betaflight the drone will only be really stable if and only if you calibrated (trimmed) the accelerometer. Even after trimming, it will only be kept stable if the drone doesn't change between flights (battery position, propellers, etc).

I hope that helps :)

from yamspy.

Thank you Ricardo for the detailed comment.
The settings in Betaflight configurator meets the code (see snapshot) beside the "Flip mode" that I removed as I don't need it (but didn't touch the code, only pressed "m" twice).

I saw that when I press "m" so the drone mode is changed accordingly in Betaflight configurator so this funcionality works.
The angle mode is set to 25 degrees but the drone is stable and parallel to the ground (it's not close to 25 degrees) but when I start the SimpleUI.py and raise the throttle to hove above the ground - the drone doesn't stabilize itself although it is in angle mode". I thought that maybe something is need to be configured in init.py?
Please note that I run simpleUI.py as a standalone script (without init.py) and done have a remote controller so it's only the program.

What do you think?

Best,
John

from yamspy.

All the stabilization comes from the flight controller (betaflight), so there's no need to change anything in YAMSPy. In general, a non trimmed drone will automatically drift on the horizontal place as it takes off. If your drone is drifting, then you need to calibrate it following the betaflight documentation or the link in my previous message. Another possibility is to have your drone crazily crashing as it takes off (flipping, spinning, etc). That usually means the motors are spinning to the wrong direction, the propellers are wrong (remember, you have L and R propellers), the IMU is rotated in relation to the default config, etc. When there's one of those problems the flight controller overshoots trying to fix it (what is impossible because the sensors or actuators are wrong) and that makes the drone go totally nuts :)

from yamspy.

I calibrated the drone and still it happens, maybe its a problem with the FC?
If yes than I can re-build a new drone and try it. what do you think?
John

from yamspy.

Could you record a video, upload somewhere and post the link here? That would be the easiest way to spot what the problem is.
Extra questions:
How did you calibrate the drone (trimming) without flying? Maybe you calibrated the accelerometer using the betaflight configurator, but it's not the same as the trimming. It should fly if the motors + propellers are setup properly and only drift. Don't forget that the altitude may be tricky to control (betaflight doesn't do that automatically), so I would use the simpleUI and increase the throttle very gently until it takes off. In this situation it should drift (X or Y), but without doing anything crazy if everything is setup correctly.

Have you checked the motors direction? They should match what you see in the betaflight configurator. If they are wrong, you can change by software. See the steps here: https://www.getfpv.com/learn/fpv-essentials/how-to-setup-reversed-propellers/

Last but not least, after confirming the motors are spinning in the correct direction, you should verify if the propellers are correct. If they are wrong, the air will be blown up instead of downwards. However, with the wrong motor direction, a wrong propeller may blow air upwards and the drone will not fly because it uses thrust and torque to control the drone.

I hope that helps. Cheers!

from yamspy.

Hi,
The drone flew and as you said, drifted to to X/Y but didn't "go crazy" :)
but when I pressed "m" - I saw at Betaflight Configurator that it moved to "angle mode" but still I had to press the arrows in order to old the position.
I thouyght that in angle mode it should stabilize itself and it results with position hold.

What do you think?

John

from yamspy.

I'm not following Betaflight closely, but I think they haven't re-implemented position hold yet :(
Therefore, if you want it you will need to switch to INAV (or Ardupilot / PX4 / etc). You can achieve position hold by using GPS + Barometer or Optical Flow + Altitude meter (ToF or ultrasound). I haven't tested the latest version of INAV, but the last time I checked it would not work without a barometer (even if you had another way to measure the altitude). I modified it to work without barometer, but it's untested, you need to compile the firmware by yourself, change config file to match the motors order and, therefore, I would only recomend for very experienced users.

from yamspy.

Thanks for the detailed answer, but just to verify if I understood correct. If angle mode suppose to stabilize the drone, wouldn't it hold its position? (I mean indoor)
John

from yamspy.

Actually, angle mode only works on the XY plane (no altitude control). If your drone is very well balanced, calibrated and trimmed, it should "almost" hold XY position (it will always drift without an extra sensor, but very gently). Have a look at this video to see an example of real world results: https://www.youtube.com/watch?v=rtLaqpN6K-s

If you really want a proper position hold indoors, you will need to change to another firmware like INAV and install an extra sensor like MATEK OPTICAL FLOW & LIDAR SENSOR 3901-L0X. INAV with a GPS can give you the position hold, but outdoors only.

from yamspy.

so if I Set the drone to a constant throttle + the drone is calibrated... so: Angle mode ("constant" X&Y), and constant throttle doesn't equal to "constant Z axis?"
or is it hard to keep the drone calibrated?

from yamspy.

and of course - thanks. I will look into the peripherals that you mentioned and will try to add them.
John

from yamspy.

The problem is the randomness. It's kind of hard to take off in a nice, smooth way. If it's too slow it suffers from ground effect (lots of turbulence), if it's too fast it suffers from overshooting. However, if you start in a place with lots of space, apply a resonable step to the throttle using the simpleUI, everything is calibrated nicelly, the motors are powerful / fast, the battery is fully charged (so no lag) and the PID has the correct values.. it should hold position in angle mode as you mentioned :)

There's a setting (betaflight or inav) that specifies the maximum angle allowed for the angle mode... or something like that.

Calibration should not change if you keep the battery always at the same position. Don't forget that everytime you crash the balance may change.

from yamspy.

wow, these are a lot of "if's..." :). My motivation was to build something stable and small, like Tello but stronger so that's why I thought of a racer.
Do you think it's a low chance?

from yamspy.

Tello has two sensors that allow it to hold its position: optical flow (XY) and time-of-flight (Z). Betaflight doesn't focus in automated flight (besides the GPS based return to home, but I'm not sure how good it is), so even with those sensors it will not change much.
The solution is INAV (or Ardupilot, PX4, but those normally demand a more powerful CPU, more memory, etc). Just remember to check if the flight controller you want to use is compatible with INAV. As I suggested, the Kakute F7 Mini is one interesting option.

I'm currently using INAV, that flight controller with the MATEK OPTICAL FLOW & LIDAR SENSOR 3901-L0X sensor and it works quite well.

Tello is a very nice tiny drone, fairly robust, and I just gave up using it because it's not open source and you need an external computer to control it. Same reason I gave up Mavic Mini.

from yamspy.

Thanks for the detailed answer. BTW, as I understood the Tello has a nice SDK, but did you try to program the mavic mini?
Of course I will check the parts that you mentioned and might build another drone :)
John

from yamspy.

Tello has a Python SDK that allows you to control it from a computer connected to Tello using wifi, but I don't know of anything like that for Mavic Mini.

from yamspy.

Yes... that I know.
So if I may ask, are you happy with the kakute f7 mini? I mean, or you recommend another FC with MATEK Optical flow component,
I am trying to build a small racer that is stronger than tello but to make it stable

from yamspy.

Yes, I'm happy with the Kakute F7 mini. So far so good and I really can't complain, but I don't use the barometer and if you decide to use it I would suggest adding something like a sponge on top to avoid problems with wind blowind directly on it. This flight controller seems to be able to run Ardupilot too, so it makes it an even better investment.

from yamspy.

Thanks Ricardo, I will look into it :)
If I will have additional questions, should I post here? or close this issue?

from yamspy.

You can post here anything that is related to this discussion (it will reopen) or open a new issue if the subject is different.

Good luck with your project!

from yamspy.

Thanks, will keep in touch :)
John

from yamspy.

Today I was testing the drone using simpleUI (angle mode) and I think there's one important detail that may not be clear in the documentation. The way it works is by adding/subtracting values from a main value when you press a key. That is an integrator and it may crazily wind up if you hold down keys. Another possible problem: if the drone drifts to left and you add too much in the roll value by pressing the right key many times without waiting for a reaction, it will overshoot instead of correcting.

from yamspy.

Thanks Ricardo for the input.
I still didn't manage to get my drone to be in angle mode so I tried a work around of fixing some default values of roll,pitch and yaw and when I release a key a command will be sent with the default value. For example, if I increase the pitch from 1000 to 1200 so when I release the key the pitch will be set to a default value (1080 e.g.).
The problem that I tackled with this work around is that a "Release event" may not be supported with curses.
What do you think?
John

from yamspy.

Maybe I should write a new simpleUI example using pygame. Why don't you give it a try?

from yamspy.

I thought about pygame/pynput but I think it will not work with SSH as "key release" events should be captured, or am I missing something?
John

from yamspy.

It seems the only solution is to run the interface on your computer instead of the RPI using socat to tunnel the serial connection ($ sudo apt-get install socat). I've been doing this to connect inav-configurator (but I had to change the version of the chrome engine to an older one because the newer ones would not accept open my serial connection).
On the RPI (-v -x options are just for debug... and my system is using ACM0 instead of TTY0):

$ socat -v -x tcp-l:54321,reuseaddr,fork /dev/ttyACM0,b1000000,cs8,parenb=0,cstopb=0,clocal=0,raw,echo=0,setlk,flock-ex-nb,nonblock=1

On your computer (-v -x options are just for debug):

$ socat -v -x pty,link=$HOME/serial,waitslave tcp:raspberrypi.local:54321

I think the current inav-configurator may work if instead of using $HOME/serial you use something under /dev, but I can't remember if I tried this solution or not.

The port 54321 was chosen without any special reason to do so and, therefore you should check if it's free in case of errors.

Now, I haven't tried to fly the drone using this socat based solution and I have no idea how much lag it will introduce.

Another possibility is to create a python script that runs on the RPI, connects to the flight controller and connects through UDP to your computer instead of socat.

from yamspy.

I didn't know about "socat" so I will read about it, indeed I thought to use Flask/Django to create a webapp with key release events, but udp is also an option. do you think it will be smoother?
John

from yamspy.

I think a webapp it's a great idea since web browsers are everywhere and they are a quite powerful GUI, but I'm not sure if it would be possible to host the webapp (server) in the RPI Zero because you need to make sure the flight controller is receiving commands at 10Hz (minimum!). I've implemented something like that to control a RC car using my phone as joystick, but it was using a RPI 3 that has 4 cores. If you serve the webapp from your computer instead of the RPI Zero, you still could connect everything together using websockets and that may be a little less CPU hungry. Here is one example where I used websockets to interface with ROS.

If you decide to go the UDP way, here is a tiny helper library called UDPHelper and an quite complex example of multiple nodes talking to each other using UDP.

So, in relation to smoothness, I would first try socat (without the -v -x options), then websockets and last resort UDP.

from yamspy.

I thought to explore another option using the rpi gpios. I mean to control them from a remote computer and on the rpi read their values and send msp commands receptively.
For now I closed the cycle without msp commands but only with debug prints to see that release/press key events are detected as expected.
what do you think?
John

from yamspy.

I couldn't understand what you mean by using the gpios. Are you planning to connect something directly to the pins?

from yamspy.

no, with gpizero library to control gpios from remote computer and read them on another script that runs on the raspberry pi so it's a mimic to keyboard... but not via ssh. I hope I explained it right, if not then I will upload a schematic.
John

from yamspy.

Ok, I think I got it. You are planning to use remote gpio:
https://gpiozero.readthedocs.io/en/stable/remote_gpio.html
I'm curious about the results. I would expect to be too much of an overhead, but this library may be optimized and therefore fast. Please, let me know the results because I'm super curious!

from yamspy.

Hi,
As promised I got my drone back and would like to update:

1. control remotely using gpiozero that is being triggered by a remote keyboard worked partially (arm/disarm were tried).
2. Flight modes - The problem was that the drone didn't responded to angle mode - once I've changed the mode to "angle mode" - this was the mode according to Betaflight configurator but the behavior was similar to acro mode.
3. FW - In order to seperate the problem - I've burned Inav FW and saw that the drone maintained angle mode as expected (had to add GPS to test that).

But, still couldn't manage to tune the Drone to position hold accurately. As I think the next step is to dive into the FW and understand what caused the problem.

I would like to ask two questions:

1. As the drone gets smaller, is it harder to tune the PID?
2. which IDE do you use to code inside Betaflight / Inav? if there is a tutorial/youtube channel for startes it will be great :).

Best,
John

from yamspy.

Hi @johncook1212,

I'm curious about the flight modes. The script simpleUI.py needs to be configured according to what was used for the flight controller receiver setup, otherwise it will not switch to the correct modes. I'm considering you double checked that from here :)

Betaflight angle mode should make the drone fairly stable compared to acro mode that mostly follow roll, pitch, yaw you send to it. However, what I mean by stable is if you take off and don't touch anything (even throttle) the drone will drift. Now, how bad it drifts will be directly related to the accelerometer (sticks) calibration, overall weight distribution and motor / propeller behaviour. A wrong or bent propeller may cause havok.

I never had to tune the PID to make any of my drones fly when using Betaflight or iNAV. PID tuning is only really needed if your drone is not standard or when you want to improve dynamic response.

I normally just use VSCode as my IDE. I consider iNAV firmware source code MUCH MUCH easier to read and follow than the latest versions of Betaflight. Therefore, I suggest starting with iNAV. However, playing with the source code is quite dangerous because it may create situations where motors receive full throttle and everything else freezes... been there done that ;)

Cheers,

Ricardo

from yamspy.

Hi @ricardodeazambuja
First, thanks for the prompt reply and sorry it took me two days :/...
Regarding the question on flight modes - I've checked it like this:

1. Drone burned with Betaflight FW + Rpi Zero W mounted on the drone with simpleUI.py running on it. I've connected to the RPi zero W via SSH from my laptop and controlled the drone with SimpleUI.py script. At the laptoop - Betaflight configurator was open parallel to the SSH terminal. When I pressed "m" to replace flight mode - I saw that the mode was changed to angle mode but the behaviour was different. The drone didn't stabilize itself as expected.
2. The same drone (+GPS) with Inav FW - it stabilized itself but didn't hold position well. This is why I am looking into PID tuning for Inav.

I hope it answered the question regarding the flight modes.

Regarding digging into the FW - I've installed VS code + WSL and made a few tutorials and now looking into pid.c and will update...
The drone is small (less than 100gr including battery with 3" props) - do you think is considered as non standard?
If I will bump into a few questions regarding the FW? (some basic abut the IDE etc) can I write in private?
John

from yamspy.

Hi @johncook1212

Ok, Betaflight doesn't really have a position hold mode. If your drone is unstable using Betaflight, I wouldn't bet on PID problems, but on trimming and weight distribution. If the trimming is correct, it should even compensate for weight distribution. However, if you are not careful when fixing the battery to the drone, that difference in the weight distribution could be enough. If you increase gains for the PID I would expect your system to easily become more unstable.

For Inav: are you sure you are using the correct mode for position hold with GPS?
Check here: https://github.com/iNavFlight/inav/wiki/Navigation-modes

There are some parameters accessible from CLI that control the gains for the position controller using GPS.
Have a look here: https://github.com/iNavFlight/inav/blob/master/docs/Settings.md
and search for parameters starting with "nav_mc"

Cheers,
Ricardo

from yamspy.

Hi @ricardodeazambuja

Its interesting, maybe the battery is the issue here and I would re-check the weight distribution. I thought that with Betaflight with known roll,pitch,yaw and thrust values + angle mode for self correction I will be able to hold position of the drone with Betaflight.

I will read the links and re-check with proper battery attachment and update...

Thanks
John

from yamspy.