I purchased a VTOL Nimbus a few months back from Foxtech, but didn’t maiden yet (certification takes time). As I see from your Video, it seems as if the back motor doesn’t speed up, only when applying yaw commands - that’s now just a guess, as I didn’t check your log.
Now, on my plane, I discovered a flaw in the supplied firmware of Foxtech, which you might check out on your “bird”. When comparing the servo functions in Ardupilot and the wiring on the FC, I discovered discrepancies and went deeper in the analysis. I found out - after some discussions with Foxtech - that the firmware is not according the actual wiring.
Beside others, I had to change the servo function of servo5 (linked to MainOut5 in my case) from “MountTilt” to “Motor 1 control”.
No idea, how maiden would have ended with the supplied firmware…
Maybe you want to check out, if you face a similar situation.
How did you identify this error with servo 5? Everything appears to be ok. timely transitions ESC calibrated certainly front two - way better then factory I think the Nimbus may have been a little nose down on unlevel ground, the rear motor kicks in when throttle is at 50%, I’m sure I can make adjustments to correct that. From other advise I received I only updated from Foxtech Apj to 4.0.6 and wonder if there are some additional tuning adjustments that need to be made. Just happy at this time to be getting close to a hover
Yes, I identified the error, because I found that in Ardupilot, only motors 2 and 4 were setup, so obviously the speed of the third motor wasn’t controlled properly.
If that’s not the case in your setup, then you might just ignore my remark - no problem.
So Foxtech APJ Cube black appeared to be working - on the ground. I was told that this version was untested and not and authorised build. so I have updated to 4.0.6, Petrou this may be relevant to you and explain your crash - I have previous checked PG 20 and identified that when changing from cruise to hover the voltage changes to indicate battery swap through PG 20…Fast forward to my flight this morning and hovering well 1-2m of the ground and I was about to land within the 2min -2:30 recommended by Foxtech for 2200mah batt. when Failsafe RTL activated. Rough landing but no damage noted. I have identified that the entire flight was on my low 3C 16000mah battery instead of the high 80C 2200mah batt. I believe high current rate caused the issue. So now I need to identify how to change the PG20 setting or alternatively change the xt60 and xt90 connections.
Mike from Foxtech will skype again tomorrow for this issue but I’m putting it out there for other PG20 users. and will post any fix offered by foxtech.
My MAP-2 camera is now working, Mike had shared an app with me to change the exposure settings…this was incompatible with the camera. We were able to access the camera using the supplied button on a circuit ribbon and reset and save the setting. All is now working. Learning heaps and again cudos to Foxtech, for identifying and helping correcting issues.
Thanks Greg
Yes Proper main outputs which is great and now have PG 20 sorted as well, SERVO 7 which controls PG20 function needed to be reversed, this I knew would fix the battery issue but I was concerned, it would effect other functions as well - primary tilt motor function or servo outputs. As it turns out it doesn’t.
Greg just curious do you know why RTL was activated in my flight above? I’m only running Cruise, Qstabilise and Qhover on my controller,
Yes, you are probably using a 6-position switch like those on a Taranis or Horus radio. I use the same radios, and, when you turn the knob too slow, the Flight Mode channel momentarily glitches to one end of the PWM range.
You can temporarily replace unwanted modes by duplicating the one on the end. In other words, program CRUISE for the other positions. You can also move the knob faster to the next position. I have been meaning to try the channel delay feature in the OpenTX setup but haven’t done so yet.
Can I confirm - I should be able to test Q -yaw function when armed - i.e. input left and right yaw and servos in Q mode will move forward and back appropriately. I’m positive I have done this before…If I put into cruise mode all surfaces inputs work correctly.
Hi Greg,
I’m using the Foxtech DA16+ with only 3 channels installed on the radio. I though an error might have induced the RTL. No worries bigger issues today with a forced arm > accidental takeoff and crash > broken wing and prop. Though I must say I’m impressed with Gorilla glue. Wing is fixed, prop may take longer to replace.
So to add to todays adventures - I rolled back from 4.0.6 to the foxtech recommended Cube Black APJ ( Not sure if this particular build is foxtech specific - interestingly it does not show up at the top of MP like 4.0.6, I chose to roll back after a number of changes in function that didn’t seem related to parameter changes i.e I compared parameters and they where the same though 4.0.6 removed some. The roll back fixed both the PG 20 issue and Q Yaw controls when conducting preflight.
Since you are not using a 6-position switch, I took a closer look at your RTL issue and found it to be a battery failsafe. You can read more about it here.
As for the 4.0.6 issues, try posting them in the Plane 4.0 Forum.
Here are your parameters:
BATT_LOW_VOLT,19 (Battery voltage that triggers a low battery failsafe.)
BATT_CRT_VOLT,18 (Battery voltage that triggers a critical battery failsafe.)
BATT_FS_CRT_ACT,4 (4=QLAND)
BATT_FS_LOW_ACT,1 (1=RTL)
BATT_FS_VOLTSRC,0 (Failsafe Voltage Source, 0 = Raw Voltage)
Could low battery failsafe also be triggered by excessive amps, I believe that excessive draw on a battery does cause a momentary loss of voltage - certainly both batteries were still 80%+-. But I recall anoit 106 amps coming of a 3c 16amp battery.
So…my gen1 Nimbus VTOL went down due to a combination of ESC/Motor FOD.
I have built gen 2. The gen2 version has a cube orange where the gen1 had the cube black.
I installed the cube orange into the aircraft and the aircraft is built exactly the same as the first one (that had over 24 flights, so it worked). I mean that in terms of wiring.
I then loaded the cube black version of my param file by hand selecting all of the copied over parameters. The only difference I saw was with the battery monitor parameters and I changed that over.
So, my problem is that the entire bird works, all of it EXCEPT that the tilt servos are not receiving a signal. I have confirmed that it is getting power via a volt meter. I have also confirmed that the servo itself is working fine by hooking it up to a servo tester.
Both the right and the left tilt servos do not work, all else does.
Ok, I got those variables in correctly now, TYVM Greg!!
I also found out that I had a rare bootloader bug that has now been addressed. It would randomly set all variables back to factory default and required an update. That’s all good, no resets have happened yet.
She arms via the hardware switch yet the tilt servos do not power up because it’s not receiving a signal (getting a signal is a requirement for these servos to power on). It has to be a setting somewhere because if I hook a tilt servo up to a servo tester it operates fine. Any ideas??
I have confirmed via a continuity check that from the autopilot to the servo there is a signal path (I hear the tone from the multi meter). I have also re-checked the power going to the servo, it has 8.04Vdc and the polarity is correct.
She arms via the rudder on the transmitter. When the hardware and the transmitter arming is complete the rear motor spins up but the front two motors require a bit of throttle to spin up. I think there is a variable where I can tell it to spin up with X % of throttle, but what was it?
I still need help figuring out why the tilt servos won’t behave. I have double checked the inputs via the same Nimbus 1800 wire guide I posted much further up in this thread, it all checks fine.
Hardware wise, the front two motors have different ESC’s than before but I don’ think that is an issue here as the motors do spin once they are armed and a bit of throttle is applied.
Chad, I to have a similar issue, I have found the source to be. The foxtech version of Arduplane that comes from the factory cannot be updated to Arduplane 4.0.6 (not exactly certain about 4.0.5) updating this causes at least two critical errors. It causes the PG20 batteries to reverse meaning over current draw on Takeoff and landing and very sort flight time in Fixed wing modes. It also disables Q-YAW function. In your words “tilt servo’s wont behave”. If the original cube black was running the foxtech arduplane apj then I believe that is your issue. I have raised this a couple of times across the forums. Foxtech have advised me that I must use their firmware and CUBE has warned me against using it as it is unverified and uses different source code to 4.0.6.
Learned something new, the “Q” parameters do not copy over if you use the compare function. I assumed it all transferred over. Going over everything with a fine toothed combed now.
