LibrePilot Forum
Users => Vehicles - MultiRotors => Topic started by: vgwit on October 16, 2018, 11:42:27 am
-
Hi Guys,
Recently at last have got acquainted with GPS modes on my 250mm quad. They works quite well despite my magnetometer rests simply on top of frame. Maximum Position Hold error is about 1m. But last test showed also some troubles. In Velocity Roaming a small pitch oscillation can be seen most of the time. Perhaps, it is normal.
https://drive.google.com/open?id=1Qv9jGNVXFJM-2P0zDNpsQkpaCbPPrgfy
But one of my three tests in Return To Base showed big vibration. Other two were quite fine.
https://drive.google.com/open?id=11PaMqkM4uGwFx8yiolxH22T8BbQn58cJ
Any thoughts are highly appreciated.
-
(From the sound of the pitch_osc.avi it sounds like it does it regardless of compass heading which could be a different issue than I will discuss.) Oscillations like that would usually be caused by PIDs too high. Are you running default PIDs or did you select a specific model template during setup? As mentioned in your other question, I would try AutoTune. :)
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/25657377/AutoTune
As for the RTB oscillation, there is another user here with the exact same problem. In RTB it flies to base OK, but once it gets there it oscillates in the hover. Although he has not yet found a solution, we have found that if you change it so it lands instead of hovers, there is no problem. System->Settings->System->FlightModeSettings->ReturnToBaseNextCommand=Land and press the red up arrow at the top of the screen to save it permanently. Also, that thread has some ideas about changing some of the VtolPathFollower PIDs.
https://forum.librepilot.org/index.php?topic=4431.0
-
Thank you Cliff,
PIDs are default. I'll play with AutoTune next weekend and see.
And yes, after I've changed next step from hover to land quad carried out RTB smoothly several times.
-
Yet another couple of questions not related to subject.
Is it possible to make altitude to be set to zero while arming (it is set to baro)?
Why MWOSD shows ground speed always zero?
Thanks.
-
Is it possible to make altitude to be set to zero while arming (it is set to baro)?
The aLtitude used for flight is a combination of GPS and baro. Basically think of it as GPS aLtitude. Of course there are raw GPS and baro aLtitudes that you can get to in the GCS. I'm not sure what reason you want to do this. There is an option in flight plans that make them relative to Home, and there is an easy way to reset Home each time you fly. Maybe you want it to show zero for FPV display? You might be able to manually set Home by right clicking on the map in GCS (then Set Home Location) and when it asks for aLtitude offset, put in the negative (?positive?) of the measured altitude of that location (easy to determine). @f5soh might help you with other ways that I am not aware of.
Why MWOSD shows ground speed always zero?
You may need to update your OSD firmware. MWOSD firmware should not really need updating to match LP UAVOs though. I recall there is an MWOSD option for LP compatibility. Again, @f5soh might help you with that.
-
Thank you.
Yes, I'd like to see zero altitude on OSD on arming. Even if it is a fusing of Baro and GPS I can't guess why do not simply zero it while arming. As it does not pretend to have any relation to see level.
About speed. Does FC calculates it and sends to OSD or MWOSD firmware should do it ?
-
It depends on whether the GPS is connected to FC or OSD. And you must have it configured correctly and with the correct OSD firmware. With Revo class FC running GPS flight modes you have GPS connected to FC, so it must be set up that way. I don't use OSD very much. @f5soh might be able to help.
-
Thank you.
Have run AutoTune. It's interesting. It defined PIDs about 1.5-3 times bigger than default. Now quad became more responsive while oscillations during descendings almost gone. I like it.
But small pitch oscillation in GPS modes still exist. I'd try to lower pitch PIDs of GPS hold mode. Could you point me to them. Are they VelocityRoamHorizontalVelPID ?
Another thing that bothers me is altitude in OSD. What I see so far right after arming is that its error is about 1-2m in case ny GPS sees more than 11 sats. But in case number of sats is 9-10 altitude error reaches 20m. Why not to just zero it on arming and send to OSD altitude from baro?
And last. MWOSD displays ground speed only 0. Its developer says OSD receives all GPS data fron FC including velocity. Would be good to clarify that. But it is a minor issue.
-
But small pitch oscillation in GPS modes still exist. I'd try to lower pitch PIDs of GPS hold mode. Could you point me to them. Are they VelocityRoamHorizontalVelPID ?
VelocityRoamHorizontalVelPID is for VelocityRoam mode.
There are braking, landing, autotakeoff, and velocityroam mode PIDs that are for those exact flight modes (braking is done in GPSAssist modes I think).
Other GPS modes are supposed to be controlled by HorizontalVelPID. Make sure you adjust the one that affects the flight mode you are working on.
There is also HorizontalPosP.
Another thing that bothers me is altitude in OSD. What I see so far right after arming is that its error is about 1-2m in case ny GPS sees more than 11 sats. But in case number of sats is 9-10 altitude error reaches 20m. Why not to just zero it on arming and send to OSD altitude from baro?
The GPS ALtitude we get from the GPS is inaccurate. For my waypoint flights, I assume that one day to the next it could be as much as 4m difference in ALtitude. Two things you can do to make your GPS as accurate as possible:
- This one makes sure it isn't usually any worse than 4m. Let the vehicle sit and gather satellites for 12 minutes before the first flight of the day and 2 minutes for each flight after the first one. That gets good satellite fix and you won't be adding more satellites in mid flight. The tiny cheap GPSs that don't have memory to store today's almanac between batteries should use 12 minutes before every flight.
- This one can make it much better than 4m. For waypoint flight, make your flight plan relative to home (that is the default), and after 12 minute warm up and with vehicle sitting at exact place you want home location to be (must be the exact same place as when you made this flight plan), clear the Attitude-Settings->HomeLocation->IsSet. Within a few seconds the new Home Location will be set and you can press Save if you want it to be permanent. Now all the waypoint positions (including aLtitude) will be based on the current GPS drifts rather than yesterday's. Warning: you must set Home the exact same place each time if your waypoints are critical, such as if you fly between trees, etc.
And last. MWOSD displays ground speed only 0. Its developer says OSD receives all GPS data from FC including velocity. Would be good to clarify that. But it is a minor issue.
You need to use the correct OSD firmware and configure it correctly. Did you get the OSD firmware from LP wiki? I am not an OSD expert. I only have one and I have it bypassed right now (it was resetting because 12V was less than 12V).
-
About speed. I use latest MWOSD configurator and firmware from
https://github.com/ShikOfTheRa/scarab-osd-gui/tree/master/MW_OSD_GUI/R1.9
The configurator itself chooses correct firmware for LP and micro minimOSD.
-
Do you use 16.09 or Next ?
Did you try the MWOSD from wiki with the same issue ?
-
I use 16.09.
With MWOSD version 1.6.8 from wiki - the same.
-
Ok, found your issue...
If board is not armed, GPS_Speed=0 in MWOSD code:
void displayGPS_speed(void)
{
if(!GPS_fix) return;
if(!armed) GPS_speed=0;
-
It's zero during flight.
-
With 1.6.8, i have GPS Speed displayed :
https://www.youtube.com/watch?v=jFijPiPfRu0
-
Have tried to simulate speed in similar way on latest firmware. 100 m/s results in 3 km/h on OSD.
Will write to developer.
-
I suggest you try the firmware from the LP wiki. Really. :)
-
Download the fixed 16.09 firmware (https://forum.librepilot.org/index.php?topic=2548.msg22710#msg22710) (LP-504+LP-462), rescue, choose the firmware downloaded and flash.
Or even better, move to Next (https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/263913473/Next+Downloads).
Sorry didn't remember this 16.09 issue.
-
Thank you.
Have flashed fixed 16.09 and now speed looks good.
About altitude. I understand baro is more accurate in short timeframe while GPS more accurate in long. So for lengthy flights it is mandatory to have their composition (fusing). But taking off for 5min flight having 9-10 sats I see -21m ground altitude. Is just waiting for more sats the only way to have it more accurate?
Why not subtract it on arming to have zero?
-
Why not subtract it on arming to have zero?
Altitude displayed/used is relative to the Home location and Home location can be set away (not the same altitude) from take off location.
Is just waiting for more sats the only way to have it more accurate?
VDOP give a value related to GPS altitude accuracy which is not directly dependent from the sat number.
If you want to ignore altitude correction by the GPS in long term you can try setting:
RevoSettings > BaroGPSOffsetCorrectionAlpha to 1
Please note 16.09 do not set the initial BaroOffset value (after a filter reset) very precisely so you will expect a difference on altitude displayed, even if Home location and take off are in the same location.
-
Thank you,
will try to set BaroGPSOffsetCorrectionAlpha to 1.
Does LP send DOPs via MSP? I don't see it in MSP bridge.
And last question. Why camera stabilisation does not work with INS13 algorithms?
-
If MSP protocol do not handle DOP, DOP is not sent.
Camera stabilization do not depend on fusion algorithm and works the same since the INS13 is initialized and running.
-
Hi,
have flashed LP16.09_LP504_LP462 to have velocity correct. Now it's fine.
But ReturnToBase behaviour has changed. Now quad does not go straight up to AltitudeOffset but simultaneously does a considerable pitch toward base with acceleration. Then passes base point and still goes further several meters. Do I need to recalibrate sensors after firmware change?
-
There is no need to recalibrate sensors.
The firmware i linked (MSP_speed_fix_16.09 in Firmware tab) is exactly the same as original rel-16.09, with additional fixes for MSPBridge.
You will get the exact same behaviour using the original firmware.
-
...
-
Did you find out the cause of this? I am going to guess that you have VtolPathFollowerSettings Max Horizontal Velocity (or similar name) set very high. Maybe VtolPFS max bank angle set very high. Etc. ? :)
-
Have changed nothing in VtolPathFollowerSettings except HorizontalPosP from 0.25 to 0.15 - 0.3.
Now I'm uncertain about correct HomeLocation at time of those flights. I suspect HomeLocation > Set was set to True with lattitude/longitude/altitude set far away (about 30 km). OSD altitude also says about it because it shows -17m during take off.
But if it'd true then OSD pointed that direction and quad go to that remote location in RTB mode wouldn't it?
https://drive.google.com/open?id=13C91teYoH5thzrMMS0nApx4HhWPUtclv
https://drive.google.com/open?id=1OQl0P85Roy-Wbkj3OmhKlOKiBHg-FeTQ
-
RTB return to the takeoff location
-
I'm slightly messed. From LP user manual
"The Return to Base (RTB) flight mode uses the full range of sensors available on controller to accurately return to the Home Location without any pilot input."
:)
-
"The Return to Base (RTB) flight mode uses the full range of sensors available on controller to accurately return to the Take Off Location without any pilot input." :P
-
Be aware that if Home Location is set say 50km away that GPS map position on GCS will be wrong by say several hundred meters.
For instance, if my Home Location is set to my friend's flying field that is 50km away and I am testing in my back yard, then the GCS map shows me several hundred meters away from my back yard.
RTB still works correctly and returns to where it took off from. It thinks I took off several hundred meters away, and that is where it returns to; which happens to actually be in my back yard.
-
Your description explains somewhat of my quad behaviour during several flight when home location was far away from takeoff. RTB and other GPS modes worked but with considerable horizontal drift (up to 10 meters) in various directions.
I plan to do some more flights at weekend with HomeLocation > Set set to False.
-
I haven't seen any drift or bad flight characteristics that I know for sure were caused by this. Only that the GCS GPS map shows the wrong location. On the other hand, I can't rule it out as I haven't researched it. I also don't fly this way on purpose, so I don't do it often, and I can imagine some worse things if Home is a really long way away, like so far that the curvature of the earth is large.
The only bad things I imagine from 50km away from Home are that you are not flying where telemetry and the map says you are flying, and that if you use the GCS map to click up a waypoint flight then it is really bad because it does not fly where you think it should.
In my experience, most of my GPS drift has been caused by:
- not waiting long enough for GPS to fully "warm up"; up to 13 minutes for first flight of the day and much less for following flights
- GPS shadowing, like flying next to a tall building or in a canyon
- GPS signal reflections, like from a building or metal roof, or even cars
On first flight of the day, GPS downloads an almanac of satellite positions which can take up to 12 minutes after initial satellite signal. Most GPS's (but not the cheapest, smallest GPS's) have the equivalent of a battery that lasts about 6 hours and powers the storage for the almanac. Less than 6 hours between flights and it uses memory almanac, more than 6 hours and it has to download almanac again.
Once you get a good GPS lock, you can fly but if it finds an important satellite that it didn't see before, it will drift when it adds that satellite to it's list. If it has the almanac, it knows where all the satellites are it is less likely to add an important satellite during flight since it already added it from the almanac.
-
Hi,
with HomeLocation > Set set to False altitude on arming now is no more than 1-2m and VelocityRoam works fine.
Did you find out the cause of this? I am going to guess that you have VtolPathFollowerSettings Max Horizontal Velocity (or similar name) set very high. Maybe VtolPFS max bank angle set very high. Etc. ?
I haven't found out the cause but determined that this "strange" RTB is seen in case it is activated from Velocity Roam (probably from any GPS mode). And RTB works correct in case it is activated from Altitude Vario or Rate modes. Here is my today's footage. It contains 4 RTB passes.
https://drive.google.com/open?id=1jiAI4SBINMby_NdnYtsZvq9oqfEcfWan
-
Thanks for the clear documentation of the issue in the video. I don't say it very often, but it looks like you found a bug.
Are you using RC failsafe or FC failsafe?
Do you use PID banks at all? Or do all your flight modes use PID bank #1?
I don't test quad RTB by switching off my transmitter very much, I just make sure that RTB switch position works as it should and that it switches to failsafe when transmitter gets switched off.
Does anyone know if this has been found and fixed in "next"? I don't see anything that looks like it by searching for failsafe or RTB. I suspect that it is an issue with going into failsafe.
-
I've got FS-IA6 radio with FS-iA6b receiver. As I understand my failsafe is RC.
But in my latest test I did not use failsafe. All I did was switch from AVar (Alt Vario) or VeRoam(Velocity Roam) to RTB. So I was able to easy get back from RTB. AUTO RTL on my OSD is not failsafe.
Alt Vario uses bank #3, Velocity Roam - bank #1, RTB - bank #1. And #1 and #3 almost the same.
By the way, in case of smooth/normal RTB behaviour calculation of RTB velocity gives me about 1 m/s while it should be 2 from Settings > FlightModeSettings.
Does transition to "Next" require sensor recalibration?
-
There are ways to get to next without recalibration, but generally, next is a big change from 16.09, so it is recommended that you start over.
Uav files are human readable text files. You can export settings from the old version, update and erase everything, export a default uav file in the new format, carefully find and hand copy all the calibrations from the old file into the new default file, and finally import the modified new file. These calibrations are scattered into several different places inside these files. Sometimes things get renamed.
So much depends on whether you have tweaked a lot or not, whether you plan to copy or redo your input/RC and output, ... PID banks, etc. Basically look at each line in the file, understand what it is, and determine if you want to copy the value to the new file. It doesn't matter whether the order is name then value or value then name.