Well going back to the era where most fabs were US based is not a feasible option, not without some really dramatic and potentially tragic consequences, not to mention that some options may just not be possible to relocate back.
Trick would be to get the chinese to play by the book. A good old saying goes that you catch more flies with honey than vinegar.
Obviously the “go cheap no matter what” approach the chinese have used isn’t working anymore, no more than outsourcing everything over to them worked for the US…so the trick is how to get the red chinese to play ball, mind you it’s not the tawainese nor the singapore chinese we’re talking about but the commies from PRC. and that is a political mess nobody can really solve…least of all
here
At the risk of further boring those persons on this thread who are here to actually talk about drones, I’ll add this.
Complicating everything is that much coming out of China is of extremely high quality. Problem is that it’s very difficult to know “a priori” when that will be the case.
Also, the Chinese Communist Party today is of course much more sophisticated than that under Chairman Mao! Political suppression, concentration camps – yep, still there. But the mix of that authoritarianism with a vastly higher standard of living for the people (at least in the cities – the farms, etc. are another story), with censored access to the Internet and hi-tech that puts the rest of the world to shame, create a much more durable political control model for them.
As an aside, I’ve been to Japan twice many years ago, and marveled at the tech as I walked through Akihabara. But the kinds of tech merchandising palaces I’ve seen in videos from China now make Akihabara look like a flea on an elephant by comparison.
I’ve been looking into the issues of “loss of control” after connection and disconnection of QGC via Wi-Fi, using the technique of opening the port with the C-Fly app. I must admit that right now I’m stumped. The MAVLINK params look correct but somehow the app and/or controller become disassociated after QGC is disconnected, even cleanly. I’ve tried all sorts of combinations and different timings.
It definitely IS possible to change parameters and save them using this technique, and for many users that will be enough. But I’ve been very curious to see if missions can be loaded this way. And yeah, you can load them. But it does no good, because once QGC disconnects (and/or tries to reconnect) the bindings are lost, usually until everything is power cycled.
So there is indeed loss of control, though whether or not RTL failsafe would kick in at that point is unclear.
My guess is that when QGC connects, the bindings move over to it, and when it disconnects, the original bindings to the C-Fly app and/or controller can’t be restored.
Under normal conditions with most ArduCopter-based units, it is usually fine to have more than one ground controller app at the same time, so the contrary behavior being seen with this particular device is definitely mysterious.
Could be related to how the UDP connection is seen on the drone and how the native app handles it. I recall having multiple UDP MAVLink sessions from different machines even but I did have the MAVLink Proxy running point and it was allowing a single connection to the drone with the option to open additional sockets on different UDP ports. Which makes sense since UDP is connectionless so you can’t really know who sent what in which sequence. Having multiple single-client sockets opened on different ports obviously solves that issue but leaves you with a bunch of UDP ports that you must allow.
When doing this on a cloud-hosted VM is a bit iffy
I had been thinking about the UDP issues. What’s unknown at the moment is exactly what state the unit goes into when this failure mode occurs. The main light goes back to blue, no apps are connected anymore, and the controller is apparently disassociated as well. If it had been in flight I might suspect RTL, but it’s not even armed yet. This really needs to be inspected via USB. I’ll do that when I start testing USB on the new unit. Much easier than last time, since I now have the proper connectors!
By the way, one easy mod that can be done now using QGC via Wi-Fi is to change the flight modes so that both Loiter – and Loiter with the Simple bit set (headless) – are available. So for casual use, headless is much easier, but for FPV you want headless disabled of course. If one of those two modes replaces the existing “altitude hold” mode, you could switch between them using the button on the controller.
That Loiter mode I recall it being in a older version of APM - 2.5.2 but in APM 2.8 and ArduCopter 3.x I think there is also a PosHold mode which for some reason differs from Loiter. From what I could dig up on these modes, their MAVLink definition at least seems to indicate they do pretty much the same, except Loiter is a bit more lose, meaning there’s a value for how far away from the intended GPS position the quad can drift before corrections are made.
It was almost 3 years ago when I looked into this so I may have forgotten things…
My point is that if we change from Loiter the quad may start behaving erratically, I mean MORE erratically than it does already. Also having that headless mode could be very confusing, especially for beginners if they fly out of line of sight and find themselves in that mode and pushing forward stick doesn’t bring the quad closer when they see themselves in the video feed…could be one of those Oh s*ht moments when you panic and hit the RTL button.
Position Hold is the looser one that gives the user more control, Loiter is the more “locked down” mode. Both can have the Simple bit applied to create a headless version of the modes.
Right, you wouldn’t want to use headless mode flying FPV. But there are times when it is undesirable or impractical to bother with the phone for video, and when just flying visually without video, headless mode can be very handy, and is especially important for beginners (and even for experienced users in some cases when flying at a distance where visual cues of the drone are minimal).
That’s why I suggested having both modes in place, and using the mode button on the controller to switch between them. Then the best of both worlds are easily available.
Actually, most drones of this class already have a standard headless mode available as an easily selectable setting. It’s rather odd that this one doesn’t (and I’ve seen some write-ups for it that inaccurately suggest that it does).
I hear you, the PosHold mode was a bit odd when I cave across it since Loiter seemed more apropiate for staying at specific coordinates but then since these modes apply to a variety of MAVLink vehicles then I guess each mode has its uses.
I used headless mode myself in the beginning, it’s really useful for beginners when they lose their orientation, and they always do. It was particularly useful for non-GPS drones, my Syma X8 variant only has barometric Altitude hold and those brushes motors are far from precise especially after several flights, so having the option to switch to headless mode and know that the right stick down brings the quad back was particularly reassuring mainly before the first crash. Afterwards I stopped using headless as it seemed too much like I had training wheels on
At least this confirms – if we can believe the battery markings – that these are indeed LiHV batteries being charged to 4.35v per cell, since it’s marked 11.4 not 11.1.
No, no particular problem.
It was that summer a very hot day after a flight.
I was able to remove the cover and take a picture.
I take this opportunity to find a cheaper alternative.
Well I just had another look at the pictures I took when I opened the swollen ones and indeed the marking on the batteries says 11.4 so they’re supposedly LiHV, 13.2 V when fully loaded, so at least that worry can be put aside.
What cannot be explained though is why they still swell? Worse, I had yesterday a flight with a pack which was 12.6 V (still reported as 100%) but the voltage dropped to bellow 40% after only 5 minutes of flight and a previous 5-6 minutes of waiting for the satellites to show up. Obviously these packs do lose their charge more quickly than expected, the pack I used yesterday only had like 3-5 charge cycles, a far cry from the 50-100+ cycles expected from a regular pack and it was not one that was swollen before.
Alas, I don’t seem to be able to get more than 10 minutes of flight on a full pack no matter what I try. I always end up with less than 15 minutes I think only on my first flight I did get around 18 minutes which was awesome but still nowhere near the 25 minutes advertised.
I read in a post in one of the X12/EX4/C-FLY groups of FB that C-FLY acknowledged the faulty batteries and are in the process of producing newer, better batteries - here’s the post if anyone’s interested:
So looks like we should not throw these quads out yet, there may still be some hope left for them.
That FB post can’t be seen without a FB account, could you summarize it for us please? In general, I haven’t heard about a lot of battery problems with these quads, though bad batches are always possible. Those batteries appear inside to be conventional cells from any one of several Chinese OEM suppliers. I have three new ones here that haven’t been tested yet, so I’ll have additional data points shortly. But I haven’t seen a deluge of short flight time or puffed battery reports, for whatever that’s worth. There are always concerns that some users are not treating the batteries optimally, and C-Fly, Eachine, etc. are not being explicit in the instructions about how best to handle them (e.g., don’t let them get or stay too low, best stored around 50%, etc.).
There’s not a whole lot to add, I inserted the FB message so if someone wants to know where I got my info to have a starting point.
As for not handling my LiPos correctly, I do keep them from over discharging, I keep a good 20% for the leg back. As for storage, I fly fairly regularly - every week-end or 14 days between flights so not much of a storage issue. I do suspect there may be something with my flying technique, I do tend to loiter a lot and surprisingly that is a leading factor in draining the battery in mid-flight - it apparently takes a lot of energy to just hover in place and do frequent corrections than flying straight or doing maneuvers, which kind of makes sense since when in motion some motors use less current but given how poorly shaped from an aerodinamic point of view these quads are it’s a surprise they consume less energy to move than to just hover.
Anyways, next weekend I hope to get somewhere with no EM or wifi noise to test endurance on them batteries. It is open mountains so hopefully there won’t be any rogue metallic ore deposit to screw up the compass again.
Hello everyone, this has been a fascinating thread to read so far!
I just recently got my EX4 and was a little disappointed by its vertical range, everything dropped out and it TRL’d after reaching an altitude of just 250m, is there a way to programmatically improve the tx power of the controller/quad before I resort to physical modifications?
Thanks in advance.
You could try different antennae. Some high gain ones but mind you, the quad itself has some really puny wires for antennae so don’t expect a miracle. There’s obviously the choice of altering the controller itself but there’s also the option to change the power TX/RX levels for the wifi radio in the controller’s OS - it’s running a flavor of linux so it should be possible to adjust its driver’s wifi parameters from the configuration.
I think only on my first flight I did get around 18 minutes which was awesome but still nowhere near the 25 minutes advertised.