Heewing Ranger VTOL - need help calibrating ESC

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)

1 Like

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.

https://ardupilot.org/plane/docs/common-prearm-safety-checks.html#recognising-which-pre-arm-check-has-failed-using-the-gcs

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.

https://ardupilot.org/plane/docs/common-logs.html#logs

https://ardupilot.org/plane/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html#downloading-and-analyzing-data-logs-in-mission-planner

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.