Hi All,
I had an APM 2.5 on my plane for a couple of years and after the initial setup it performed reliably for those 2 years and was quite solid. Recently I decided to upgrade to the pixhawk and ended up buying two of them for two different planes. So far my experience with them has sucked. One of them died with the (No PX4IO board found) message which indicates hardware failure. 3DR agreed and replaced it (but it took a month). Now, just today the other one lost it's USB port and it's hardware failure as well. This is devastating to me and has me wondering if I should just give up on Pixhawk and just us the Eagle Tree Vector instead which so far at least has been easier to setup and with no failures ( I have two of them as well).
Though I'm intrigued by some of Pixhawks advanced features and capabilities I really want something rock solid and usable. But I'm upset that I've wasted about $800 and countless hours on this experiment. Did I just have really bad luck with this hardware or is it a poor design and fragile?
Thanks for any insight.
-Paul
Replies
Suit yourself. As my old engineering professor used to say "you pays your money and you makes your choices".
But you might take a look at the Ardupilot wiki under the section Common Pixhawk wiring check the image above "For planes connect the control channel wires to the main output signal pins:"
What do you see? or maybe more correctly what don't you see?
plane.ardupilot.com/wiki/common-pixhawk-wiring-and-quick-start/#connect_other_peripherals
Yes, I've seen that image on occasion and thought... that might work if you had one of those special connectors and wanted to go to a lot of trouble. As I said, it would be one way to be sure the power for the servos was isolated from the Pixhawk but I just feel it's a lot for the designers to ask of the users. Maybe it will turn out to be the best way, I don't know.
Here is the way I'm trying to do it to address both the Pixhawk PWM power rail -AND- the warning at the top of the page you linked to about drawing too much power from the RX rail for servos. Tell me what you think!
All,
I have an interesting update to this thread. As Chris suggested above I contacted 3DR support about this issue. They asked me to check a few things and I started to write back with the steps I had done to determine this was a hardware problem. While the Pixhawk would power up with the Power Module it wouldn't power up with the USB cable and even when powered up though the power module would not communicate through the USB. I tried the firmware update and it got stuck with a no communication error. I tested everything (USB cable, PC port, software) with a brand new Pixhawk and to make sure everything else was working, but the sick PH still didn't work. It didn't matter if I plugged into the remote USB port or the one on the side, same thing. And I removed the pixhawk from the plane so nothing else was connected, same thing.
I did all the above the day before I was responding to the support email. To be fair I thought I should probably go into my shop and try it one more time. And it worked! It powered up through the USB port and I was able to update the firmware on it. But I had changed nothing from the day before!
Then I tried to connect to it in Mission Planner and that didn't work, so I discovered the SD card was missing and when I put that in I could connect to it and it seems to be functioning normally. So the missing SD card was obviously my fault but I can't imagine that had anything to do with Pixhawk not power up on USB when it powered up the next day with the card still missing. It was only connecting to Mission Planner that didn't work until the SD card was inserted.
Bottom line is I now have a functioning unit but since I don't know why it malfunctioned I don't have full faith in it yet. Since I had already replaced the Pixhawk with a new one I'm going to leave that one in the plane and see what my experience is with it first. I'll keep the sick one for another plane I've been building and test it there eventually. If anyone has any insight or a similar experience I'd love to hear it.
The good news is from what I learned in the dialog above I'm a little more confident in setting up the new Pixhawk this time.
Thanks,
-Paul
That is indeed bad luck. Failure rate in the field (even with hard landings and cables being ripped out) is less than 2%. Email help@3dr.com and we'll send you a new one.
Wow, I'm a bit star struck I have to say as I didn't expect a personal reply from you Chris!
That said, your message is a good one and gives me more confidence in requesting another new unit.
While I've been a member of this site for many years I haven't done a lot of posting so please allow me to ask a couple of other questions that have been bothering me.
1) Is a zener diode still required? I thought that was a strange requirement but I did go to the trouble of ordering it and a tool to crimp it to a servo connector.
2) Since it's recommended to isolate the GPS unit from sources of interference why would a longer cable not be included or at least available for purchase? It seems like GPS placement would be a universal issue with many users.
3) There is a warning in the instructions not to use the PWM output pins of of the receiver directly in any manner so I struggled to get the output for my brushless gimbal to go through the Pixhawk pins. Unfortunately the gimbal developed weird behavior that isn't present when hooked directly so I want to use the programmable outputs of a dragon link RX to control the gimbal directly. Is there a way to do this safely?
Thanks,
-Paul
1. The zener is to be used when you have big digital servos on servo rail, servos that can generate power (you can check with a voltmeter, some can produce voltage when moved.
this is the electrical reason, and (sorry Chris), the correct one.
2. for many/most the included cable is plenty, including "too much" is not a good solution, as for my planes I could wish 30cm, but then a coiled up cable for those who don't need that may be even worse.
3 it's ok to use PWM pins on rx , but do not load the dervo rail on RX - because it's powered by less power, (reciever does *not* get it's power from servo/output rail on Pixhawk, but the redundancy-controlled internal power)
I have been using Pixhawks profesionally for years, also selling them in an small norwegian webshop, since release, I had two RMA's - both with defects on arrival, an insignificant percentage.
Hi Andre,
1) Do you know how hard it would be to protect against this issue internally? If this was cost effective I just think it would be nice to relieve the user of these kinds of fine points. When I see BEC's that can take a wide voltage input range without problem I don't understand why nothing over 5.7 volts can be allowed on this rail.
2) What about an extension cable or two of various lengths?
3) So the RC in port (and the neighbor port for RSSI in) is not connected to the 5V servo rail and has it's own internally produced power source specifically to power the receiver? But that power source is not adequite to power any other devices connected to the RX. So if I run BEC power to the RX and cut the red wire to the RC in port of the Pixhawk is that the recommended way to handle it? And I assume I can use the same BEC to power the Pixhawk servo rail and the RX, correct?
Thanks for helping me out Andre. It's good to hear of your experience with many Pixhawks.
-Paul
1: I see you wrote "I just thought it was strange to ask the user to do this when over voltage protection could be included internally"
A proper zener, to handle BIG servos , would be the biggest component inside, making pixhawk even bigger/more expensive/heavier, and >90% of users won't need it anyway, those who do, can easlily add it. So it's a call made my smart people, I'd say a correct choice. - giving the fact it's only there to ensure that the servo rail can be used for redundancy, and people will have USB and PM inputs for redundancy anyway.
2: do not exceed I2C lengths, - that depend on cable and what's near it - monitor I2C errors to be sure.
3: not sure what you mean by "neigbour RSSI port" ? - but reciever is fed by internal +5v of the Pixhawk. - you can feed reciever another +5v , but disconnect the +5V from PPM port then, - and do not make groundloops...
1) Fair enough, I just wish it was clear (or I had figured it out) that the zener diode was NOT required in most cases. I was trying to be careful and protect my investment.
2) The GPS has two cables that need connecting. I used the I2C "hub" to extend that one, by having that in the middle it doubles the length. I extended the GPS cable with the cat5 wire as I explained, now Chris has pointed out a longer 30 cm GPS cable which I will order to clean up that piece. Thanks for the tip on looking out for errors, I'm guessing I'd see those in the log?
3) Pin 103 on the sbus out port can be used for RSSI voltage input which I have done with my DragonLink RX and it works. The sbus port is right next to the RC In port so I used the term neighbor. Sorry for the confusion. Can you expand on the "do not make groundloops" comment? I want to be sure I understand what you mean there. Is that accomplished by removing the 5V red wire? It seems you might mean the black wire since it's the ground but doesn't it need that for reference?
3: google is a good friend: https://en.wikipedia.org/wiki/Ground_loop_%28electricity%29
I realize this is a bit into electrical-engeneering field, so in short:
do not multipath ground , (especially with thin wires/loaded circuits).
-
1
-
2
-
3
of 3 Next