Can someone please look at my heli 380 log file and let me know how I went with the tune. This is my first electric heli and I tried tuning it last weekend, but conditions were too windy/gusty. I also had the wrong motor pinion installed and had too much rotor droop. Change it to 24t from 21t pinion and all good now.
This logged flight was only a hover in Stab and Loiter modes.
The cyclic feels nice in pitch but roll is slower and not as responsive. What roll param can I increase to fix this?
Nice heli, what type of Autopilot ? could you add more setup pictures ?
had a quick look at your data. check RATE data, desired vs. vehicle rates, for pitch/roll/yaw.
pitch and roll do follow loosely the command, can be better, need to refine. yaw is in worse condition, might be due to the wind condition, you need to make the copter trace better the commands.
check your CG as the pitch have phase response.
Looks like you’re getting double RPM shaking, check tracking.
It is possible to read RPM data from the ESC and use it to have active filter on the accelerometers and gyros, better use it.
Attitude data reviles almost the same.
The tail settings are the stock setting off the Trad heli docs page, so defiantly why it’s worse. I use Mission Planner for log analysis but really struggle with scaling and black background on it. What do you use for log analysis?
The autopilot is a old Pixraptor 2016 model. It seems to be working well so far. I am running an Frsky X8R receiver with the Mavlink and Frsky telemetry being displayed on a Frsky X12S transmitter running the Yaapu lua script.
Underneath the heli, I have a RFDesign 900 radio for tuning and a little extra telemetry linked to my laptop. With a GPS, Autopilot and RC receiver out the back on such a small machine, I had an aft CG problem. So, I mounted a 4S 5200mah pack further forward than normal and had to move the canopy forward as well to fix battery space issue. Sounds like I need to recheck the fwd/aft CG again. Last time I checked it seemed fine.
thanks for the pictures, Yappu telemetry is so great, I took down the redundant direct telemetry, only monitor through the Tx view, and use direct connect to download files and change parameters.
I use mainly MP as i found that QGC lacks some parameters.
Alas, RPM data is not included in the Ardupilot Frsky passthrough telemetry code…
so Alex can not add it.
I looked inside the ardu source code, and had thoughts to add it my self, as this data is very important.
took me long time to understand the logics, parameters and tuning procedure. I do learn new things every day, specially thanks to @bnsgeyer who gracefully help and spread his vast knowledge over traditional heli part
it didn’t froze, he just didn’t apply any command on yaw axis .
@Steve_Mitchell I would set ATC_RAT_PIT_ILMI and ATC_RAT_RLL_ILMI to 0.05 . It will help a lot keeping the heli stable in hover condition (autotrim).
ATC_RAT_RLL_P seems far too high, compared to ATC_RAT_PIT_P.
Can’t we just Y-lead it or use a FrSky RPM sensor and display it through the Lua script? Same as Frsky sensor. The RPM has too much delay when passthrough the Autopilot.
Thanks @Ferrosan for the “ATC_RAT_PIT_ILMI and ATC_RAT_RLL_ILMI to 0.05” for the suggestion. I have tried it and the heli seems to behave better now.
Well… this is possible, but cumbersome, already have RPM readings into the autopilot, adding another sensor using the direct telemetry seems wrong.
regarding the delay, I do not sea any reason to get high rate of RPM update, only need to know that the RPM is correct.
Well if you have an engine failure, it’s very useful to know immediately when it’s happened, not some 3 to 5sec delay. Could also add a voice/sound warning when RPM drops below a set value.
Both modes. At the moment, if there is a engine failure. The autopilot holds or increases collective pitch to try and maintain altitude, killing off rotor RPM = crash. If we can get an early warning, we could enter a autorotation.
In auto modes, there is a start of autorotation function, I do not know the current status, but this is the best solution as the RPM is read by the autopilot. in manual modes, you fly visual, and as you should note failures in non instrumented heli, you can act the same.
on our helicopters (equipped with FPV) I have installed OSD and got rpm streamed to minimOSD or TBS PNP Core. Shortly, in the code I have replaced the “used mah” with rpm data (we do not care about remaining battery, we have voltage/current data and we are flying turbine helis anyway ).
This way is the fastest, so far, to have rpm data as fast as the flight control elaborates it.
Interesting @Ferrosan. I want to get back into FPV with heli’s this time. (Did some FPV fixed wing 19years ago.) I thought of doing a similar thing in the Yappu telemetry and replace “used mah” to RPM.
Yeah Steve, I’m using the DJI fpv and to be honest it is the best add ever to increase situational awareness.
It has unrivalled video quality ,range and reliability (amongst HD systems).
I think @ChrisOlson has something working telemetry-wise to stream RPM through Yaapu.
Only for my custom 3.6 version. I haven’t worked on the 4.x versions yet to get that working with the new WFQ scheduler for FrSky telemetry, although @yaapu does have a PR to put it in 4.1. But also requires making some mods to the Yaapu script, or writing a custom one, to replace the battery stuff with Rrpm. Been working on some other projects with the new heli governor for 4.1, might get around to looking at Rrpm over FrSky for 4.x maybe next week.
@ChrisOlson now that my PR for RPM data on ArduPilo t4.1 is ready for merging, I can create a PR against Helipilot (ArduPilot custom version 4.0.x) so to have the lua side compatible with both ArduPilot and HeliPilot