Yuri's new project (ArduCopter Quad - now 4.1.0-beta)

I was waiting to hear the flight time. That is in the range of what I was hoping to get when I DO get a flying machine going.

Amazing results all around!

1 Like

I updated to 4.1.0-beta today without issue, and it’s flying easily as well with the new firmware as previous. I think the autotune parameters may be a tad conservative, and perhaps I’ll run it again in calmer wind (I ended up running the routine in Loiter mode for all but the yaw axis). It’s quite stable, and I’m pretty happy as is, but I think it could be just a little more responsive with less oscillation to stabilize after large control inputs.

Thanks to @Derek for the log anonymizer feature point out. Here’s a Google Drive link to today’s last flight (starting with about a 75% charged battery for this power cycle):

I also added some WS2812 LEDs to help with visual orientation. I have some experience with Lua scripting for ArduPilot, but this proved slightly challenging, particularly due to the mid-stream firmware update that changed some of the variable and function names. There’s plenty of improvement to be had with the code I attached below, but it’s functional. Interestingly, it helps to delay the first call of the update function. If I let the script execute straight through without that 750ms delay, the LEDs remain off (except for an occasional lucky boot).

QuadLights.lua (3.4 KB)


Lastly, I’m not sure what’s up with the antennas I linked in the build list, but they are not an improvement to the antennas that came with the SIK radios. They are indeed the same part number that I used for my mower project, with which I get great range and quality. Perhaps one of them has a bad ground or something - I’ll do some more exploration there. I noticed the link quality was pretty poor no matter what antennas I used, and a firmware update from within Mission Planner along with the settings shown below seems to have helped quite a bit. I’m sure locating the ground radio some distance away from the laptop would help as well. If I get ambitious, maybe I’ll just make some simple 1/4 wave antennas…

Note: To update the firmware on the air radio, you need a 5V USB FTDI interface. I happened to have a couple of them from other projects, but they are cheap, accessible, and simple to connect.

Further note: The replacement antennas I was using had RP-SMA connectors, while the SIK radios use SMA. I didn’t notice that until much later…



On the subject of SIK radios - I’m sticking with the stock antennas for now. I did some experimentation this morning with antenna placement/orientation, and even frequency tuning of the replacement antennas (replaced the active element on one and trimmed while watching for change). No matter what, the stock antennas beat the replacements. That is not the experience I had with the mower, but so be it!

As such, I don’t think I can recommend those antennas - save your 6-9 dollars for something else.

EDIT: Nevermind about the replacement antennas being useless. You need an SMA/RP-SMA adapter to use them with the SIK radios I linked in the first post. I was just to un-observant to recognize that and blamed the poor signal quality on the antennas rather than my own mistake.

I use one of those antennas for my ground unit. The air units have a half-wavelength piece of thin coaxial wire (salvaged from an old laptop) with half - quarter-wavelength - of the shielding removed and soldered directly to the HM-TRP pins. Saves weight, and it’s good for 2.5 Km, almost the same as my Taranis with an antenna mod does.

I made a few discoveries this weekend. My VIBE values were very low because I had the Cube on a very squishy vibration damping mount, and I think that mount is the reason I’ve had trouble tuning the roll axis under 4.1-beta. The Cube already has internal vibration damping, and it shouldn’t need more. I naively thought that eliminating all vibration was a good thing, but I’m now more impressed than ever with the whole ArduPilot ecosystem - the control loops run fast enough to detect and correct for extremely small perturbations and it’s GOOD to let the FC “feel” nearly everything that the frame is doing (with notable exceptions, of course that are, for the moment, beyond the scope of this thread).

So, I hard mounted the AP using some heavy duty 3M mounting tape, and the sensed vibration increased quite a bit (but not clipping). My first attempt at autotune with the new mount was going very well (no “failure to level” messages), but it was cut tragically short.

The adventure is over for now…it crashed. HARD.

After a couple of late night hover tests with the hard mounted FC, I got up and began running the first autotune routine in pretty calm wind. The roll terms were increasing nicely when the props stopped, telemetry disappeared, and it just fell from the sky from about 30 feet.

