LibrePilot Forum
Users => Applications - Autonomous Flight => Topic started by: TheOtherCliff on November 23, 2020, 10:55:40 pm
-
Update: 2020-11-27 Relationship to telemetry(/OSD?) Disproven?
The relation to telemetry was proven false in further testing. That implies that the relation to OSD (a form of telemetry) also needs to be retested.
I can recreate this issue (~ 4Hz oscillation in VelocityRoam mode) every time (but only when vehicle is pointed south). I tried both leaving GCS telemetry powered off and completely disabling the quad FC's OpLink and the oscillation still happened.
In relation to oscillations that occur when using OSD-telemetry (https://forum.librepilot.org/index.php?topic=4923.0), I have basically confirmed that it happens with normal telemetry too. It happens with my 16.09 Sparky2 DJI GPS quad when using telemetry in VelocityRoam. Not in Attitude mode. Further testing is needed.
For VelocityRoam (and I presume any similar GPS mode) some setups have "steps" or fast oscillations in stabilization. Instead of quickly becoming level it takes small steps toward level about every 250ms (time is guessed). Strangely, stick response is still immediate, so it acts like it's concept of level is oscillating, but not the stick control response that is relative to that concept.
Years ago I saw the GCS attitude oscillate when the quad was motionless on the ground. Recalibrating the mags seemed to fix that. I want to get all the info I can get before I recal the mags and the problem seems to go away again. The new/old WorldMagModel may even have an issue here. Some of my quads have the new model and some the old. Some of my quads have my DJI GPS oscillation fix (as posted on the forum). Not sure about this quad.
It appears that several similar issues may all have the same cause. This has been seen even before 16.09 and with Ublox GPS. Both the pre-16.09/Ublox-GPS and my 16.09/DJI-GPS have a fast east/west oscillation that can become this fast-stepped-recovery to a slow 4 second oscillation for my 16.09/DJI-GPS and . This quad is tuned fairly tightly with AutoTune with a high max roll rate, so the attitude commands from VelocityRoam have a very quick response. It may be that loosely tuned models would not show the stepping, and only the slow oscillation.
One possible reason that also needs to be explored is that pirouettes (even very slow ones) with this quad, cause a lateral drift that is related to compass heading. When you do a full 360, the drift comes back to the original location. This implies that the GPS antenna has a directional offset? One of the things on my list :slightly_smiling_face: is to add a GPS mount offset so that this pirouette is stationary. This issue raises questions about bank angle though. Does the GPS have a bank angle offset too? That would cause this issue too. I need to rotate the GPS 90 degrees, change aux mag orientation, and see if the oscillation is still east-west or whether it is now north-south. This seems to be caused by bad sensor calibrations (accel and mag) so it's hover position is in the direction of non-level drift with the GPS constantly trying to pull it back. You yaw rotate and the drift is in a different direction but it tries to bring it back to the "Position Hold" location.
Then there are all those unneeded telemetry packets that I found some years ago; remove them all to see if it is congestion related. Maybe try really reducing all the telemetry for a test. It is odd that increasing a telemetry packet rate makes the fast oscillation / steps quicker (in time with telemetry) and thus less of a problem. It would seem that reducing the telemetry packet rate would slow the fast oscillation down and make it worse. Slowing it down should reduce congestion if that is an issue.
Further testing is needed ... to recreate the issue, and to see that it goes away if telemetry is disconnected or disabled entirely. To see if the new WorldMagModel helps. To compare with/without the DJI oscillation fix code that I posted on the forum some time ago (recall though that it happens with Ublox too). To see if reducing the AutoTune PIDs is warranted. To see if a coded GPS mount offset (pirouette drift out and back) is warranted. To see if GPS bank angle affects the GPS location that it gives to us. Note to self: I need to rotate the GPS 90 degrees, change aux mag orientation, and see if the oscillation is still east-west or whether it is now north-south.
I will try to get some logs, examine them for clues, and make videos.
Here is @Trust's recent thread with excellent video of the same problem (watch the video in the first post from 0:18 to 0:30). @Trust complained of the quick oscillation, but you can see that there is the same slow oscillation too.
https://forum.librepilot.org/index.php?topic=4923.0
Here is a video from years ago. The first 10 seconds show the large slow oscillation with steps. The rest of the video is full of recording dropouts and is worthless.
password is oops
https://vimeo.com/189638568
Edit 20201125: Here are some possible reasons and factors I can think of for these oscillations. If you think of one not mentioned, feel free to post about it here:
- See if it goes away if telemetry is just disconnected (coordinator powered off) or if telemetry must be disabled in the model or if just drastically reducing the number/size of packets makes it go away.
- Simple priority issue. Both telemetry and stabilization must be high priority. Loosen the tight 2ms telemetry reply window and reduce the telemetry priority. What does this do to OpLink RC control?
- Examine captured telemetry: See if some of the embedded debug shows signs of a problem:
ActuatorCommand->UpdateTime, MaxUpdateTime, NumFailedUpdates
ActuatorDesired->UpdateTime, NumLongUpdates
CallBackInfo
EKFStateVariance
SystemAlarms
TaskInfo
etc
- Does increasing VtolPathFollower->UpdatePeriod (to more than the telemetry period) have an affect?
- Add debug to watch the starving of stab by telemetry "after the fact" since telemetry is part of the problem
- Try to time the period exactly. That may hint at what it is related to if it is a nice number like 250ms.
- Change the PID tunings and/or vehicle weight to see if the oscillation period changes. If it changes, the problem is not related to a timed process.
The following aren't fixes since it only occurs with telemetry enabled. They are probably only interesting side projects at this point:
Interesting related topics:
- See if the new WorldMagModel helps.
- Compare with/without the DJI GPS oscillation fix code that I posted on the forum some time ago (recall though that it happens with Ublox too). DJI GPS fix code helps the slow oscillation, but not the fast oscillation.
- See if reducing the AutoTune PIDs is warranted. Probably not since user @trust has the issue without using AutoTune to tune PIDs.
- Rotate the GPS mounting say 90 degrees and correct for this in aux mag orientation settings. See if the problem is still an east west oscillation when facing south (north with some vehicles).
- See if a coded GPS mount offset (pirouette drift out and back) is warranted.
- See if GPS bank angle affects the GPS location that it gives to us.
- Imagine what an incorrect WorldMagModel value would do. If magnetic inclination is wrong then there would be 0 or 2 headings that would match. Imagine a cone pointing straight down from the vehicle. The magnetic field should be a line on that cone. If the mag vector falls inside the cone then there are two roll angles that put the vector on the cone.
- Hand code a WMM inclination offset and vary that to see if the oscillation changes.
- Try old EKF settings.
- Oscillation seemed significantly worse at the PCMA field than at the house 35 miles away. Both using the same HomeLocation (at PCMA).
-
It appears that the fast oscillations are caused by bad sensor calibrations (mag and accels) telling it that level is like this (which is wrong), but GPS telling it that it should come back when it drifts off. The result is that it stays half way between sensor level and GPS correct position, getting tugged one way and then the other. I make this educated guess because it fits the facts and then was backed up by the fact that halving the GPS packet rate halved the oscillation frequency. That is, it wasn't a coincidence that the GPS packet rate was exactly the same as the oscillation frequency.
I think that one real test of whether you have bad sensor calibrations is whether your VTOL drifts significantly away when you do a very slow pirouette. My "bad" test drone drifts several meters if I simply yaw it 180 degrees and becomes quite unstable if I try to do pirouettes that are anything faster than very slow. Again, I haven't tried to recalibrate this bad drone till I understand the problem more.
I don't know whether the bad sensor calibrations of the fast oscillation could affect the slow oscillation. I can tell you that with a bad mag calibration and the model sitting motionless on the ground for 5-15 minutes, I have seen the GCS PFD display start (an at least similar) slow oscillation, and ATTI or STAB go from green to yellow or red I forget which.
My slow oscillation recreations are finicky. Some days they are bad and some days I only get fast oscillation.
Long ago I tried changing VtolPathFollower PIDs and didn't get rid of the slow oscillation. I have assumed that there is a tuning piece that I just couldn't find. I found some possible tuning pieces but have not tested at all. The tuning that I found is related to the statements in revosettings.xml so RevoSettings in System -> Settings. Tweaking these could help:
<!-- Low pass filter configuration to calculate offset of barometric altitude sensor.
Defaults: updates at 5 Hz, tau = 300s settle time, exp(-(1/f)/tau) ~= 0.9993335555062
Set BaroGPSOffsetCorrectionAlpha = 1.0 to completely disable baro offset updates. -->
<field name="BaroGPSOffsetCorrectionAlpha" units="" type="float" elements="1" defaultvalue="0.9993335555062"/>
<!-- Coefficient for velocity estimate post processing low pass filter
- filters velocity bias based on delta position to compensate offsets coming from EKF -->
<field name="VelocityPostProcessingLowPassAlpha" units="" type="float" elements="1" defaultvalue="0.999"/>
There is a related piece that may not be part of the cause, but i would like to mention it here. @JDL found that VelocityRoam mode does not have any deadband. Most transmitters do not output the exact same position from one stick release to another, so it was not changing into PositionHold. I think that the worst this meant was that VR mode would drift in the wind if you let sticks centered. This uncovers another issue in that telling VR to fly slowly north when there is a wind from the west would actually have it flying north-east. I haven't seen him post about this in the forum. It is a trivial change if you build your own firmware already.
https://librepilot.atlassian.net/browse/LP-620
-
...
It is a trivial change if you build your own firmware already.
https://librepilot.atlassian.net/browse/LP-620
Regarding LP-620, there is probably a cleaner workaround without need to build new firmware.
Looks like that just setting (in current "next" firmware, probably also in LP16.09) the Assisted Control to GPSAssist for VelocityRoam mode in GCS: FlightModeSwitchSettings tab enables the persisting AssistedControlStickDeadband (default: 8%) in RemoteControlInput tab for VelocityRoam and this would solve the issue with VelocityRoam drift in winds.
Edit: Replaced the image with deadbands, it could mislead to set the Roll/Pitch/Yaw stick deadband to 0, this is not recommended and was only for testing purposes. Leave it to default "2" or raise a little if necessary (depends on your transmitter).
The other deadband, Assisted Control stick deadband is only active for GPSAssist modes. However, if it is smaller than Roll/Pitch/Yaw stick deadband, the larger value from both is used in GPSAssist modes.
-
In the last few test flights on a quad, In VR mode I've noticed if there was any wind more than 5mph, the quad would drift with the wind, yet it is easily compensated if I manually fly it. I'm using a Futaba 9, and it seems to be a very repeatable value when looking at the inputs, so I'm not sure 8% is really needed, but since it only operates in VR mode, probably ok to try the GPSassist with deadband.
-
My recollection is that you can't use GPS-Assist with any GPS flight modes... at least in 16.09. GPS-Assist is to e.g. add a PH to Attitude mode if you release the sticks.
----------------------------
The quad doesn't drift with the wind in true PH mode.
There are two problems there. The fact that it drifts with the wind means that is not actually in PH mode. It should be in PH if the sticks are centered in VR mode. That is what the deadband fix is for.
The other problem is also that it drifts with the wind. Currently, if it is pointed north and I give it forward it flies north. The problem is that if there is a wind out of the west, it also drifts east a bit, kind of like Attitude mode in the wind. It doesn't have to be that way. An enhancement would have it flying straight north, even in wind.
Pointed north, with a wind from the north and a very small forward stick, it will actually fly south. We already see this by the fact that it drifts with the wind with a very small amount of stick to keep it out of PH.
-
My recollection is that you can't use GPS-Assist with any GPS flight modes... at least in 16.09. GPS-Assist is to e.g. add a PH to Attitude mode if you release the sticks.
I've thought the same. However, config tool (in "next") allows to setup GPSAssist for VelocityRoam and Save settings without error/warning message. It seems logical as VelocityRoam IS GPSAssist-ed when sticks are released (it enters Brake, then Hold).
Setting GPSAssist for VelocityRoam just sidesteps a (my suggestion) missing logic in
…\flight\modules\ManualControl\manualcontrol.c static uint8_t isAssistedFlightMode(uint8_t position, uint8_t flightMode, FlightModeSettingsData *modeSettings); that needs correction to always recognize VelocityRoam as assisted flight mode, so the dedicated AssistedControl sticks deadband is applied for VR. I've commented this in LP-620 https://librepilot.atlassian.net/browse/LP-620 (https://librepilot.atlassian.net/browse/LP-620)
I plan to test this in real flight tomorrow...
P.S. I'd also try to set GPSAssist for AutoLand flight mode (in config tool). This should allow position corrections during descent (at least the pop-up hint for the AssistedControl field says so...)
-
I've just returned from my test field :)
CONFIRMED!
Setting GPSAssist in Assisted Control for VelocityRoam flight mode in GCS: FlightModeSwitchSettings tab enables applying the AssistedControl sticks deadband (default 8%) and thus the VelocityRoam does not suffer from drift in winds (enters PH when sticks are centered)!
This might be used as an easy workaround for the VR drift issue until the firmware is fixed. No side effects noticed (not that I'd expected any).
(https://forum.librepilot.org/index.php?action=dlattach;topic=4941.0;attach=8699;image)
Another nice surprise:
Setting GPSAssist in Assisted Control for Land flight mode in GCS: FlightModeSwitchSettings tab allows the pilot to make corrections with sticks during descent, and find the optimal landing spot or just correct position wanderings due to GPS drift.
I've made tests with "next 735" firmware, cannot say if forementioned setting are allowed in LP 16.09 but I suppose so.
-
Ok. Just tested the GPSassist mode in 16.09 on VR mode on my sk450 quad and left the default 8% deadband. Lite west winds - so hard to tell if it was helping the drift issue, but it did seem to be better. In regular STB1 mode, I could hold into the wind with about a -3 degree pitch. Several times while facing west, the craft began the slow east-west oscillation - but this time it kept increasing in amplitude, growing to over ten degrees before I stopped it. If I yawed even 45 degrees - or especially 90 degrees - it stopped oscillating and was quite steady. I did try a little moving around in VR mode and it seemed stable and predictable.
-
Tried this again in somewhat stronger winds (5-10) from the north/nw with some thermal turbulence.
This time the east-west oscillation was there no matter which way I oriented, although more severe if pointed west. It did try to stay in place in the wind - that's good. Moving around in VR mode tended to reduce the oscillation.
I then tried increasing the gyro settings on pitch and roll - from .003 to .006 (and doubling the ID values also).
This didn't affect the normal flight much at all, but did improve the stability when in VR mode. The oscillation was less severe, but still there.
I haven't tried autotune but will see what it comes up with.
-
Ran autotune. It came up with PID value in between my settings on pitch - .00423 P and lower in roll - .00240. Yaw was .01059 - didn't know it could go that high! I thought 0.01 was the limit. ID values were scaled appropriately - roughly I=P*2, D=P*0.02125
Yaw D was slightly less. These make sense in that the camera is in front, counterbalanced by the battery behind, higher mass in pitch, so needs more stabilization.
Manually flown it seemed less "tight" in hover but acceptable. When I flew up and put in VR mode, the same problem appeared - a slow east-west oscillation that increased in amplitude until I stopped it (10s or so).
It seemed worse than with the higher PID values. At least with the high PID values, it did not get out of control.
-
Also, attitude mode outer loop PI values changed slightly with autotune. My original values were P=2.5 and I=0, autotune gave P=3.514, I=0.824
-
I assume that you are talking about the slow oscillation. That is the one that sometimes can get worse and worse so you must finally switch to a different flight mode.
If you are using DJI GPS, there is an issue that happens because the DJI GPS smooths the data (and thus delays it) more than the Ublox GPS. This is the same thing as happens with ESCs using 50Hz PWM... you get oscillation that goes away when you change to 490Hz (or reduce PIDs, but that makes it mushy).
I didn't find a setting equivalent to reducing the PIDs so I wrote a firmware change that tries to unsmooth and speed up the GPS data for DJI. It generally helps a lot but sometimes not perfectly. Are you running that DJI mod firmware?
Later on, I found some RevoSettings settings that might help, but I have not tested them. I described them a while back.
-
Yes, I'm referring to the slow oscillation. Yes, this unit uses the 16.09-dirty firmware with the DJI fix.
Are you referring to these possible fixes?
Long ago I tried changing VtolPathFollower PIDs and didn't get rid of the slow oscillation. I have assumed that there is a tuning piece that I just couldn't find. I found some possible tuning pieces but have not tested at all. The tuning that I found is related to the statements in revosettings.xml so RevoSettings in System -> Settings. Tweaking these could help:
<!-- Low pass filter configuration to calculate offset of barometric altitude sensor.
Defaults: updates at 5 Hz, tau = 300s settle time, exp(-(1/f)/tau) ~= 0.9993335555062
Set BaroGPSOffsetCorrectionAlpha = 1.0 to completely disable baro offset updates. -->
<field name="BaroGPSOffsetCorrectionAlpha" units="" type="float" elements="1" defaultvalue="0.9993335555062"/>
<!-- Coefficient for velocity estimate post processing low pass filter
- filters velocity bias based on delta position to compensate offsets coming from EKF -->
<field name="VelocityPostProcessingLowPassAlpha" units="" type="float" elements="1" defaultvalue="0.999"/>
Both of these are at the default values. How could they be changed and what would the possible effect be?
I see you suggest setting the Baro value to 1 would disable it's effect.
What about the other?
-
I'm looking for alternate GPS/mag units that might have better update rates. How about this?
https://www.ebay.com/itm/UBLOX-NEO-M8N-GPS-Module-Compass-Antenna-Engine-For-Pixhawk4-Flight-Controller/303745218271
-
Yes, those are the settings I was going to experiment with. The comments in the one tell how for that one. I think that 5Hz is the GPS update rate. We are working with a slower GPS, so I would try plugging say 3Hz into that formula to see if it works better.
BaroGPSOffsetCorrectionAlpha = 0.998889506 or other number moving farther in that direction if that helps
and the other number, just experiment with say 0.990 0.900 or 0.9999?
I would initially try this on a known platform like a quad as opposed to an experimental platform.
As I recall, Ublox GPSs are all configurable to higher rates. Maybe some higher than others but M8N's are all the same in that regard. Change the update rate in GpsSettings, but Ublox GPSs don't have the DJI issue unless you misconfigure them (update rate e.g. 5Hz and smoothing e.g. airborne 4G). The default is that they are get configured correctly at each power on. DJI GPSs on the other hand are not configurable. We are stuck with what we have.
-
Well, I decided to try replacing the DJI/naz GPS with a Ublx GPS, and try to use the onboard mag. I had successfully got the OPLINK mini working, so I wouldn't have the cable interference problems I had before.
But when I tried to reload the 16.09 (plain, not dirty) firmware, it now no longer boots. I tried loading the firmware shown in a reference here in the Forum, but it is a 15X version. I can load firmware, but after booting it doesn't communicate via USB.
Where can I get the Revo 16.09 firmware? I hope I didn't somehow brick this FC. I swapped in another one I had and by the time I got most items functioning its too late to finish the calibration I need to do outside.
Also, which mag should I be selecting for the onboard mag type? Its a mini Revo.
-
All firmware is built into the install program / GCS. You can use that DJI dirty firmware for Ublox GPSs. It is just normal firmware for Ublox.
Info: Each UAVO (group of settings like GPSSettings) / version (16.09 or next-###) is unique. You can probably store a full 16.09 configuration and a different full next configuration at the same time on the same FC such that flashing one firmware will run one set and flashing the other firmware will run the other set.
Beware that having an I2C mag plugged in without a flight battery to power it will keep that I2C bus from running. For instance in Sparky2, if you have a mag plugged into I2CPort with only USB power, it won't boot, even with default settings as I recall.
First try booting (USB power) with everything (especially mag) disconnected from the FC. What do the LEDs look like? About a 7 second long blink that repeats? That is watchdog reboot and after about 3 of those it should boot up with default settings. If so, you could Rescue / Erase Settings if your settings are not important.
Second try:
- unplug / no power
- Firmware page press Rescue
- plug it in and wait for it to connect up to a minute
- press Safe Boot, this starts it up with default settings, but without erasing settings
If that works and it comes up, then it looks like you have some settings that are recognized by your current firmware, but that are doing something you don't like. It could be something as simple as having USB telemetry disabled.
If you don't have important settings stored on the FC, just do the Rescue again and do Erase Settings and it should all be fine.
Finally, make sure you don't have something shorted out like pins shorted together in a small FC connector or metal FC mounting hardware or FC touching metal or carbon underneath.
-
It looks like I needed to erase settings. Once I did that, I was able to reboot, reload UAV settings and get it working again.
I always save the settings after every change so I can reload if needed.
Thanks.
-
I was able to get the sk450 quad working with the Ublx GPS and the onboard mag. Atti & stab seems finicky - doesn't show movement. Will ATTI & STAB be red if all the GPS flags aren't there yet? GPS would be green, but these were red. I did some recalibrating, then it worked. Saved after each step. But brought it inside and now after reboot they're red again.
At any rate, tested in a moderate wind. Hovers fine. When I went to VR mode, it shook with the fast oscillation - more so than previously with the other GPS.
Also, I'm holding some tilt to keep it hovering in the wind. When I switch to VR mode it does try to stay in position. But I have to hold some stick tilt to keep it there. I'm using GPSassist so it has deadband - but what happens when you switch to VR mode with the sticks off center?
The mass shouldn't have changed much at all with the different GPS. However the location of the GPS shifted from about 7 inches above the model FC to the same plane as the FC, just about 2 inches laterally.
I may try turning down the gyro settings to soften the fast oscillation.
-
I'm assuming this is a Revo class FC. :)
I was able to get the sk450 quad working with the Ublx GPS and the onboard mag. Atti & stab seems finicky - doesn't show movement. Will ATTI & STAB be red if all the GPS flags aren't there yet? GPS would be green, but these were red. I did some recalibrating, then it worked. Saved after each step. But brought it inside and now after reboot they're red again.
If you are using INS13, then GPS must be green (including 7+ sats), GPS must have less than 3.5 PDOP, and mags must be green (and HomeLocation set) for ATTI & STAB to go green. After that, those sensors could get worse, but atti/stab will still stay green unless some sensors (mag) go really bad.
At any rate, tested in a moderate wind. Hovers fine. When I went to VR mode, it shook with the fast oscillation - more so than previously with the other GPS.
I believe that fast shake is bad sensor calibration. In VR, stationary hover, low wind, hands off no drift, do a slow yaw pirouette. Does it move around a lot? That is another sign pointing to sensor cal issues. Think of it sitting half way between where GPS wants it to be and where accel/mag leveling (unlevel) are trying to drive it. Every time the GPS sends data (4 or 5 times a second depending on GPS and settings) the GPS kicks it back to where it wants it while the bad leveling constantly drives it away.
Recall that transmitter trims should always stay where they were when you did transmitter wizard. You can test by looking at Input -> RC page with Tx on, and compare where Tx currently is vs where Neutrals are.
I do careful board and leveling cals (accels) and careful mag cal, then hover it in Basic (Complementary) Atti and trim for stationary hover (must be zero wind and even so, yaw 180 and test when pointed that way too). Use Attitude -> Settings -> RotateVirtual to get it hovering stationary. Then switch to INS13 with Atti and trim the level with Atti -> Mag -> AuxMagOrientation. This has it hovering motionless in either Basic/Atti or INS13/Atti.
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/18382863/Aux+Mag+Setup+and+Calibration
Heading:Fine Tuning Your Hover To Stop Drift (Not Required)
Next has other GPS flight mode capable AttiEstAlgos besides INS13. There is one which doesn't use mag for leveling. I'm afraid I haven't used this and don't know much more.
Also, I'm holding some tilt to keep it hovering in the wind. When I switch to VR mode it does try to stay in position. But I have to hold some stick tilt to keep it there. I'm using GPSassist so it has deadband - but what happens when you switch to VR mode with the sticks off center?
If sticks are off center enough to get past deadband, then even with sticks helping a tiny amount into the wind it could drift downwind in a strong wind. That is the second VR drift issue I talked about (where? maybe in the Jira?)
JDL says VR with GPSAssist should stay put so I am confused. Maybe that is only true in next not 16.09? Do you build your own GCS? There is a trivial change to add a fixed deadband to VR. My understanding is that with either GPSAssist or with that deadband tweak it might drift a little in the wind (a few meters?) but not keep drifting.
With GPSAssist, hands off the sticks it should stay there. Touch the sticks and it could drift downwind.
The mass shouldn't have changed much at all with the different GPS. However the location of the GPS shifted from about 7 inches above the model FC to the same plane as the FC, just about 2 inches laterally.
Shouldn't make a difference unless moving the GPS puts it too close to metal or magnets.
I may try turning down the gyro settings to soften the fast oscillation.
I don't expect that to help. The full fix is recal board, level, and mags, then redo Basic/Atti trim with RotateVirtual and INS13/Atti trim with AuxMagOrientation.
-
Is this issue fixed with the next revs? It sounds like a different approach was used. I tried cutting the gyro settings in half - it reduced the shaking but didn't eliminate it.
I had to recalibrate the mag again when I went to do the these last tests. Not sure why but it was WAY off before I did the recalibration - despite the fact I used the exact same spot and technique to calibrate. One possible issue is it's sitting on the sidewalk for the calibration - not ground but close to it.
-
Mag calibration continues to gather data during the whole calibration. Not just while the slider is moving each time after you press the button 6 times.
You can't put the drone on the ground or close to the ground or near metal or magnets at any time during the calibration. My laptop even has a strong magnet (attempt at a good speaker?) I can feel when holding metal close. Glad we aren't using floppy disks any more.
You can actually press the button 5 times, then do all 6 positions, then press the button the 6th time.
I actually do a different calibration dance. I know my magnetic inclination is about 60 degrees here in Georgia USA. Think of that being like the north pole looks like it is north, but 60 degrees downward as well. Around the equator the field is generally level. South of the equator, it points upward. But it is a mess. You need to look at the inclination map. I press the button 5 times, then point / wiggle-around each of 6 drone directions (top, bottom, left, right, back, front) of the drone at the north-but-60-degrees-down direction, then press the button for the 6th time.
https://upload.wikimedia.org/wikipedia/commons/d/de/World_Magnetic_Inclination_2015.pdf
This procedure gives a good chance of pointing both directions of each of the 3, 1D sensors built into the magnetometer directly along the magnetic field line while only having a general idea of exactly where north is and where my 60 degrees is.
At the north magnetic pole, the magnetic field is straight down and useless for direction but perfect for "where is down". Above the equator, the north magnetic field points downward at an angle that depends on location. Below the equator, the north magnetic field lines point upward. At the south mag pole the north field points straight up and is again worthless for direction, but perfect for "where is down".
-
Ok. Today is fortunately zero wind, so a good chance to test.
I re ran the mag alignment, this time ensuring that it was well of the ground, and used your 5 clicks, rotate around then 6th click method. It seemed to accept this and stayed green.
When the aircraft is on flat ground, the pitch and roll look correct - the turn/bank indicator looks flat and level.
But when I launch to hover, while craft is pointed west, I need about 10 degrees of roll to keep it level. If I point north, I need some pitch and roll. If I point east - it thinks it is level and hovers almost perfect.
I tried climbing and putting in VR mode while pointed east - it was considerably more stable and not much fast oscillation - a little east-west but not much. But when I tried to yaw, it began to drift badly.
See the enclosed video of this test flight.
I went into the settings and tried changing the auxmag boardrot setting roll to ten degrees & uploading - it had no effect.
I don't think the board level calibrations are off - the position sensors seem correct or close to it. I can't tell if the mag settings are reasonable or not.
I'm also enclosing the UAV settings.
https://youtu.be/MAA5a4lilZk
-
If this is in INS13 / Attitude, it sounds like it is AuxMagOrientation wrong. This must be 0,0,0 (DJI GPS or OP GPS Platinum) unless you use it specifically to tune out this kind of problem or have the aux mag mounted non-standard. Do not try to get the sliders all to 0,0,0 by tweaking the AuxMagOrientation.
For Ublox GPS/mag it should be 0,180,0 or 180,0,180 (these are equivalent rotations. try it. :) ).
-
I decided to try the latest next rev. After a lot of loading GCS versions and firmware into all the devices (FC, OPLINK, OPOSD), then calibrating using the 5 press, swing around 6th press mag calibration, I tested with the generic quad settings in basic mode. Hovered fine and stable. Then I switched to INS13 mode and flew in lite wind (5ish) conditions. I was able to get a lot of sats (16). When I switched to VR mode, it did what I had been hoping for - no fast oscillation, stayed pretty much in place (swayed maybe 1-2 feet). No slow oscillation either.
This am I tried it again. This time I was only able to get 8-9 sats. No wind. But when I switched to VR mode, it moved around a LOT - 10-20 feet. Not very stable. I tried several more times - same results.
I also tried two other modes - complementary+mag+gpsoutdoor & INS13+CF. They both seemed to act identically - still moved around a lot.
Just now (about 4 hours later) I tried again. Now some wind and thermally. At first I only got 9-10 sats, and again, when I switched to VR mode it moved around a lot - 10-20 feet.
Then the 11th sat kicked in. I relaunched and this time it was very solid again. Held position - even with some wind and lite gusts - within 1-2 feet. No oscillations.
I had been watching the PDOP values on the computer and they seemed all under 2.5 even with low sats. Not sure what they were when it went solid.
I understand how the GPS system works - and its not just sats but the area of the sky they radiate from that determines precision.
Is PDOP in meters or dimensionless?
-
*DOP's are dimensionless but can somewhat be tied to distances with formulas you would have to research. Understand that DOP is simply the factor that comes from satellite positions and is the same even for different brands of GPS's at the same location, if they are using the same satellites.
https://www.gps-forums.com/threads/roughtly-converting-dop-to-metric-error.40105/
I don't see anything but coincidence or GPS shielding location (or weather for a poor GPS) in your descriptions of it working good or bad. Clear and cold (low moisture) should be best GPS, but I don't ever worry about that.
Are you between / next to buildings. I fly to within 10 feet or so of my house with 1 or 2 stories blocking GPS without much problem, but metal roofs or buildings or city streets with several stories on both sides can be bad.
I can also generally get GPS lock in the basement with 2 stories above (after a long time like 30 minutes sometimes). Can you get GPS lock even green sometimes anywhere indoors? That would help understand the sensitivity of your GPS and GPS penetration of your house and roof. It appears that the GPS's I use can somewhat see through my house.
Were you flying in the same place each time?
Most GPS's have a super capacitor that acts like a battery to store the GPS almanac for say 6 hours after power off. It's wise (but not required if sat count and PDOP are good) to wait 15 minutes after power on for GPS to download this before first flight of the day. If the GPS has a low sat count and adds or deletes a sat, it can move the calculated position a bit. Some cheap GPS's don't save the almanac this way.
If you don't yaw at all (edit: in Velocity Roam mode), does it stay put? My worst test ship moves a lot if I rotate even less than 90 degrees (in VR). If I do it quickly at 1m high it almost crashes. (I want to keep it this way until I completely understand the issue, and I have been lazy. :) )
-
The poorer GPS results were with a cloudy morning. I can get GPS reception inside in select locations, but generally much poorer.
These last tests were all done in the same location - starting from curbside and hovering above a street. Houses here are single or two story, but there are some tall (60-80') trees (only a few). I try to raise to about 10' at least to try VR mode, and when it's not too gusty, will go up above the treetops (about 60') to test.
I tried again later in the day - again, when I had 10 sats I had very poor stability. At 11 it was much more stable.
This unit has a battery which I suspect saves information.
I don't know if 11 is the magic number for that day/sat positions or if it's this particular GPS Ublx M8.
I did try a yaw test in VR mode when it was stable with 11 sats. It rotated pretty much within a 1m circle - although at the end of 360 degrees rotation it dropped one sat, it was still reasonably stable.
-
You might sit it out at the curb and watch the GPS track wander on the GCS while the aircraft is known to be in one place.
You might play with the GpsSettings -> UbxGnssMode. I recall that GPS location was more stable when using just GPS. Also look at the System page. On the right side, Ublox GPSs will tell you how many are GPS, how many are Glonass, and BeiDou. Perhaps try to correlate good/bad with that?
When Using a Ublox GPS that accepts any of the 3 satellites, I recall that 10 or 11 is a rather low count and may have less than 7 of the USA GPS sats. In the old days, 7 or more of USA GPS satellites was the standard. If you can get 8 or 9 of those with the others turned off, you should wander less?
-
Ok. I'll check those options. Are you referring to settings on the GCS or in Ucenter?
Update on field tests - I set out in a large field yesterday to test. Here too, 10 sats was relatively unstable, but I did eventually get 12, and this seemed fine, with caveats. I noticed when parked 90 degrees to the wind, there was more of a tendency to sway left/right in the direction of the wind (5-10mph). Pointed into the wind it remained quite steady.
I also tested RTB. On returning with RTB, if it was traveling cross to the wind, it would tend to meander as the wind would push it one way, then it would wander back. Into the wind, it was a pretty much straight shot.
Also, once returning over base, it tended to rock quite a bit, especially once it first reached target. The swaying tended to increase, so I stopped it.
I suspect these are at least partially due to the rotational inertia of the craft being higher front/back due to the camera mount on front and long 4000mah battery position to offset. I don't have different roll vs pitch values for these first tests - autotune did a good job of finding the difference.
Last, I made a big mistake in dealing with an issue with the motors. The cheap motors/frame I got on sale from Hobbyking had all the motors with the same thread direction - so one half had a much stronger tendency to "unscrew" than the other. I had lost one already and replaced with a nylock nut.
But in the middle of the last test, one unscrewed, lost a prop, and tumbled to crash - frame pretty toast. It appears all the electronics are ok after some initial tests. Building a frame now in carbon rods and CF laminates. Should be lighter and stronger anyway.
-
Are you referring to settings on the GCS or in Ucenter?
GCS
I noticed when parked 90 degrees to the wind, there was more of a tendency to sway left/right in the direction of the wind (5-10mph). Pointed into the wind it remained quite steady.
Could this also be called a slow oscillation east-west?
On returning with RTB, if it was traveling cross to the wind, it would tend to meander as the wind would push it one way, then it would wander back. Into the wind, it was a pretty much straight shot.
This is at least somewhat to be expected in gusty wind. It should pretty much track straight in constant wind. I suspect that it can be tuned better by doing a full tune: regular PIDs (Autotune) then VtolPF PIDs (HorizontalVelPID?)
Also, once returning over base, it tended to rock quite a bit, especially once it first reached target. The swaying tended to increase, so I stopped it.
This sounds like the slow east-west oscillation. I haven't gotten to the bottom of that, but I intend to try tweaking:
VelocityPostProcessingLowPassAlpha and maybe BaroGPSOffsetCorrectionAlpha
as described previously:
https://forum.librepilot.org/index.php?topic=4941.msg33322#msg33322
https://forum.librepilot.org/index.php?topic=4941.msg33301#msg33301
The cheap motors/frame I got on sale from Hobbyking had all the motors with the same thread direction - so one half had a much stronger tendency to "unscrew" than the other. I had lost one already and replaced with a nylock nut. But in the middle of the last test, one unscrewed, lost a prop, and tumbled to crash - frame pretty toast.
Sorry to hear that. :( As a point of reference, the cheap eBay motors I use only come with "normal thread" prop adapters and although I have stripped out some loose prop adapters, I don't recall a prop coming off in the air. I mostly use the 2212/2830 size motor or one size larger. I would guess that as you suggested, a nylock nut would cure your problems?
-
I managed to build a new frame from 10mm square cf tubing arms (round hole ID -very strong) and two plates of cf/1/8"balsa/cf laminate, sawed off the previous motor mounts and remounted them to the CF tubing. Found a lock nut for the lost prop & replaced prop. Test flights with default gyro settings work fine.
On the swaying -
This doesn't act like the east/west oscillation. It is more random, and seems to be more related to wind direction and the mass of the aircraft. Cross to the wind, I would see some random swaying. Into the wind - very little swaying - pretty stable. Also the RTB when pointed into the wind was quite smooth. Wind was out of the SE.
I'll do an autotune and try with its parameters. Then try modifying the VtolPF PIDs.
-
Well, I tried running autotune. The aircraft seemed to shake much more violently than last time I tried this (although it may have started with a twice as high PID settings). The end result settings were nearly unusable to fly with however. Low PID settings - less than half of what I started with (defaults). I reloaded the defaults.
But now another issue has surfaced. My OPLINK is dropping and reconnecting - connect for a second or two, drop for a second or so, then reconnect. Any ideas how to fix this?
-
The trick with AutoTune is that you must not run it with an unstable set of PIDs. Stock ones usually work OK, but there are quads where that is too high. There is a PID issue that I call a D term oscillation that is so fast that you don't actually see it. Setting D to zero fixes it, but others should then be reduced. Long story.
Bad OpLinks are a known issue. Here is a link. To know if you have the issue, pay attention to the talk about X2 markings. Basically bad works with bad and good works with good, but bad does not work with good. It's hard to define which is bad so the assumption is made that original OP Revo and OpLink are good and the new ones that are incompatible are bad.
https://forum.librepilot.org/index.php?topic=4197.msg28502#msg28502
I suspect that at very least, this issue could be coded around. I don't honestly know if it is a hardware issue or an OP/LP issue. Knowing some things about the way the GUI says that the code defines channels, it may be that we do something that is undefined "at the edge" and one brand of RFM22B handles it one way and another handles it a different way.
It works fine, but regularly drops the link, like at a specific channel. I was not able to tweak the settings (starting and ending channel) to avoid the issue, but that is because the code for instance does not let you use just one channel. If you are running next, you can also see that the frequency is way off (41 kHz). I haven't played with it in a while. A project that I never completed is to allow a Revo to be used as an OpLink so if you have two good Revos, at least you can get telemetry working.
-
I checked the AFC correction - it says 10khz - which seems acceptable. These units were working fine. The only difference is it is warmer today by about 10F.
I tried swapping OPLINK units from another aircraft not in use (but the OPLINK had been working). It had the same problem! At first it seemed fine, then 10s or so it started cycling connect/disconnect. I then noticed if I held the receiver antenna between fingers - it would work!
Probably enough to detune it. I decided to try recalibrating outside. I had to try to hold the antenna while doing this. Which stalled at one point (probably dropped connection) and hung the GCS.
But after a about 15m, and as the temperature outside was cooler, it started working without having to hold it. I was able to do a mag recalibrate and do a short flite test, but it was getting dark so I quit.
Something is temp sensitive.
When I ran autotune before I had higher levels of gyro to start with. I've gone back to these higher levels (P=0.06) on pitch and roll - feels much more connected.
-
You probably already know but there is a connector called RP-SMA (SMA-RP) where they swap the male/female pin parts. With one SMA and one RP-SMA it's possible to put two female pin parts together and not get a connection.
Also, are you sure you are using two 433MHz antennas?
I would also ohm out the coax cable if you are using one.
I recall that with the "bad OpLink" issue, you set the power to min on both sides, then if the two antennas are close (wild guess 1m) you regularly get a big drop in "Rx Level". Move them farther apart (5m?) and you regularly get a disconnect. Flying at higher power you can regularly get a disconnect.
I don't think I recall :) ever seeing a 10kHz deviation between a good pair. Channel width can be 40kHz, so I wouldn't consider 10kHz to be good although there is AFC to handle deviation/drift.
You can't tune (next) a 41kHz deviation out. I actually coded a 41kHz deviation for a test on that set and it didn't help.
-
These units came with antennas, and they are correctly paired connectors.
I assume these are tuned with digital PLLs - can I adjust the PLL manually from the GCS menu or an offset?
Do they frequency hop to find a clear channel? Once acquired do they stay on channel?
It seems odd that BOTH pairs failed with the same deviation (about 10khz).
-
I decided to try a different tactic to fix the OPLINK rcvr. I rolled some pieces of aluminum foil around the rcvr antenna, and slid it up and down until I got consistent solid signal back at the GCS. Short pieces of 2" length seemed to work well - 1" was not enough.
I'm also going to try recutting the antenna lengths a bit shorter to detune and see if that will also work. Simple enough to pull off the black plastic covers.
I also looked at the GPS system display upper right showing the GPS "speed" - proxy for rate of change of GPS position from sat data I presume. When 11 or more sats this stayed well under .1 m/s and was in the .02-.04 range. At 10 or less the numbers would occasionally jump over 0.1 and sometimes .2 or .4.
I also tried GPS Dynamic Model to 4G instead of the 1G it had been set. 4G seemed worse - more meandering. But then sats was 9 or 10, so hard to tell.
I did get one good flight in a moderate, gusty north wind (10ish) that held pretty solid with 12 sats.
-
I assume these are tuned with digital PLLs - can I adjust the PLL manually from the GCS menu or an offset?
Tuning (and reading the frequency deviation) can be done in next, not 16.09. You will have to reflash everything since next is not compatible with 16.09 OpLinks. When receiving, the RFM2x we use uses AFC to lock on to a slightly different frequency transmitter. Tuning shouldn't be necessary, but that is with good OpLinks and good antennas.
Do they frequency hop to find a clear channel? Once acquired do they stay on channel?
They do frequency hop, but they do not detect clear channel. If you know of a particular problem frequency you can adjust the start or end channel number to avoid it. All OpLinks and Revos must be set the same.
Internally the cheap 433 antennas are a coil of wire like a spring with no wire after the coil. If it is not a coil of wire it probably isn't a 433 antenna.
A "store bought" 433 antenna really shouldn't need any tuning.
A thread about 433 antennas:
https://forum.librepilot.org/index.php?topic=4199.msg28510;topicseen#msg28510
-
Thanks for the links. I've built dipoles, crossed dipoles, & yagis before.
I took a broken antenna, which was one of the same that was shipped with these units, and added 6.3cm wire to the end of the coax (that's all that would fit into the tube).
The original gave about -40db with 10' between OPLINKS, parallel orientation.
The replacement was virtually identical -41db.
During the tests the freq shift needed was only 1khz.
These must have a coil in the base - that length is not for 1/4 wave 415Mhz is 17cm.
-
Those coil type antennas are about the worst you can get that is actually a correct antenna. :)
The only case I know of where adding length to a "store bought" antenna actually helps is the old 72MHz RC receivers where the antenna (30") was shorter than a quarter wave (but no ground plane) and more than doubling it gives much longer range.
My advice is that unless you are building the antenna and using a length formula, leave the length as it comes. This is especially true of antennas used on transmitters, where you can burn a "final" just because the impedance isn't right. I wouldn't worry too much about burning a 100mW OpLink/Revo though. I have found a disconnected Revo antenna after flying it several times that way (@ 50mW IIRC). None the worse for wear.
My second advice is to always use a half wave dipole antenna. Quarter wave antennas need a ground plane to work correctly. That antenna article has some info at the end that you might find useful. :)
-
I agree - these are usually pretty bad, and may be why there have been these problems with the OPLINKs. For me I'm mainly using them to set up and calibrate systems, with plans in the future to upload waypoints. SO the short ones are fine. But I think I'll order or make up some dipoles. Its pretty easy to make a dipole from a piece of cable already made up with connector. But it'll end up pretty long - 35cm. Fine for base station but long for the quad.
-
With Retevis 771's at the lowest power setting on both ends, you should expect to easily get a couple hundred meters on the ground. That is how important a good antenna is. :)
Even with the coax sleeve dipole, by the time you have paid for materials, not to speak of tuning equipment, if you consider your time to have value, buying a pair of the best antennas I have found for $13 (shipped) for the pair is the best deal for me. Else: What kind of coax? Is the sleeve diameter large enough? Should I just fold the braid back or use a sleeve? Should the wire be longer than the sleeve (look at the insides of any 2.4GHz antenna)? How to tune? How to make it stiff enough (both connector and antenna) for vertical use on an airplane? Of course you may enjoy making antennas and I can't fault that reason. :)
I always use these Retevis on the ground side. I don't consider quads to be long range, so I usually go with the best shorter antenna I can find on the quad. Airplanes are another matter. I use the Retevis 771 in the air too when flying airplanes.
https://www.ebay.com/itm/2X-SMA-M-VHF-UHF-Antenna-for-Baofeng-UV3R-Retevis-RT3S-YAESU-VX-3R-Two-Way-Radio/362947038362
These are a bit heavy at a little over an ounce IIRC, so if you want to save some seconds of quad flight time, you may want to get a lighter one (like the Nagoya NA-24 at $16) for the aircraft side. If you want the best range, then a full length dipole in my opinion is the only way to go. Truthfully, most of the time we don't need best range and a 771 on the ground at medium-low power with something less in the air at medium-higher power is plenty good enough.
If you simply enjoy making antennas and don't mind buying a pair of Retevis 771's for $13, you might find it interesting to compare range of 2x Retevis vs. Retevis + DIY.
This started out to be a short post... :)
-
It is sometimes fun to make antennas. But I take your point and ordered 2 to compare against 2 other types I've also ordered.
BTW:
Reloaded firmware on all devices, configured next rev on my original Hellaplane V1, calibrated, tested in basic, then tested in INS13 mode - a rare no wind day. Hovered nicely. Was getting up to 14 sats today with the DJI GPS/mag.
Then tried VR mode - oddly, it slowly rotated 180 degrees, then hovered reasonably smoothly - no pitch or roll craziness like before - no oscillations. Don't see any issues with the mag - it is showing the correct direction.
Was able to switch back to stab flying mode, transition to horizontal flight, do a short hop and land successfully.
Still working on building V3, but this was a chance to test systems before I transfer them.
One other oddity - I tried to set GPSassist on the VR mode, but it gave me a config error. It did not do that on the SK450 quad.
Any ideas why?
-
Then tried VR mode - oddly, it slowly rotated 180 degrees
That absolutely should not happen unless it is commanded to do it or the yaw stabilization is completely ineffective. It should be locked in to the compass heading. Yaw trim, zero PIDs, or no yaw stabilization configured (design / mixer) are the explanations I come up with.
One other oddity - I tried to set GPSassist on the VR mode, but it gave me a config error. It did not do that on the SK450 quad.
Any ideas why?
If you are running the same LP version on both, then I would guess that you have Hella* set up as custom mixer/aircraft. The default when you do that is to treat it as fixed wing. I am guessing that fixed wing is not allowed to use GpsAssist since it can't hover / changes heading constantly when loitering.
I ordered another pair of those antennas to test against the ones I have and make sure they are still as good as when I bought them before. It looks like you ordered 2 pairs. :)
-
Yes, because I am using servos to effect yaw on the elevons, I have a custom mixer set. So it apparently switched it to fixedwing.
That's probably why it yawed - it was drifting backwards - so it needed to move to a point behind its position so it yawed the aircraft thinking it needed to point that direction. It didn't really need to but no harm done - in one sense cool as then it always tries to point in whatever direction it's drifting to.
It would be better to have GPSassist on for this VR hover mode. I suppose this takes a separate rebuild of the code to enable.
There's probably a lot of features that "safety" protocols are disabling the feature, unaware that users may try something unusual.
I'm not a fan of that approach. Warnings are better than preventing features.
-
It occurs to me that is exactly what we would want it to do. Since it's normally best in hover to hold the nose pointed into the wind, if the wind drifts the aircraft backwards, the VR mode will turn it to try to point it back into the wind. There is also a vertical tail fin that assists with this. Although if the GPS thinks it's gone too far it'll try to turn back.
Well, anyway on to field testing!
-
I got in 5 flights, almost perfect no wind 67F sunny day. Up to 16 sats.
Most used fixedwing vehicle type, but I also tried VTOL mode.
VR mode for fixedwing does not seem to act the way I expected in VTOL mode - attempting to stay in the position it was when entering VR mode.
Instead, when entering VR mode it seems to lock in the VECTOR the aircraft is heading (in xyz) and tries to stay on that vector - same speed, same direction. If I was slowly climbing/sinking - it would keep on climbing/sinking. If I was flying in horizontal mode in a direction - it would just keep going at that speed and direction. Is there another mode that tries to hold position (position hold)?
In VTOL mode, when starting in hover, it would begin to rock in pitch and accelerate rocking - the Hellaplane is very sensitive in pitch in hover mode - both the motors AND the rear elevons are moving to try to keep it level, which if too extreme starts rotating the wing. And I had the P values set to half of what I normally use. I can adjust these somewhat as the mixer gains for motor pitch and elevon pitch are separate - but the motor gains are at 12, the elevon at 100 - and for transitioning back to hover, I need all the elevon gain I can get - I have to be able to hold the nose up high enough that it will fly backwards - that will transition the wing. I noticed when using the pitch stick elevons did not move as much as when I did yaw, which was also set to 100. The pitch P=0.003.
I would expect in INS13 attitude mode either VTOL or fixedwing in hover - the mix gains and PID values would yield the same results - but they seem to be very different in pitch at least. ?
I later set the roll gains up quite high to eliminate the roll wobble it tends to have in horizontal attitude flight mode. Last flight was quite reasonably smooth.
-
Yes, because I am using servos to effect yaw on the elevons, I have a custom mixer set. So it apparently switched it to fixedwing.
Default is fixed wing. TreatCustomAs is in VtolPfSettings.
That's probably why it yawed - it was drifting backwards - so it needed to move to a point behind its position so it yawed the aircraft thinking it needed to point that direction. It didn't really need to but no harm done - in one sense cool as then it always tries to point in whatever direction it's drifting to.
It shouldn't drift either for the same reason, unless the GPS fix is drifting, and then it doesn't think it is drifting and would still hold the yaw, but we know that VR does drift position. It should never drift yaw.
But there is a setting in VtolPFSettings that says how the yaw responds in some GPS flight modes. One setting says to hold yaw. Another setting is to yaw into whatever direction it is traveling. That second one can be dangerous when GPS fix moves a little this way and that. It constantly yaws large random amounts.
-
It occurs to me that is exactly what we would want it to do. Since it's normally best in hover to hold the nose pointed into the wind, if the wind drifts the aircraft backwards, the VR mode will turn it to try to point it back into the wind.
It shouldn't drift yaw or in VR mode but we know it does and know several fixes. :(
The wind drift would push it downwind, it would think it was flying in that direction, and the nose would turn downwind. Pretty sure this is backwards of what you would want. :(
-
Is there another mode that tries to hold position (position hold)?
PH for VTOL tries to hover motionless. PH for FW tries to constantly try to turn back to the hold point as soon as it passes it. Basically random bowties.
In VTOL mode, when starting in hover, it would begin to rock in pitch and accelerate rocking - the Hellaplane is very sensitive in pitch in hover mode - both the motors AND the rear elevons are moving to try to keep it level, which if too extreme starts rotating the wing. And I had the P values set to half of what I normally use. I can adjust these somewhat as the mixer gains for motor pitch and elevon pitch are separate - but the motor gains are at 12, the elevon at 100 - and for transitioning back to hover, I need all the elevon gain I can get - I have to be able to hold the nose up high enough that it will fly backwards - that will transition the wing. I noticed when using the pitch stick elevons did not move as much as when I did yaw, which was also set to 100. The pitch P=0.003.
Generally speaking, you want the control to physically actuate as much as will ever be needed but not more. Then leave linkages and mixer settings alone from then on and adjust PIDs. Thus you get maximum Manual mode control but not more than reasonable, and PIDs to make that work in stabilized modes.
Often times, the I term is important too if you are not getting enough control. A quad that won't hold pitch at high speed (pitch "blow outs") needs more I term.
I stand by my statement about the rotating wing changing e.g. ailerons controlling yaw in a hover to ailerons controlling roll in forward flight being problematic. Some of the problem can be helped by for instance having a rudder that only is effective in forward flight, and having the rudder and ailerons both connected to the yaw channel or leaving yaw unstabilized and uncontrolled in forward flight (use PID banks to set the yaw PID to zero). Maybe having an aileron function with no prop blast on it so that it is only effective in forward flight. Some of the problem needs to be rethought. With all the control functions on the wing, I don't see how you can have a self levelling mode both with wings vertical and with wings horizontal. All those controls rotate 90 into a different function and for instance hovering aileron left yaw becomes forward flight aileron right roll so what I suggested before would be backwards ailerons hard to fly.
I would expect in INS13 attitude mode either VTOL or fixedwing in hover - the mix gains and PID values would yield the same results - but they seem to be very different in pitch at least. ?
There is no code that does fixed wing hover, only loiter. I suppose that you could think about a normal airplane pointed straight up to be a level hover in Atti mode, but then you have the same problem getting it to fly forward flight.
What you really need is some fancy mixing enhancement if you basically want e.g. ailerons connected to the yaw stick (with Rate stabilization) when hovering and to the roll stick (with Atti stabilization) in forward flight. Add a timed smooth change from one mode to the other and you have an enhancement that is in my notes, that I daydream about, but realistically probably won't get around to.
That enhancement is to allow tail sitter airplanes to be Atti stabilized either horizontally or vertically and for that it also needs to have RotateVirtual be part of the PID banks so you can define one bank to hover horizontally and the other vertically (both in Atti mode. with hover aileron yaw in Rate and forward flight rudder yaw in Rate or Manual).
-
Ok, just so I'm clear - VR and PH are about the same with a VTOL aircraft - trying to stay at holdpoint, but with fixedwing, VR holds a vector and PH tries to fly back to hold point? What are the differences between VR & PH?
My yaw control in Vtolpathfollowersettings is set to manual. There are 5 different modes available - Manual, Tailin, Movementdirection, Pathdirection, and POI. They're mostly self explanatory. I assume POI is point of interest - is that the hold point?
I suppose in horizontal flight since it has a fairly big vertical stabilizer it will generally yaw into whatever direction it's flying anyway, so manual is probably fine. That also explains the yawing it was doing to keep it pointed in the direction it was drifting.
-
Yes, on VTOL, VR can be though of as an adjustable PH and is supposed to be exactly PH (same code) with sticks centered. The recently found deadband issue means that it doesn't usually get into PH and so it can drift with the wind (much slower than the wind).
The only GPS modes I have flown on fixed wing are waypoint and RTB.
I make a guess that VR was not designed to be used with FW. VR code uses things from VtolPfSettings without checking if VTOL or FW. I suspect that for a normal FW, you would have to hold full forward stick (down elevator) to get it to fly forward fast enough to fly. It uses VtolPfSettings horizontal vel as max vel when using full forward so you would need to set that accordingly.
I make a guess that you should look into AutoCruise which seems to be an FW cousin of VTOL VR. Fly in the direction it was pointed when the mode was entered with speed controlled by throttle stick.
VR (again, designed for VTOL) has many siblings that all use the same code. I suspect that POI flight mode is just VR that is relative to the POI like HomeLeash is relative to TakeOffLocation. There is a POILearn setting that is an accessory for selecting the POI. I suspect that you select the POI with the appropriate accessory channel while hovering, then you can use POI mode to fly relative to that or use the VtolPFS YawControl to always point at it. Again, for VTOL.
In horizontal flight, the differential thrust will cause yaw when it sees a roll it doesn't like and that may add or subtract from the rudder. You need code changes or the equivalent REALLY fancy mixers that can reroute e.g. differential thrust when hovering ... to aileron roll when in forward flight.
-
I went out at tested PHold mode along with VR mode in fixedwing again.
This time, PHOLD works as you say - I could take hands off the sticks and it would either fly circles or bowties around the hold point indefinitely, when I started from horizontal flight mode. Nice!
VR mode in fixed wing does not seem to ever want to come back to the hold point. It is more like autocruise - it just stays on whatever vector it's on at the time VR mode is turned on. And moving the controls don't seem to do anything either, unlike VTOL versions.
I did try PHOLD in hover mode, trying to hold it as still as possible before activating. In every case it rolled or pitched too much. If the Hellaplane pitches down and accelerates too much, it will rotate the wing into horizontal mode & go into horizontal flight. Normally if there is too much wind and I want to hover, I'll hold it 90 or 180 to the wind - that will keep it in hover mode. At any rate, once it was in horizontal mode it ran the circles/bowtie flight path around the hold position.
I'm wondering if I can set the limits of pitch (primarily) in PHOLD mode such that it won't have the tendency to rotate the wing. Is there a max pitch setting?
-
First of all is this custom aircraft going to consistently be a VTOL or FW in TreatCustomAs? This boils down to whether this is a long range GPS controlled airplane at the heart of it's purpose.
I did try PHOLD in hover mode, trying to hold it as still as possible before activating. In every case it rolled or pitched too much.
Normally I would say that if it flies OK in Atti but oscillates in PH / VR it sounds like it needs tuning in either VtolPFS or FwPFS, but I know that you are trying to get a compromise working where some actuator results are 90 degrees from where they should be. That alone causes oscillation.
Is there a max pitch setting?
There is not a place that simply says for instance anything more that 50% up elevator stick or stabilization is limited to 50% so that 50% stick is 50% control and 100% stick is still 50% control. There are places to limit it to 50% of throw, but then 50% stick is 25% control and 100% stick is 50% control; a different animal.
I don't think that is the way to tackle this. Servo arm holes, horn holes and mixer settings to allow only the max the airframe will ever need and not more. Then leave that alone and tune. If you ever go back to change the control surface throws, you have to retune. But I don't want to send you to beat your head on a boulder when I don't think you can break the boulder.
I suspect that you have oscillation whether or not you have too much throw.
:'( There may be ways to get something like this to work, but for me to help, it needs to start from technical principles that LP can address. If we had a feature that would make this work (rotating the wing so that e.g. ailerons go from doing yaw to doing roll) (besides mounting the FC on the wing and some other changes, which it seems you reject) I could help. I have a JJRC MO2 (letter oh, not number zero) that has features that you could use; for instance twin motors rotate 90 degrees (like yours) and go from a differential thrust roll actuator (like you have) and differential motor tilt yaw actuator in hover to a differential thrust yaw actuator in forward airplane flight, so it can be done. LP can't do that without someone writing some code. Buying an MO2 won't help you because there is no setup program to configure the other, similar issues.
It is possible to write LP code to make your aircraft work. All you need for this is a super mixer to e.g.
mode 1 (hover):
send roll to differential thrust (mixed with throttle)
send pitch to flaps
send yaw to ailerons
mode 2 (airplane):
send roll to ailerons
send pitch to elevator
send yaw to differential thrust (mixed with throttle) and to rudder
of course you could just mix flaps and ailerons into elevons while you are at it
some of these can be done away with like you can leave the airplane elevator and rudder always active, and you don't really need differential thrust for airplane yaw
In addition, there are some things a modern transmitter can do, like have a switch to move the aileron control from this stick to that stick and reverse it at the same time. If you do that with an LP mode switch, you can do the flying wing setup and have the sticks working the way you want. That is the best way I can see.
What happens if you ignore forward flight, configure and tune it as VTOL, and hover in Atti and VR? You should be able to get that working really well as LP can do all that.
-
Under VtolPathFollowerSettings, there is a MaxRollPitch parameter of 25 degrees. That looks like what I want. If I set it to some small value like 5 degrees, it should limit the ability to try to push nose down and shift into horizontal flight mode when hovering.
Right now I'm just trying to explore what I can do with the existing code, just by modifying parameters.
Normally, we envision take offs are from Hover, so it's a VTOL. Then transition to horizontal flight for the majority of the flight, culminating in a transition back to hover mode prior to landing vertically. In strong winds take off may be vertical but landing is likely horizontal - just at a fairly high AOA.
So most of the time it's a fixed wing aircraft.
However, there are times we may want to loiter. There we would H->V loiter then V->H again. Hovering burns way too much energy though - if there is even the slightest wind you're better off in horizontal wing mode just holding a high AOA and adjusting throttle to hover into the wind - the wings greatly increase efficiency. But here is where it'd be nice to be able to do a PHOLD and just stay in place.
I've considered a number of times the super mixer idea - for that matter, just taking two flight controllers and digitally mix the outputs to accomplish what you're suggesting. Mixing could be blended or just A/B selectable by switch or a switch tied to the wing position. Or use a servo sensor to get a PWM value of the wing position. Of course just coding it would be a cleaner solution.
On the other versions of Hellaplanes with Atom FCs, the flight mode switch is used to select between what I call "aerobatic" mode - pitch/roll/yaw all on rates with somewhat different PID values, and attitude mode which is used for hover and nowadays most of the flight. I have a mixing switch on the transmitter that when on mixes aileron into rudder, so I get more coordinated turns with just aileron. The Hellaplane does awesome tight flat turns with rudder only thanks to differential thrust. The attitude mode is set to max 65 degrees - makes a handy stop when pitching up for landing mode to keep from inadvertently flipping over. One can do some quite fun pirouettes in horizontal wing hover mode. It'll loop easily. It rolls inverted a bit TOO easily - especially versions without tiplets. There's also the dreaded loop done badly - if it stalls inverted, the wings will go vertical, and it falls like a rock - but fortunately as long as it's nose heavy it tends nose down, which then (eventually) rotates the wing back to horizontal mode. We have an impressive video library of "things going nothing like we planned". There is however a clever recovery if you're quick - simply hard roll to either side, which rolls it back to vertical hover mode!
This is another fun aspect of what we're doing. Exploring a whole range of aerobatics and flying maneuvers perhaps not possible with any other aircraft.
What I'm trying to explain by the above examples is that it flies just fine with the controls the way they are - you can fly an entire flight in attitude mode just fine, from V to H and back to V and land. There is a little roll oscillation (like dutch roll) in attitude mode when you overcorrect or hit turbulence - but I've been able to dial this down to near zero. In aerobatic "rate" mode there is none of that - smooth flying especially when using the downlink video monitor - and the turn and bank, altitude, heading etc overlays adds to the ease of aerobatic flying. So I have somewhat of a reluctance to go down a different development path than what works already. Chris' versions have an extra set of servos driving outboard true ailerons on the front wing (or back wing depending on the version). He's also testing with no gyros affecting any of the control surfaces - they are entirely controlled by mixers (an extra Atom FC in manual mode), but he has the motors on a flight control mode switch to switch between attitude mode for hover and rate mode. The goal there is to try to minimize the need for flight controllers as much as possible and built the aircraft itself with more designed built in stability.
As for trying VTOL mode again, I'll try the Maxpitchroll angle first - if that helps enough, then I'll try VTOL mode again. Looks like rain for a while however in the next weeks forecast.
-
Sorry, thought you meant max pitch actuator, like keeping the control surface from moving as much.
Setting max bank angle should work, unless oscillation is a problem.
It might be that a unique aircraft is easy to fly without an FC, but the FC can't be configured to fly it at all without code changes.
The reason I asked whether it was to be a VTOL or FW is that I suspect you will only be able to get it to fly self leveling modes (and thus GPS modes) in either hover or forward flight, not both with the same configuration (without LP code changes or a super mixer).
-
After some moderate rains, we got a short break before the heavy rains come, so I did some testing in 8-12mph wnw winds.
First flight was using fixed wing with the 5 degree maxpitchroll.
Both VR and PHOLD modes acted as before - just more drift in the downwind mode.
Then I switched to VTOL mode.
I set it in hover stab1, 90 degrees to the wind. When I switched to PHOLD, it held position for about 30 seconds, then began to drift downwind. It held altitude, but drifted. I switched back to stab1, pitched down to transition to horizontal mode.
I brought it back, then set up a horizontal wing hover into the wind. This is very nose high - 25-30 degree AOA.
When I switched to VR mode - it retained the hover and stayed reasonably well in place - nose high as in a typical horizontal hover and drifted around the hold position reasonably well.
In the third flight I started in vertical wing hover and set VR mode - here too it held position for a while, but not long - maybe 10 seconds - it rotated into the wind then transitioned to horizontal wing mode - but here then it acted different than fixed wing - the nose pitched up and it went into a horizontal wing hover.
It seems like the maxpitchhold values don't really prevent it from pitching/rolling past the set values - either absolute or relative to the set point values.
At any rate, when aircraft is set to VTOL, as with quads, in VR mode you can roam around - laterally or forward/backward with the control sticks. PHOLD does not seem to allow any position changes.
In the case of the Hellaplane, if its kept 90 or 180 to the wind, it will stay in vertical wing hover in VR or PHOLD mode, but if there's wind and it rotates into the wind, it'll transition into horizontal wing mode - then shift to nose high hover.
Nice!
-
I've been considering my rather big mixer enhancement and I think for your special case, it only needs a small piece of it; a 2nd mixer table that gets used with configurable flight mode switch positions (and some programmer stuff). One FMS position set up for hovering in one mixer where e.g. roll is differential thrust and another FMS position set up for airplane flight in the other mixer where e.g. roll is aileron.
This would be implemented as a mixer table offset. Normally zero in all FMS positions. I am guessing that you have 6 independent output channels, so set the offset to 0 for hover FMS and 6 for airplane FMS.
Forgive me for being pedantic. I would like to remind that the mixer table is output (servo / actuator) configuration. For each "servo" you get a configured amount of roll plus a configured amount of pitch plus ... (where the command can come from transmitter stick position or "FC doing the same thing with code").
I presume you are 100% Windows. Can you do your own builds? I use Linux and don't build Windows GCS. I may be able to do a double cross compile, but I haven't set that up in years.
If you are interested in this then I ask that you get it tuned and flying well independently in both modes. Your mixer table will be completely different for hover than for airplane. E.g. In hover, roll will be connected to differential thrust (+roll for one servo and -roll for the other servo). In airplane mode of course roll will be connected to the ailerons and not differential thrust. E.g. In hover you may choose to have rudder and elevator outputs (servos) enabled in the mixer, but all inputs set to zero (this should hold both to neutral servo regardless of stick positions). In airplane mode rudder and elevator outputs will be active and you may choose to do away with differential thrust or move it to yaw input. Etc.
Do away with any mixes or mods that try to get a compromise between hover and airplane. I assume you have 6 controlled channels. Two independent motors (differential thrust plus throttle), two independent ailerons (elevons), airplane rudder, and airplane elevator. Let me know if you must have more or different than that as that could make or break the mod. At 6+6=12 we will be using all mixers. If you have 4 aileron servos, they should be physically wired to be controlled as 2 servos; left elevon and right elevon.
Have TreatCustomCraftAs set to VTOL. Lock the wing into hover position and get that configured, tuned (PIDs) and flying really well in Attitude mode. It should be doable including hovering at any compass heading relative to the wind. After you get it flying really well, you might try AutoTune (initial PIDs not too high) and see what PIDs that gives and whether it feels better to you.
Save that/those configuration(s) for later reference.
Have TreatCustomCraftAs set to FixedWing. Lock the wing into airplane position and get that configured, tuned (PIDs) and flying really well in Attitude mode. I always start with full Manual mode, then Rate, then finally Attitude. Do not adjust a previous step such as changing control horn throw (Manual) when doing Rate or such as Rate settings when doing Atti. When you e.g. first try Rate, make the mental assumption that you will change right back to Manual. A good Rate tuning rule is set I and D to zero and get P adjusted to mild oscillation, then cut P in half (multiply by 0.45 actually) and then tune I up to oscillation and back off till oscillation is completely gone. Leave D zero.
https://en.wikipedia.org/wiki/PID_controller#Ziegler%E2%80%93Nichols_method
When done, the main things you have are a mixer table and set of PIDs for hover and a very different mixer table and set of PIDs for airplane. Different mixer tables will be handled with this mixer table offset enhancement. Different PIDs will be handled using current "stabilization settings banks" functionality.
Without a way of locking into airplane mode, I don't know if it's reasonable to consider waypoint missions. :(
Let me know if you want to try this, whether you can build a GCS, and what version you want to start from.
Firmware is the same wherever it is built, so I can do that much for sure. This version (GCS and firmware) should be considered incompatible with everything else although most stuff will work. StabilizationSettings is probably where I would put the mixer table offset (one per flight mode) and so it would be incompatible with all other versions.
-
This seems like a good approach - creating a mixer table with two sets selectable by an offset.
Bu today I did some more testing on Hellaplane V1 - testing RTB and Land modes. In VTOL plane mode, if a selected RTB, aircraft seemed to shudder slightly - but then just kept going in whatever direction it was going prior to RTB. Control inputs did nothing. I tried pointing aircraft back towards home, hit RTB - it traveled well past the home position and did not seem to respond to being near home at all.
So I tried fixedwing mode. This seemed to work. The aircraft banked and flew back towards home, then circled around home. I had autoland set - but it never seemed to go into land mode. Whatever altitude I was at when I set RTB - that altitude is what it stayed at flying back to home.
So then I set a separate LAND switch mode in fixed wing. This time when I switched to LAND, the motors cut off completely. I suppose it's meant to then glide in but this seems drastic.
I went back to VTOL mode and tried LAND. Here it was much more reasonable, cutting throttle to achieve a certain sink rate. I didn't actually land to see what happens then.
I know RTB has worked on 16.09 on a VTOL aircraft, but I've never tried it in next. Is there a problem there? I can test it on my quad which is now set up on next.
Shouldn't RTB in VTOL mode pitch and bank back towards home, and keep trying till it heads towards home?
-
RTB acts completely differently for VTOL than for FW. It uses different code for VTOL than for FW.
For VTOL, all it has to do is hold the correct amount of roll and pitch to fly in whatever direction the takeoff location is. When it gets there, it just uses roll and pitch to fine tune the exact location. All this because it is hovering.
For FW, roll and pitch generally stay neutral with occasional tweaks to keep it on track. When it goes past takeoff location it turns back to fly over it again and again.
This is one of the programmer tweaks I mentioned I would do. For it to think it is VTOL in one switch position and FW in the other.
Your aircraft is capable of doing GPS flight modes either hovering or as an airplane. That's one of the issues I was trying to get at. With the stock LibrePilot code it can be configured as VTOL or FW, but not both in one flight. RTB as a VTOL will just hover to home and hover when it gets there. RTB as FW will airplane home and then constantly fly back and forth when there. It shouldn't be expected to fly like an airplane if it is configured as a VTOL.
-
If a switch was assigned to toggle VTOL/FW mode, can this be done in flight and have it change modes?
As a start, this seems like a way I can get both modes usable in any given flight.
-
That is not a current feature. :'(
-
Well, I bit the bullet, cloned a copy of next, installed MSYS2 and all the build files, and ran make package.
It seems to compile most of it, but I get this python error:
File "F:/librepilot/next/make/scripts/version-info.py", line 229
print "path: ", self.path()
^
SyntaxError: invalid syntax
And it won't link the binaries.
?
-
My recollection is that you must use a MINGW[32/64] shell and not an MSYS2 shell to do the builds after installing on Windows.
If that doesn't fix it, I would go back over the parts of installation that have to do with python. It may be missing a python add-on or dependency.
You should be able to run:
python --version
<and>
python F:/librepilot/next/make/scripts/version-info.py --info
cliff@i925 ~/dev/librepilot/1609 $ python --version
Python 2.7.6
cliff@i925 ~/dev/librepilot/1609 $ python make/scripts/version-info.py --info
path: .
origin: ssh://[email protected]/librepilot/librepilot.git
Unix time: 1604888485
commit date: 20201109
hash: cfd288db8f914763f3a4e50060ef5dce1ae102b7
short hash: cfd288db
branch: 1609_cliffs_changes
commit tag:
dirty: yes
label: 16.09+r1-gcfd288d-dirty
revision: 1609_cliffs_changes:cfd288db-dirty 20201109 02:21
-
I did use minw32-make package to do the build.
My python is version 3.8.7
Maybe the make code is using an older version of python? 2.7.6 is a while ago
-
I'm not talking about the version of the make utility that you use, but the shell that the make runs inside of.
As I recall, there is an environment variable...
At the command prompt where you would do the make command to do the build, what does the following command print (capitalization exactly this way)?
echo $MSYSTEM
Then, it's been a long time since I set up a build environment, and never a plain Windows environment, so anyone else that has done so recently, please chime in. :)
I do recall some noise that sounded like "Windows build is broken" a ?year? back. Help?
-
That command gives:
MINGW64
-
What editor do you like to use for working with the source code?
-
Here is a .7z archive copy of my working msys32 (Python 2.7). I'm using it on 64-bit Windows. Unzip it in drive E: !
I've alreday uploaded it once ago but deleted it recently from google drive (space needed). I'll keep this archive there for a week or two.
No success with MINGW64 to build the package, so I'm using MINGW32.
https://drive.google.com/file/d/1LRey8WiC4oizbZj3w0PkAxM6002Hs948/view?usp=sharing (https://drive.google.com/file/d/1LRey8WiC4oizbZj3w0PkAxM6002Hs948/view?usp=sharing)
-
What editor do you like to use for working with the source code?
Notepad++ ;)
-
I tried fiddling with the python code that was causing the error. It seems to choke on the print statement as invalid syntax - but I don't see anything wrong with it. Indenting seems ok.
Any ideas how to fix?
I'm downloading your files. I'll have to make a partition for e:
How big its it after decompressing?
-
Now that you mention it, I also recall to avoid MINGW64 and use MINGW32. 32 is what I have installed on 64 bit Linux.
I also remember needing to use the MINGW image rather than the install program. That may be a Linux thing.
This is all on the order of 5 years ago.
-
Well, I fixed one of the problems.
In python 3, print statements are functions so must have arguments inside () - I edited that in so those errors went away.
Now I get this error:
Traceback (most recent call last):
File "F:/librepilot/next/make/scripts/version-info.py", line 540, in <module>
sys.exit(main())
File "F:/librepilot/next/make/scripts/version-info.py", line 481, in main
r = Repo(args.path)
File "F:/librepilot/next/make/scripts/version-info.py", line 124, in __init__
self._hash = self._out.strip(' \t\n\r')
TypeError: a bytes-like object is required, not 'str'
mingw32-make: *** [F:/librepilot/next/flight/Makefile:265: flight_uavobjects] Error 127
Any ideas?
-
My first thought, rather than fixing python version issues when you see them and wondering about issues you might not see ... is to try to get a Python 2 version installed.
I kind of recall both 2 and 3 being available for just this reason?
Sounds like we need a Jira/tracking created to convert to python3. Maybe part of getting build working with current tools and on current OS's?
-
.... I'll have to make a partition for e:
How big its it after decompressing?
15.4GB / 15.7GB on disk. Librepilot files not included. If counting them - 17.9GB.
-
Ok. I decompressed the files onto a USB disk E:
I run ming32, it opens a window.
I move to the directory f:/librepilot/next - where the code sits
I run
mingw32-make package
I get the following error:
mingw32-make: *** [F:/librepilot/next/flight/Makefile:265: flight_uavobjects] Error 127
Are there environment varbs I need to set, or does make set them?
I assumed you already built the tool chain in this or do I need to rebuild it?
If I run python --version I get 2.7.16
-
127 is usually "file not found".
A few things:
No spaces in install directories. It looks like you installed the source in librepilot/next and it probably isn't an issue, but there are problems with installing tools? source? what? in directories that have spaces in the name?
what does this command output?
echo $MSYSTEM
I recall issues with MSYS64 bit?
I know that Windows uses \ and Linux uses /. I see that the file name of the error uses /. I don't know if that is an issue or if showing / is normal for Windows builds.
Do you have permission to write in that directory? Maybe it doesn't belong to you (use chown or chmod ... with -R ? or Windows utility to change owner of everything)
Are you out of space on the disk?
Are you sure this is the first error? Always fix the first error first.
Good luck.
-
...
I run ming32, it opens a window.
I move to the directory f:/librepilot/next - where the code sits
...
Librepilot files are expected to be in
E:\msys32\home\karat\librepilot
Of course, replace "karat" with your username.
mingw32 should be started from E:\msys32\mingw32.exe
Edit: Incorrect, sorry for that!
-
Trying to understand the setup to maybe get it working under Linux Wine. I haven't actually unpacked it. :) I wonder how long it would take me to document a fresh Linux setup and make build / source fixes to get it working.
Librepilot files are expected to be in
E:\msys32\home\karat\librepilot
Of course, replace "karat" with your username.
I don't understand ??? why that would be needed unless you tweaked it to get it to work, and this is a tweak requirement? git / LP source usually works anywhere, at least in Linux. Then again, a Linux system does look like a single tree and doesn't have the multiple tree concept of Windows drive letters...
mingw32 should be started from E:\msys32\mingw32.exe
More tweaks that require this or just that you have tested it that way, and other ways are untested?
-
... or just that you have tested it that way, and other ways are untested?
Exactly right. This is how it used to work for me.
I had once moved the whole msys32 folder to different drive letter and had issues...
However, seems that my previous post is misleading, sorry for that! :(
I've just moved the librepilot files/folder from E:\msys32\home\karat\librepilot to E:\librepilot and successfully built the package at the new location!
-
echo $MSYSTEM
outputs
MINGW32
When I first ran mingw32-make package with this version on e:, it took a fair amount of time to output anything - I assume it was actually compiling. I looked through the build directory - under firmware, fw_coptercontrol has .o and .lst files I assume from the compile on 2/2. dep directory is empty
uavobjects has source code but no .o files
under build/uavobjgenerator/release there are .o files
There is nothing in the gcs-synthetics or librepilot-gcs_release directories
I tried moving all the code to the e: drive and ran mingw32-make package - same error
Yes, it is the first error.
It is a 128Gbyte USB drive - there is 100Gbyte free space
-
I didn't get an answer to this - do I need to run
mingw32-make all_sdk_install
again?
-
I would try smaller pieces, hoping to narrow down what builds and what doesn't. That should help determine if any sdks need to be installed.
this will erase all the built stuff so you can start over
mingw32-make clean
make just the revo firmware using 4 cpu cores (threads/jobs)
mingw32-make -j4 revolution
make just the gcs
mingw32-make -j4 gcs
that is enough to use gcs and revo firmware
with some small caveats like upgrade buttons are grayed out so you need to do halt and then flash the firmware
-------------
for reference
this will erase just the revo firmware
mingw32-make revolution_clean
this will erase just the gcs
mingw32-make gcs_clean
---------------------
On a system already set up and building correctly, you almost never need to clean. But your system isn't working perfectly yet...
-
Ok! Progress.
It appears to have compiled and generated the fw-coptercontrol.bin & .elf files successfully.
It also generated the gcs. When I run it, I get the following error message:
E:/librepilot/next/build/librepilot-gcs_release/lib/librepilot-gcs/plugins/LibrePilot/PfdQml.dll: Cannot load library E:\librepilot\next\build\librepilot-gcs_release\lib\librepilot-gcs\plugins\LibrePilot\PfdQml.dll: The specified procedure could not be found.
Pressed ok, then looked at the GUI.
Most everything looks normal (have not tried connecting to a FC yet).
On the Flight data tab, the upper left panel allows setting gadgets - I have never played with this before - there was always a default display there. Now I see that ALL my GCS versions display what is set there! (I have both 16.09 and next set up on my computer). How do I get back the default "gadget"?
Anyway, much progress! Thanks!
-
Not sure where to mention this - but on the next GCS version I'm using (not my code build), importing UAV files does not seem to load mixer settings. I checked the UAV file - the settings are there. But they never load. 16.09 seems to load ok. Only next. I can export, but not import.
?
-
It also generated the gcs. When I run it, I get the following error message:
E:/librepilot/next/build/librepilot-gcs_release/lib/librepilot-gcs/plugins/LibrePilot/PfdQml.dll: Cannot load library E:\librepilot\next\build\librepilot-gcs_release\lib\librepilot-gcs\plugins\LibrePilot\PfdQml.dll: The specified procedure could not be found.
3D OSGEarth PFD
I recall that you must either disable this, or you must do a special download or build and tell it to use that.
I recall there is an issue building the 3D OSGEarth PFD. It has to do with versions of the things it depends on which you may have worked around by using @jdl's msys stuff.
This command will show you some options how to handle this. Handling it involves storing your request in a file called "config" (you will use use mingw32-make):
make config_help
I would either disable all OSG stuff as described in config_help or I would use the instructions at:
make/3rdparty/osgearth/README.TXT
to build these libs and to tell the build to make a GCS that uses them.
I recall there is a way to download pre-built libs, but am not familiar with that way.
There is also a way to hack Makefile that has to do with these lines:
GCS_WITH_OSG := 1
GCS_WITH_OSGEARTH := 1
GCS_COPY_OSG := 1
On the Flight data tab, the upper left panel allows setting gadgets - I have never played with this before - there was always a default display there. Now I see that ALL my GCS versions display what is set there! (I have both 16.09 and next set up on my computer).
Running the GCS with the -help option shows you the possible command line options:
$ ./build/librepilot-gcs_release/bin/librepilot-gcs -help
Command line ("./build/librepilot-gcs_release/bin/librepilot-gcs", "-help")
Loading system settings from "/home/cliff/dev/librepilot/1609/build/librepilot-gcs_release/share/librepilot-gcs/"
Loading user settings from "/home/cliff/.config/LibrePilot/LibrePilot GCS.xml"
main - system locale: "en_US"
main - GCS locale: "en_US"
main - language: "en_US"
Usage: librepilot-gcs [OPTION]... [FILE]...
Options:
-help Display this help
-version Display application version
-no-splash Don't display splash screen
-log <file> Log to specified file
-client Attempt to connect to already running instance
-D <key>=<value> Permanently set a user setting, e.g: -D General/OverrideLanguage=de
-reset Reset user settings to factory defaults.
-config-file <file> Specify alternate factory defaults settings file (used with -reset)
-exit-after-config Exit after manipulating configuration settings
-noload <plugin> Do not load <plugin>
How do I get back the default "gadget"?
Use the -reset option to reset the GCS to defaults. If you want to use multiple versions of GCS on the same PC, you will have to supply some glue code to move the settings files around.
Not sure where to mention this - but on the next GCS version I'm using (not my code build), importing UAV files does not seem to load mixer settings. I checked the UAV file - the settings are there. But they never load. 16.09 seems to load ok. Only next. I can export, but not import.
UAV files are version specific in that if the firmware version does not match exactly, then there are things that don't import because the UAVO hash number is different, because the UAVO is different. The bigger the changes from one version to the next, the more things don't import.
The simple way is to just make screen shots of the source version and hand input them in the destination version.
There is another way, but it is technical. The .uav files are human readable text and so you can use diff tools to compare them. If you compare e.g. the erase settings default revo exports for 16.09 and next, you will see the differences. I use two editors at once so I can Alt-Tab from one to the other. When both are on the same page, you can use this "blink test" to make the differences pop out. Then in a 3rd editor, you make the changes that you see when blinking between the two default files. A uav file does not have to have all the lines in it. I often make uav files that have just the calibrations in it. There are a LOT of differences between 16.09 and the last next.
-
I'll try the PFD makefile options.
I used the -reset and reset it.
On the importing, the UAV file was exported from the same version of next I'm importing into. So it should be the same format, correct?
And it should import I would think.
-
I looked at Makefile - it already has the flags set, provided it determines the OS used:
...
else ifeq ($(UNAME), Windows)
UAVOBJGENERATOR := $(BUILD_DIR)/uavobjgenerator/uavobjgenerator.exe
GCS_WITH_OSG := 1
GCS_WITH_OSGEARTH := 1
GCS_COPY_OSG := 1
GCS_WITH_GSTREAMER := 1
GCS_COPY_GSTREAMER := 1
endif
Is $(UNAME) predefined somewhere?
-
On the importing UAV in next issue, I noticed something odd - the system listing has the correct imported values after importing, but the config custom page does not show them at all, and all are disabled. Also this means the output page has everything off.
If I manually enable the relevant channels and set mixer values, then save, it is correctly saved to FC. This also then seems to enable the output page and its data, such that I can then save it to the FC.
-
I looked at Makefile - it already has the flags set, provided it determines the OS used:
...
else ifeq ($(UNAME), Windows)
UAVOBJGENERATOR := $(BUILD_DIR)/uavobjgenerator/uavobjgenerator.exe
GCS_WITH_OSG := 1
GCS_WITH_OSGEARTH := 1
GCS_COPY_OSG := 1
GCS_WITH_GSTREAMER := 1
GCS_COPY_GSTREAMER := 1
endif
Is $(UNAME) predefined somewhere?
The idea is that you may need to turn it off...
On the importing, the UAV file was exported from the same version of next I'm importing into. So it should be the same format, correct?
And it should import I would think.
The only way import export works perfectly is if the same version is on GCS and firmware during export and that same version is still on GCS and firmware during import.
On the importing UAV in next issue, I noticed something odd - the system listing has the correct imported values after importing, but the config custom page does not show them at all, and all are disabled. Also this means the output page has everything off.
If I manually enable the relevant channels and set mixer values, then save, it is correctly saved to FC. This also then seems to enable the output page and its data, such that I can then save it to the FC.
There is probably some other setting that is not coming across because of a version mismatch?
-
Just to be clear - that is what I am doing. I export a UAV file from the latest version of next with GCS. I then load the same firmware onto a new mini REVO FC that has been upgraded and erased. I then try to import with the SAME version and GCS.
Trying a recompile now on the other issue.
-
I did a clean to delete previous version.
I edited the Makefile to set three values to 0 instead of 1
Ran the firmware compile - seems to have been successful
Tried to run the gcs compile and I get this:
mingw32-make[1]: Entering directory 'E:/librepilot/next/build/librepilot-gcs_release'
mingw32-make[1]: *** No rule to make target '.qmake.cache', needed by 'Makefile'. Stop.
mingw32-make[1]: Leaving directory 'E:/librepilot/next/build/librepilot-gcs_release'
mingw32-make: *** [Makefile:308: gcs] Error 2
I went back to square one. Deleted all the next files. Copied files from source.
Edited makefile to set three parms to 0.
Ran clean, make firmware, and make gcs.
This time, when I run the gcs, I get the default version with PFD in Flight data tab.
Success.