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.
Is anybody using Arduplane 4.0.x on a Nimbus V2 with PG20? I would love to hear from you.
Also attached are my Nimbus V2 PG20 parameters, it would be great if someone would have a look and advise if anything seems array. To the best of my knowledge and reading I should be good to go. https://1drv.ms/u/s!Auv-5QlGCPQojSMCeKGAswiZ2M4N?e=D4TNbp
Steven, sound like you are the person I need to talk to. I am a drone pilot flying the DJI quads. I am looking to play with the Nimbus and have no idea what I need to do to learn the ArduPilot software. Can you give me any advice on training and who I could get with in the USA to see the Nimbus in flight before I waste my money!
Hi Darrell, some would probably say I’m not the person to about the Foxtech Nimbus. I have a number of issues with the Foxtech Nimbus. I mine remains on the ground as a $5000 brick. Foxtech Nimbus V2 has 3 different instructions regarding firmware update. The Manual from the website states you can if required upgrade the firmware, The Firmware updatedocument from the website states to update to the latest Arduplane for enhanced failsafe features- and the video that accompanies this clearly shows arduplane4.0.1 But Foxtech support and Nimbus v2 webpage both state that the firmware is customised for the drone do not upgrade or change it.
Mike Lee – Skype “yes, this firmware is different from Adduplane and we got it from our suppliers” “Please never refresh the parameters or firmware by yourselfjust use the default parameters and firmware”.
Foxtech have not released the source codes (which is against the licencing agreement) for their version of Firmware used in the Nimbus V2.
It is important for all documentation and source codes be available to purchaser of Nimbus V2 because we know that installing the wrong firmware can cause crashes and the Nimbus firmware upgrade states to upgrade firmware for improved performance and safety – as I have read about some issues with PG20 and Q-YAW and I wonder if this is due to firmware upgrade. Only by releaseing the source code can critical analysis be done to confirm and fix these issues.
Why do I care? Why not just fly the unlicenced unverified code? Insurance, air safety, costly investment, and because in 2018 DJI had battery failures with TB50 and TB55 batteries that went unreported resulting ongoing losses of M200 series drones, fortunately no injuries to people were reported.
Beyond the firmware issue - I have found their support to be good, you just need to be patient and clear on what you want, in the first instance expect a generic type response, if this doesn’t fix the problem be more specific and include photo’s or video, and always be polite. I would avoid the PG20 it is definately 1 of the failures that occurs with a firmware upgrade and others have reported fc brown out using this. I also have a MAP-02, which came with a different wiring harness to the MAP-02 Manual, it is a little fussy but I now have it sorted. The ONLY way to change parameters is via HDMI port and the plug in ribbon controls that come with it.
By all accounts when in the air they fly ok - I would just like to see Foxtech get their ducks in a row, with regards to document control and firmware so we can fly them safely and confidently.
Being just shortly before the maiden of our Foxtech VTOL V2, I’d like to ask the experience of other Nimbus VTOL owner regarding potential, necessary modifications of the aircraft.
We are running the “original” firmware as delivered by Foxtech, have a PG20 that we are currently not using as we are running solely on a Foxtech semi-solid LiPo battery.
I’ve read some issues with servos and/or hinges. Do I need to make any changes on this before maiden?
Hi Steven,
thank you for your good wishes. What improvements for the flight operations are you expecting by running the 4.0.1 version?
Yes, documentation is a difficult issue (for this “RTF” product). Many versions are available, but the one you get along with your product is hardly the one that suits.
Anybody has an idea, how the different flight modes in Ardupilot are used in the Foxtech version? Some flight modes switch from copter to fixwing operation, e g. when going into ACRO mode…
Hi Pascal, @GregCovey would be best to talk about flight modes but ACRO won’t be one of them for steady flight I have Q Stabilize, Q Hover, FBWA, CRUISE, LOITER, Q Hover.
I can’t afford to put $5000 aircraft in the air with unverified firmware, Tridge has confirmed this and I doubt my insurance would cover me. Also the because the foxtech firmware has its own source code you cannot be certain what effect parameter changes will have on aircraft performance or function.
Foxtech have documentation stating 4.0.1 so I know they have a build that will fly on standard Arduplane upgrades to 4.0.7 from there should be doable and there are obvious benefits to that, and others have been able to fly on standard Arduplane 4.0.x, but I’m not sure if they are using PG20. I was supposed to recieve a copy of these parameters from Foxtech today, but I recieved again standard Foxtech Parameters instead.
I would really like to have Arduplane 4.0.x parameters from anybody with PG20 version. if anyone could share.
Hi Steven,
okay, so running the supplied firmware is not necessarily a danger per se, but the lack of security about the parameter settings.
As far as I could identify, the version on my Cube is 4.1.0dev. I don’t know whether this is of any help…
Hi Pascal, In Mission Planner I don’t get any version displayed, so this is a positive for you. Yes mine is a security/safety issue around firmware version and parameters.
Hi Pascal, So I found I’m running 4.1.0dev chibiOS as well, I cannot find any relevant literature on it though, unlike the stable released versions which have lots of chatter. What dev. actually entails and weather it is inherently stable and weather the source code is consistent to 4.0.x. Hopefully I’ll learn more soon and get in the air.
The meanings of the versions from the WiKi are below. When you use a “dev” version, it is from the “latest” category and meant for developers or experienced testers only. There are no release notes until it moves to the “beta” and then “stable” categories. There is a thread below for copters that explains some of the process, which should be the same for plane.
stable - this is the version recommended for new users. It has had the most testing
beta - this is the firmware to choose if you want to be part of beta testing of new versions prior to release as a stable version. Note that during some development times the beta release will be the same as the stable release
latest - this is the latest version from our git source code repository. This version is only for developers. The code may have unknown bugs and extreme care should be taken by anyone using it
Thanks Greg,
Well that says it all, looks like I’m on the ground until Foxtech gets its ducks in a row - or I manage to find a set of parameters running 4.0.6. I’m astounded that they would use this code as their retail firmware - Bordering on criminal.