Newbie (and I mean absolute newbie) question. Can this be used to update a 3dr Solo green cube pixhawk 2.1 quadcopter, currently running 4.0.1?
Thanks,
User096
Is there some danger in using sonar/rangefinder values, overriden by hand and with jumping values when the EK_ALT_SOURCE is set as 0-use Baro? In my new setup i’m using sonar value to give back some custom paremeters through frysky telemetry back to transmitter for my lua scripting. I’m waiting for new frame after crush with v4.0.1 firmware autotune, and i have some doubts if it will be safe.
So there is something else on the vehicle that is publishing distance-sensor messages? Or you’ve someone setup a rangefinder (by changing the RNGFNDx_ parameters) that isn’t really a range finder?
If it’s the former then it should be safe. AP will only consume mavlink distance-sensor messages if RNGFNDx_TYPE = 10:MAVlink.
If it’s the latter then it’s probably not safe because some flight modes like Loiter and AltHold will try and use the rangefinder to maintain an altitude above the terrain.
Copter 4.0.2 testing and success.
We set up a refurbished old Quad X8 with AC 4.0.2 and initial parameters based on the new Tuning Guide and everything is going well on the first flight. Ground-based tests showed no issues. Flight tests in Stabilize, Alt Hold and Loiter have been good without any further tuning yet.
Now we will move onto Autotune and re-examine logs.
Tarot 650 quad frame, Pixhawk, 13"x5.5 RC Timer props, 8 Turnigy 390kv motors, 8 Turnigy red 40amp ESCs (basic PWM), 2 x 3cell 5200mah Lipos in series for 6 cell.
No telemetry or any additional devices fitted at this stage.
2 Likes
Yes, I think so. If Copter-4.0.1 is on the green cube then I think it would be a good idea to upgrade to this new version.
FYI b@Pedals2Paddles.
AC: 4.0.2 Chibios
Frame: Quad Q
FC: Cube Black
Could somebody help me to find the reasons behind quite large difference between ATT.YawDes and ATT.Yaw sometimes ranging 5 degrees both directions - starting at 525.038 seconds.
Video shows camera panning both ways.
Vibrations are <10 on all axis.
thanks in advance
maciek
Configuration is: i have ESP8266 -arduino (it controls the gopro 8 with UDP protocol) and it’s connected to SERIAL4/5 (as 4) , it’s sending/reciving MavLink to Pixhawk. To control sonar/rngfinder, my ESP8266 is overriding the Channel 8, the channel 8 is connected (by wire) to Aux5. Aux5 is configured as rngfinder PWM, and the type of RNGFNDx_TYPE=5 offcourse. So overriding channel 8, gives me my own values to sonar/rngfinder. Sonar is in telemetry passthrough in 0x5004 packet, so in this way on ma lua scipts i have 10bit for use, to see what is the status of gopro. Range finder is configured as looking down to ground, becouse if not, the sonar is not getting any readings from rngfinder.
So crash nr.3 with atun.(with copter 4.x.x) First with 4.0.0, second 4.0.1 ,couple days later i noticed from facebook that there is a bug in autotune.
So i wait for 4.0.2, no probs, installed the new FW today and went for autotutune flights.
First flight i did only yaw&roll. that went ok and i did not noticed anything weird.
Change of battery and takeoff for autotune for Pitch axis.
My RC (herelink) gave notice that autotune complete, so i headed back to takeoff site.
As I approached, i noticed that craft wanted to go right even command was straight ahead, when i managed to get copter near landing site, it was really hard to control and end up crashing again, could be that landing would have been possible, but not for me today anyways…
Dont really know what happen, totally wrong pid´s, that´s for sure, i absolutely have no motivation to look at the logs today…maybe someone with more knowhow with logs be kind enough to take a look 
Great community 
I will attach both flight log´s.
https://drive.google.com/drive/folders/19CnPkqkACp2RA2QNqMHR22-8aHgB7YkO?usp=sharing
Here pids after autotune second flight-
Cube black / frame dji s900 / bat tattu 10000Mah / no gimbal etc.
AC 4.0.2 autotunes worked as expected and produced good results on the Quad X8, almost no other tuning required after following the new guide.
2 Likes
so, no one cares about this bug that is crashing my drones…is this community only for dev´s?
no comments no nothing…weird.
thanks
okay, but that was during autotune? before she flight nice.
Oh I see, sorry! No idea then - nothing jumps out at me. Have you been through the initial tuning guide on the wiki? https://ardupilot.org/copter/docs/tuning-process-instructions.html
i have gone thru that again and again. i just thought that someone is interested that there is same kind of behavior with atun than 4.0.0 - 4.0.1. im gonna do tuning manually again. dont trust this autotuning feature any more, tho its so much better than before, bu thats just me.
Thanks for your reply andy.
Were you flying with the autotuned PIDs? Or did you revert to defaults when the crash happened?
autotuned pids on air, dont remember. its all in the logs. Exactly same behaviour that i had with 4.0.1 autotune…even valueas that came from tune was approx same. useless feature at the moment. I dont recommend to do atun with larger copter at the moment.
The 1st 2 parameters listed in the Tuning Process Instructions are not set…
Okay, so pilot error then. Thanks for your time
Well, maybe it won’t make a big difference it depends on the size of your craft. The guidlines can make a big difference as a starting point for a small craft (say 4-6" props) or a big craft (say 16 and bigger" props). The garden variety 450 frame size can often fly on defaults well enough.