Do you have the V1 or V2 HEEWING flight controller?
im almost certain its the V2 controller because of an issue with the V1. When I had the original issue several months back, Heewing sent me one of their new FC. When looking in MP messages upon initializing, it showed V2 when it came up. Also, when looking through Painless360 steps to update to transitional firmware then to current firmware, I did not go through those steps because the FC already said V2.
Is there another way to tell?
It also looks like the baud rate for GPS is 230k in messages, correct?
I have also put my param file on here with the settings you sent.
MrPipersnew tune-no working motors.param (25.8 KB)
Iâm afraid my V2 is with a friend so I canât try your params. The GPS baudrate should be 115k, so not sure why its switching to 230k.
You probably should set SCHED_LOOP_RATE,300
but I doubt that is the problem. The parameters look correct as far as I can tell.
I will give it a shot just to see if anything changes. Any other thoughts as to why it would be zero motor output?
Literally baffled. Seems very straightforward. Would there be a big difference between V1 and V2? Especially if everything went through the transitional firmware to the correct firmware.
I also have a Mark F405 vtol bored that I may try. The parameter file that is online for it should be correct, is this right?
V2 is almost identical to V1 - I do not know what the issue would be
I wanted to say thank you guys for your help and input with this. I was never able to get the V2 working. I pulled out a Matek F405 VTOL that I had, got it programmed and got it working. Im sure there is something subtle that I was overlooking, but wasnt able to get it.
I did have a question though, I have attached my param file for eval. I am getting issues with the âPreArm: AHRS not configured for AHRS typeâ. Also, I was able to let it sit for a bit, got it armed, disarmed and then got the internal error spi-xxxxx.
Let me know if there is a setting or work around for this.
Thanks
Wes
Matek F405 VTOL.param (26.5 KB)
The pre-arm check is normal - just wait for GPS lock and the EKF to settle.
The SPI issue is bad, but first suspicion would be the board itself.
Well thatâs not good. That makes sense about the EKF.
What would cause a failure like that?
Something that is interesting I noticed. I continue to get the âPreArm: AHRS not configured for AHRS typeâ. Is there a setting that can "relax"this parameter or is that a bad idea? Itâs a brand new board.
I noticed if I power cycle everything and I am actually able to get past the pre-arm check, the board arms and plane flies very well. Itâs only after I disarm that I notice that error. Seems like that would be firmware, correct?
AHRS: not using configured AHRS type
- EKF3 is not ready yet and vehicle is using DCM If indoors, go outside.
- Ensure good GPS lock. Check for misconfiguration of EKF (see AHRS_EKF_TYPE)
Are you getting good continuous GPS signal? Did the compass calibrations go well? Maybe post a log of the flight and there might be a clue in there.
Hey there, so I wanted to take a second and say THANK YOU to you both for helping with this. I was able to bypass and get plane ARM (not the safest, but it worked). It flew beautifully!!! So happy to see it get off the bench. Nothing crazy, just simple flight, movements, characteristics, etc.
Now to business. In regards to [AHRS_EKF_TYPE, everything I can see matches. Here is my most recent updated param file, slightly updated from earlier. I also put a few more screenshots from the initializing. It will come in and out of being able to arm, once there, everything works fine. BUT, when I disarm, i cannot re-arm the plane. Any thoughts?
Matek F405 VTOL.param (26.5 KB)
Need to see the .bin log file. The parameter file wonât help much. And in the .bin you can see all the parameters anyhow.
And I really need to suggest you turn the arming checks on. If you need to by-pass an arming check thatâs big flag for a problem.
How do I get you the bin file? Will it store on flash memory or does it need SSD? Also, are you able to tell of logging is enabled?
The dataflash logs (.bin) files are stored on the SD card. You can download them using Mission Planner (link below) or remove the SD card and find the directory. Thereâs only a few directories on the card so it will be pretty easy to find. Heads up: The forum wonât let you post a typical .bin file as they are over the file size limit. Youâll need to use a share drive (such as: google drive, dropbox, sync, or whatever else you want to use) and just post the link.
.tlogs are the telemetry log files created by Mission Planner. Donât bother sharing those. For trouble shooting and tuning of the plane they are nearly useless.
I didnât look specifically, but typically logging enabled by default.
If you want to get the plane tuned and running correctly, youâll need log files. What âlooksâ good can be a borderline train wreck waiting to happen.
Thanks @Allister , it finally stopped raining here long enough to get a flight. I have a link to my bin file. I was able to get a sat lock, arm it, then do a qstabilize flight, transition to FBWA then back to qstab. On the same log did a QATUN.
Let me know what you see that may be helpful.
Wes
You have to get the arming checks back to 1.
Set LOG_DISARMED,1, and ARMING_CHECK,1 Take it outside as if you were going to fly. Power it up. Let it get GPS lock. Try to arm it. Maybe give it a couple of minutes and try again. Power it down, and post that log file. Then set LOG_DISARMED back to 0.
The GPS looks like it was struggling to get a really good fix. HDOP was high and Sat count was low. One thing thatâs been suggested here before and you might want to try is GPS_GNSS_MODE to 5 or 65. See if you get a better GPS performance. What that does it focus the GPS on very specific constellations rather than looking for everything. Basically, itâs telling the GPS to not try to everything poorly, just do a few things really well. At best it helps, at worse it does nothing.
Compass was doing okay, but it can be improved. Itâs good enough for now. Once youâre up and flying then you can run MagFit and get it locked in.
In q modes it looked like it was flying well, right from the start. Looks good. You canât evaluate a tune from an autotune flight so that wonât come till itâs flying around after. I suggest you get the other issues sorted first and then get into tuning.
Good infoL. Not raining now so Iâll do it here in about 30 minutes.
So I noticed that I had a pre-arm check of waiting for terrain data. I downloaded from the terrain generator, put it into the terrain file. But does it need to be back in the root of the ARM file and not into TERRAIN?
Either way, I will try it in both and see if that gets rid of it. I definitely want to be able to use terrain enable. Iâll get you some more info here in a moment
It should go into the terrain file. Another way is to just create a mission around your location and load it into the plane. One or two waypoints will be enough. Even if you never plan to fly it, it will load the terrain data for you.
Just thinking you may have got the error as the GPS was dialing in itâs location, in which case you just need to wait for the GPS and EKF to be happy with the home location.
Terrain data is nice, but itâs far from perfect. I think itâs now based on Google data in 30m squares. So if youâre flying in a reasonably flat or rolling area then youâll be fine, but if youâre in the foothills or mountains then you could be in for a surprise.
So I currently have everything in the terrain file. So your thought is that maybe as a pre-arm warning / being unable to arm, was because of the GPS not being able to lock well if Iâm not mistaken, the terrain generator put everything into 90 m and not 30m squares. Does this make a difference? Also, are you able to tell if the terrain spacing is okay?
The GPS took a while to get locked in, thatâs why I suggested adjusting the GPS mode. You will get terrain warnings until the GPS and EKF are satisfied on the home location. Itâs normal.
The 30m/90m is based on what SRTM data set youâre using. It doesnât matter, your call. If youâre in a flat area then the 90m data is fine. Either way, it wonât effect the error youâre seeing as long as youâve loaded a data set for your location.