Can you simply try a servo tester plugged into one of these tilt servos?
Not really. I soldered the wires instead of using connectors. However I can do the same thing by setting servo1 to aileron. When I do that, I get full deflection, so the servo is working fine. Something in my parameters isnât set correctly. I just donât know which one.
Ok, good test. Can you save your .param file from Mission Planner and post it?
Itâs all good. Apparently some of the changes I made needed a reboot to take effect. Upon power up this morning, all is working as it should.
Sorry for the spam.
Thanks for the help,
Dave
Hi,
Iâm having problems with tuning my freeman 2300 in px4 environment. Has anyone done this before? And could share the parameters?
Thank you.
If youâre using the PX4 Pro firmware, might I suggest you put in your issue in the PX4 Forum. Out of curiosity, what airframe did you choose during the initial setup?
Good luck.
Thank you,
I created new init and mixer files for freeman.
Hey Guys,
My Freedom build is complete. I am setting parameters and adjusting control surfaces. I am wondering about engine tilt. Right now, I have the forward engines tilting until they are horizontal, in line with the top surface of the engine mount arms. This seems to be the right configuration if the airplane flies at 0 degrees AoA (angle of attack). I am guessing the airplane flies at a positive AoA and think I might need to limit the range of motion of the tilt servos to something less than horizontal.
What did you guys do?
Thanks,
Dave
Hi,
We, attempted first transition today. Realized there is a lot of vibration on our vehicle. Here is the logs link:
https://review.px4.io/plot_app?log=033f23ad-cc81-4335-92d4-5a054442fc07
Inspected the vehicle and couldnât find any loose part. We started thinking maybe it is the vehicle design itself. So how is your vibrations? Can you share?
By the way, we give a little angle of attack to the motors in FW mode, since the orginal believer design was driven by so.
Thanks in advance.
Ozan,
The plan is to do our first hover test tomorrow. We plan to start in Q Stabilize then go to Q Hover and finally Q Loiter. If each mode tests ok, we weâll put it in Q Tune on all axis.
Got to say I am a bit anxious. I have a lot of time in this build.
Iâll let you know how it goesâŚ
Dave
Hi David,
I think youâll find that how you have it now will work just fine. Here are some example images of the normal Believer AoA. If you feel the need to change the trim after several flights, refer to the WiKi section below. Good luck!
1 Like
Good luck 
Iâm sure it will be great.
Looking forward to hearing from you.
Thanks,
Well it started out well, but ended in a disaster.
Took off in Q Stablize, flew around for a few minutes then switched to qhover. Flew fine in both modes. Switched to qloiter. The drone was very stable and responded well to pilot input. Decided to do a qtune. During the qtune, the battery voltage steadily declined to 21v. I had batt failsafe enabled at 21v and the drone responded by starting toward home. Around 5ft above the ground the nose of airplane abruptly pitched down and the drone crashed. Even from 5ft the foam couldnât contain the battery, which came through the nose of the airplane. The drone is a loss. Fortunately, I can salvage all of the electronics and ordered two kits.
At the crash site, I thought one of two things caused the plane to crash: brown out or battery voltage sag. I am not seeing indications of either in the logs. I am using a Mauch PL V3 BEC⌠it provided very impressive regulated power to the pixhawk. None of my servos or RFD900 are powered from the Pixhawk.
Nor did I see a drop in battery voltage.
The vibes werenât excesvie, maxing out around 15.
A little bit after 16:02 in the linked log, youâll notice motor_emergency_stopped. I donât know what caused this. It wasnât commanded. I do have an emergency stop enabled but itâs a rotary switch on my Taranis and wasnât activated as indicated by RC3OUT.
My current hypothesis is the drone thought it was on the ground and cut the engines. Is that possible?
Any help diagnosing the problem is greatly appreciated.
BIN file linked below.
Thanks,
Dave
I am going to suggest that the ESCâs picked up the voltage was too low (high current draw on final stages of landing) and cut the power.
Hey Luke,
Thanks for sharing your thoughts. What data are you using to reach that conclusion?
The logs show the min voltage at 21v and the current drops considerably, from 100 amps to 50 amps, once the failsafe is triggered and the drone transitions to QLand.
ESCs are rated at 60 AMPs and the Mauch Power Sensor is rated at 200 amp,
See attached image.
Dave
Certain ESC have their own emergency cutoff when they sense that the voltage is too low. This is from the manual of a Hobbywing one:
We have seen this come into play on the bench when running a very low Li-Ion battery and then demanding throttle. With voltage sag, this can be enough to trigger the ESC to cut off.
Im not saying this is the reason for your hard landing. I have not analysed the logs and donât think I am qualified to make any comments regarding that. Just that The ESC work independently from the autopilot sometimes and have their own way of handling low voltage spikes.
Sadly, it was a lot more than a hard landing⌠the drone is destroyed.
Thanks for the heads up on the ESCs. I donât think that is what happend. The battery never got below 20v, so even at the highest setting the esc should not have shut down.
dave
Hi,
Really sorry that happened. I donât think voltage or generally power is the problem. I run mine at voltages around 20V no problem. Also, it canât activate the âlanding detectedâ in the air, I think thats impossible. Can you check in your parameters âBATT_FS_LOW_ACTâ if it has a value â5â Which is a terminate command may caused your problem. You can check the link: https://ardupilot.org/copter/docs/failsafe-battery.html
Hi David,
Sorry for your crash. You and I have totally different philosophies when it comes to testing new aircraft or VTOLS. I will typically turn off all the alarms and automatic stuff so that I am in control. This comes from experience. By simplifying things, I believe that less than go wrong. Would you rather destroy just a battery pack or the entire plane? I also have never used any AUTOTUNE or QAUTOTUNE feature.
That being said, your initial problems started when trying to exit QAUTOTUNE mode and you had a critical battery alarm of 20.96v. Yes, this is below your BATT_CRT_VOLT setting of 21.0v.
When changing from QAUTOTUNE to QLAND, I do not see any change on the mode switch of Ch. 5. Was this done via another switch setting or the BATT_FS_CRT_ACT set to 4?
It does appear that Ch. 3 creeped up to (1900) to activate the MOTORS_EMERGENCY_STOPPED feature of Option 31. I would not recommend using this feature.
Some food for thought on your next VTOL maiden flight. Disable all the failsafes, test the copter modes first. They may perform fine using the default parameters or at least good enough to move onto a forward flight transition. Use your transmitter timer to set a hover/flight time that only uses about 50% charge. I often use two packs when testing and then change the transmitter timer based upon the charge left in the pack. These 10AH+ packs can fly for a long time!
Good luck on your repairs!
2 Likes
Greg,
Thanks for taking the time to review the log and for sharing your analysis and thoughts.
Funny you start out with our testing philosophies are completely different. I adopted the order in which I test Q modes from you, otherwise I probably would always start in qloiter. And I normally donât set a battery failsafes.
I do autotunes because I donât understand PIDs well enough to tune the drone myself.
The qland mode was not commanded but was triggered by the BATT_FS_CRT_ACT to 4. I also had q_options set to 32, use QRTL instead of qland. Not sure this worked as I expected. It never went to QRTL, instead it transitioned directly to qland. Not sure why? But it could be I was close enough to the homepoint.
Is a kind understatement. This, as you correctly identified, was the cause of the crash. I should have never set RC3 to 31. It was a poor, misguided decision that I will attribute to ignorance and sleep deprivation. Itâs tough to be stupid
Tough way to learn a lesson, but I am glad that it was human error, which increases my faith in the firmware and hardware.
Thanks,
Dave