A look at the log makes it look like the battery completely died, and all logging/telemetry ceased at the moment of failure. However, there were still lights blinking on the quad when I got to it, and a cursory check of the offending battery shows that it’s mostly balanced with a little under half charge remaining. Another boot cycle with the same battery brought it right back to life (worse for wear, of course), it armed, spun the motors, and probably would’ve flown if I increased the throttle (no prop damage - it pancaked on the landing gear which absorbed most of the impact, along with my camera gimbal (I was tuning with it installed because it sits low and affects the CG quite a bit).

Post crash battery stats:

I need to get some yardwork done today, so I’m walking away from the quadcopter project for now. I’m not giving up, but I need to put it down for a bit. Here’s a link to the log file for the crash.

Well, there are no smoking guns here that I can find. Here’s the process of discovery so far:

I checked the suspect battery’s charge state and internal resistance - all nominal. I put a few mAh worth of charge into it, and the charger functioned normally with nominal values on the battery.

So, I devised a load test of sorts using two identical batteries (the ones I linked in the build list). Let’s call the batteries GB (good battery) and SB (suspect battery). Initial conditions were a fully charged GB and SB around 3.8V/cell.

  1. Power the charger with GB and use it to fully charge SB.
  2. Power the charger with SB to charge the now moderately discharged GB.
  3. Set the charge rate to 2C (14A).
  4. Monitor the input voltage from SB during the charge cycle.
  5. Recharge SB at 1C rate using AC power in and monitor that charge cycle as well.

Everything worked normally. A constant 14A drain on SB showed no sign of distress or failure. Internal resistance remains low (~3mΩ per cell, just like GB).

I think I can rule out battery failure.

Another logical source of failure might be a short to ground from a loose connection or chafed wire. I see no evidence of that, but I will carefully dissect things as I rebuild (probably this week) and see if I can find a problem.

Lastly, I must fess up to some buffoonery. During the build, I accidentally applied full battery voltage to the ground servo rail of the FC, with a ground wire on one of the servo rail’s power pins. It was a double error - I misunderstood the purpose of the ESC’s power wire (thought it was 5V, but it’s full battery voltage), and then cross-connected it, too! Thankfully (or perhaps tragically) the tiny 28AWG wire acted as a fuse, and it appeared as if little harm was done.

I did have some trouble flashing the ESC, but it eventually worked. The FC occasionally seems to have a boot anomaly where it gets stuck prior to ESC detection, but I attributed that to the finicky LED script that I’m running (since the script doesn’t run on the occasionally anomalous boot cycles, and I know it’s taxing on the processor and memory).

So…it’s entirely possible that I pooched up the ESC, FC, or both, and that the electronic demon I created was laying in wait until this morning. If I find no other evidence during the teardown, then I’m attributing the failure to my own stupidity. We all learn the hard way at times…

Against my better financial judgment, I ordered a replacement for both. I can use the suspect ESC and FC on another project that doesn’t wield 13" blades of fury.


I got some SMA pigtails with the express purpose of testing some DIY antennas very similar to what you describe. Good to know someone else had success that way.

This post shows a pretty cool, extremely simple method of constructing a sleeved dipole antenna that might work really well (with respect to its weight) if tuned properly.

1 Like

I guess you are paying more for the new FC than the previous, unless you found a better source than I. #ChipShortage

Looks like it was a brief price hike. It was back to $250 today :smiley:

Make a reel mower rover as a next project? If the flight controller resets it should just sit there (vs crash like a multirotor).

Is there any way to rule out the LUA LED script? Could you run the script and LEDs on your rover mower as a stress test?

If you want to get into making your own antennas, IBCrazy has some good youtube videos https://www.youtube.com/watch?v=sCypz0ZeDdo

I think the easiest way to rule out the LUA script is to monitor the new FC and ESC behavior at boot. If the boot anomaly is present with the new hardware, then I better disable the script until I have time to rewrite it.

I strongly suspect that the ESC is to blame for the boot anomaly rather than the script. I have a feeling that the Cube survived my goof-up just fine, but the ESC did not. I’m still wondering if something shorted, though. Even if the ESC gave up the ghost mid-flight, it shouldn’t cause a drop in battery voltage like that unless it had a significant internal short.

It’s all fixed up, and if this thunderstorm breaks, I’m gonna go press my luck with a test flight.

During the teardown, I was careful to look for signs of a short, and I found nothing obvious. I’m pretty baffled as to the reason for the crash, which makes me nervous to take to the sky again, but it’s no fun to be grounded, so, with a few new parts, I’ll be back at it soon.

I decided to hard mount the FC between the top and bottom plates. The wiring is more protected there. I moved the battery to the top plate where the weight is more in line with the rotor plane, which should make it more responsive, and then I can keep any payload closer to the CG as well. I replaced the thin foam on the landing skids with some foam utensil grips meant to aid the elderly/infirmed with things like eating and toothbrushing. So far, it seems I do a lot of landing on concrete, so I feel better with the ugly but softer skid pads. I also added some green silicone caps to the right skid (same color as right-side position lights) to help with visual orientation.

EDIT: It lives!!! First flight success. Took off in stabilize, made a few increasingly aggressive jinks to check that it wasn’t going to upset itself, checked that AltHold was useable, and then started autotune. I thought I just had the roll axis enabled, but I accidentally enabled all 3 axes. The good news is that the new configuration + lack of camera gimbal helped with endurance, so I was able to get all 3 axes done on that same first flight. There were no “failure to level” warnings, and the whole routine seemed to take less time than before. So…lesson learned…don’t mount a Cube on a soft mount! It got dark, and I don’t have any of the lights connected yet - trying out the new tune will wait for another day.

1 Like

Unrelated but… Those Master Airscrew props are great arent they? I tried to balance a set but you are just making more work for yourself - they are fine to use straight out of the packet.
I’ve seen four of the 12inch Master Airscrew props lift a total takeoff weight of about 7.5 KG (or a bit more).

1 Like

Absolutely related…and I have little basis for comparison, but they definitely exceeded my expectation. They are far better balanced right out of the package than some of the cheap RC plane props I’ve used. Still, it doesn’t take long to balance using the method I showed here, and it probably doesn’t hurt.

Completely unrelated, I found a free version of the sheet music to Thunderstruck, and if you want to play AC/DC on your BlHeli32 ESCs, set the gen length to 12 and paste this:

  • ESC #1
    B5 2 P4 A5 4 P4 B5 4 D6 4 B5 4 D6 2 E6 4 D6 4 F#6 2 E6 8 D6 8 B5 4
    P1 P1 P1 P8 P16
    D7 2 B6 4 P8 P16 B6 2

  • ESC #2
    G5 2 P4 F#5 4 P1 P1 P1
    B6 8 B5 8 A6 8 B5 8 G#6 8 B5 8 A6 8 B5 8 G#6 8 B5 8 F#6 8 B5 8 G#6 8 B5 8 E6 8 B5 8 F#6 8 B5 8 D#6 8 B5 8 E6 8 B5 8 D#6 4 P8 P16
    E6 2 E6 4 P8 P16 E6 2

  • ESC #3
    A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8
    A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8 A4 8 P8
    P1 P1 P1 P8 P16
    D6 2 B6 4 P8 P16 B6 2

  • ESC #4
    A5 8 P8 P2 A5 8 P8 P1 P1 P1
    A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 A5 8 P8 P8 P16
    D6 2 B6 4 P8 P16 B6 2

1 Like

I must confess to another silly mistake that cost way too much time to correct - unlike the Holybro SIK radios I used before, the ones linked in this thread have SMA connectors. The replacement antennas have RP-SMA connectors. So, there’s a great reason why the replacement antennas performed so poorly…they were physically attached but not actually connected, and I never bothered to look at the simplest solution first!

It gave me an excuse to get a cheap little vector analyzer, though (look up PS100 or N1201SA on the usual suspect sites…Amazon, AliExpress, BangGood, etc). After calibrating it, it showed the stock antennas were tuned in the 600MHz range, which makes no sense at all for their intended purpose. So I cut off the active elements, soldered up these dipole antennas, and used the VNA to tune them by cutting the elements a little at a time. With those installed, the telemetry RSSI and SNR show much closer to expectation. Alternatively, I could just use some SMA/RP-SMA adapters, but what fun is that?

The copter is grounded except for a little testing to confirm my suspicion that I damaged a motor in the still unexplained crash. There’s a yaw instability that I cannot correct through tuning, and it appears that the #3 motor is not accelerating at the same rate as the others. I’ll throw some parts at it soon. In the meantime, I’ll do some work on the lawnmower and post those results in the Rover forum.

That RP gotcha is easy to happen. It’s too bad that such a thing exists!

1 Like

It lives!

I never narrowed down the root cause of the crash. I’m chalking it up to $h!t happens and moving on. I replaced the ESC with a HobbyWing X-Rotor, and I didn’t like it. It was less feature rich than the Lumenier Elite with less heat sinking, and it seemed to be the cause of the yaw instability I mentioned above, which was still present even after I replaced the suspect motor. So I got yet another Lumenier Elite ESC, and all is well. I have little basis for comparison, but the Lumenier seems like a really nice ESC.

The micro MinimOSD board finally showed up off the slow boat (fair warning, if you order from the link I gave, it takes at least a month to arrive in the US). That caused another problem…I ran out of serial ports! I had MAVLink2 on SERIAL1, FrSky telemetry on SERIAL2, GPS on SERIAL3, and ESC telemetry on SERIAL4.

So I elected to remove the ESC serial telemetry, use that port for MAVLink1, enable BDSHOT, and mess with the OSD, which was pretty easy to get set up. I flashed it with MWOSD using a 5V FTDI interface. Then I paid the couple of GBP for the license to write settings to the EEPROM. The software was easy enough to use, and it’s super configurable. I used what looked like some reasonable default profile settings and called it good enough. When the copter is disarmed, you can follow some on screen prompts to use the transmitter sticks to navigate a series of menus.

Because I’m interested in freeing the limited serial ports in other projects, this was a perfect place to experiment a bit with UAVCAN. The Here+ V2 looks like it has an option for CAN bus operation, but it appears that was a future roadmap thing and was never actually enabled. If it’s supposed to work, I couldn’t make it happen. But I did find the mRO UAVCAN Node, which will convert many ArduPilot compatible serial and I2C devices to the UAVCAN protocol. It was entirely unnecessary for this project, but I wanted to experiment, so I ordered one. Once I set CAN_D1_PROTOCOL = 1 in addition to the settings on the documentation page, it worked right away without further setup, including RTK injection and the integrated I2C compass. The notification LEDs on the Here+ aren’t working, even with the UAVCAN bit set in the NTF_LED_TYPES parameter, but I can live without that. With SERIAL3 freed up, I reconnected ESC serial telemetry there. I was also able to split the button pins off of the Here+ connector and connect them to their previous locations on the GPS1 connector, so the hardware safety switch still works, even with SERIAL3_PROTOCOL = 16. It was a really interesting exercise and may prove handy again someday!

I have some more ideas about video capture, but I’ll save that for another post. This one is already longwinded!

1 Like

I would say i agree and nice build BTW.

1 Like

Perhaps one of you following this can un-muddy the ESC telemetry waters.

As I understand it, BDSHOT telemetry is quite a bit faster than ESC serial telemetry and should offer a significant performance increase, particularly with respect to harmonic filtering. However, BDSHOT is RPM only, where ESC serial telemetry often includes voltage, current, and temperature in addition to RPM.

If I read correctly in the BDSHOT support topic, there is no harm in enabling/monitoring both BDSHOT and ESC serial telemetry, and they do not conflict with one another.

Do I have that about right, or is there more to the story?

You can do both at the same time, just make sure TRATE is low (the default of 10Hz is fine)

1 Like