Pixhawk 2.1 (cube) unreliable? Not stable with ArduCopter? Strange issues with various units. LIDAR refuses to be detected

ArduCopter Copter 3.5
, , , ,
1

So I am starting to think the Pixhawk 2.1 is simply not reliable or ArduCopter is still not stable on them. I so badly want to like them but every build I do with one there is some problem or another.

Here is the deal. I am building 2 identical drones. Both have Pixhawk 2.1 units obviously.

I am using a TF Mini Lidar for simple avoidance - on the first unit it worked both serial and with the i2c Arduino mod.

The second unit refuses to detect it in either configuration - even tried cloning the working config. Tried reflashing the firmware, resetting to defaults and a host of other diagnostic steps including flashing the PX4 stack and reverting back to AC3.5.5.

The odd thing is that if I unplug the GNSS and plug in an external i2c LED it works fine (by design the LED will not work when the HERE GNSS is plugged in). The telemetry 1 and 2 both work fine for the 915MHz transceiver so I am doubly confused.

The only difference between the two units is that the working one has an Edison carrier board (no Edison) and the other does not. The one that is the “standard” is newer.

The system refuses to acknowledge there is a LIDAR attached. Nothing works. I even tried changing the base address in the Arduino hack. Serial is no joy as well so I am lost here.

How can i2c be working for an external LED and serial be working for serial telemetry but not for a simple LIDAR that works fine on another 2.1 running the exact config and firmware?

If I enable CLI on the misbehaving unit I can test the rangefinder and it gives accurate readings. It just refuses to show activity in Mission Planner. It is as if the rangefinder code is not loading unless manually triggered by the CLI test. Is that even possible?

One indication of that is if you enable a LIDAR rangefinder MP should complain about bad LIDAR health if it does not “see it”. This is not happening on the unit that is giving me issues.

I am confident I2C is working and that the serial ports are working since I can use GPS, Telemetry and the external I2C LED. Like I said; it is almost like the rangefinder code is simply not running (I am sure there are drivers or something in the firmware to interact).

Is this at all possibly a software issue or hardware? I just don’t get it. I am both confused and frustrated at the now 19 hours I have spent on this.

Any help would be greatly appreciated.

2

I dunno man, you pretty much insulted the very people who you will need help from.
You might want to read some of the other posts on here that get help and try rephrasing.

2 Likes
3

I sincerely appreciate your input. No disrespect intended - I am being honest and direct regarding my experience with the PH2.1 and it is a legitimate question. I am not the first to raise concerns about the 2.1 either.

I would hope the reader could see this exactly for what it is. An question influenced by an opinion based on observation and NOT an attack on any persons character, ability or otherwise. To suspect the PH2.1 may be “junk” is not personal; it is an actual possibility. I hope I am wrong - as stated in my post I SO WANT to love this unit. It has a robust array of features.

I appreciate some my not prefer honest opinions/questions but again it is not disrespectful to be honest and I am not sure how to be honest and phrase the questions raised any better. If one of every 3 or 4 units I purchase (which to date has been 26 units) has had issues there is something wrong. Support is difficult and vendors, at least the ones I am buying from, are not helpful with returns. I am personally out a considerable amount of money on units that don’t work as expected - like one I received last week immediately reporting BAD GYRO and BAD BAROMETER. My opinion, phrased as a legitimate question was isolated to a title and one sentence and does not reflect the entire subject - only a portion.

To elaborate on that sentence in question in my post for context:

My position is that when one spends 200 to 350 per unit and has a dedicated system to program them, a lab quality environment and all the right tools for fabrication in a professional manner, when one goes wrong for no apparent reason and happens at a 1 to 4 ratio it is more than likely an issue with QC on either software or hardware. It is possibly reducible to a non reliable piece of equipment. I have used as much empirical evidence as available to rule out user error and all data indicates an issue with the units or the software. Just trying to be factual.

Thank you again for your advice and I truly thank you for taking the time to help but I must stand by the legitimate question raised here as it has no meaning other than being a question and I certainly hope nobody is so easily offended as to not actually read the post and address the question as to the reliability of the PH2.1

It is a pleasure to make your acquaintance and hope I can return the favor of your contribution is some way some day.

Warm regards.

4

I think @pyrate was referring mostly to your choice of words in the heading, which I was going to reiterate but now see you have edited to reflect your posts content.
It is just so you will attract the right attention to get the answers you desire, that is all.

Now this is a shot in the dark, but I had hair tearing months with a couple of PH2.1’s and it turned out to due to a combination of a faulty lead and an intermittent I2C expansion board.
I personally am not a huge fan of MP on Windoze but it is very capable and the easiest to setup and adjust a PH.
But it does have it’s idiosyncrasies. Sometimes unexplainable hiccups.

When I now have issues with units as you describe I first strip everything back to just the PH and the troublesome unit, get it working, and build forward from there.
I know this is probably just as you have done.

A good start would be posting some log files of your tests so hopefully a Dev can have a look and offer some suggestions.
I am sure they would be interested in getting to bottom of just as you are.

Good luck with your investigations.

1 Like
5

Thank you Mike. Yeah - I was perhaps a little too frustrated when I originally posted. The PH2.1 is awesome when they work and a royal PITA when they don’t.

You are correct in assuming it was all stripped to basics, different components used and so on. We make our own cables (bought a machine that ends various leads we use and we have a continuity tester for each cable we make (but I replaced them anyway). Logs on the way (I looked - there is nothing specific there - like rangefinder isn’t even there). The rangefinder refuses serial as well ruling out I2C being the only issue. Other devices have now been tested and function on i2c and serial though.

I am starting to lean towards the rangefinder code not loading for some reason. If I understand correctly (which I may not in my fast read of how the code and stacks work), when you enable a sensor there is a mechanism in the FW that enables code that allows it to communicate on the system/user level like a driver of sorts (doing a bad job here of explaining what I read so forgive me). The CLI is lower level if I am understanding this right - sort of like a interacting with a bios. The hardware is shaking hands at the lowest level and I can interact with it in the terminal but I know when I am at user run level the sensor is not picked up. So the low level sees it and reports it. The mechanism that allows the system/user to interact with it appears broken. Just a guess and a poorly worded one at that - lol.

If not MP for an setup what do you recommend?

Thanks so much!

Gio

6

I have to admit I have a lone PC laptop in the workshop that runs MP for all my setups.
Flight planning and monitoring in the field is also using MP.

I do all my analysis and graphing on APM Planner in the office.
When MP stuffs up and will not talk to boards (Pixracer is a good example, and the new version of MP would update one Pixfalcon but not an identical setup) I go to APM Planner.

I have been looking at QGC as an alternative if I can get it running on an RPi, which someone has just posted a solution to but they are doing under Ubuntu.
I use Mac wherever possible so hopefully there is not much difference in the recipe between Ubuntu and other *nix.

1 Like
7

I am a Mac junkie myself…

I use a highly modified QGC for flight. I like it for the field. Not so much for settings.

The main reason I use our build of QGC is that we made an HDMI video device that sends 1080P video to the ground via RTSP with almost no latency - about 200ms average and we get a range of several miles - perfect for search and rescue, scouting and so on. QGC has a built-in mechanism for this.

It is actually pretty neat. I got tired of buying the 1500.00 Connex HD system, getting an HDMI USB 3 device, attaching all that to my remote and so on.

Now we put a specialized iMX6 SBC with HDMI input, a custom PWM HDMI switch to go from thermal to standard camera and the SBC takes Mini PCIE cards so I can send video 5G, 2.5G, Cellular, 800, 900 - you name it.

On the ground side I use an X9E (since it has a ton of room inside) and I add a telemetry device connected to BT so the tablet can connect via serial BT to the UAV (can also control the UAV from QGC alone). Also inside the unit is, for standard setups, a high dB diversity 5.8G wireless card with antenna that run external. The only cable between my remote and the tablet that runs it all is a USB 3. So the setup is super clean.

I highly recommend QGC as Daniel, Don and others have done a tremendous job with it.

1 Like
8

Hello,

How are you powering your Cube with usb or battery ? Usb powerline can be weak …

1 Like
9

Thank you for your reply. I am using battery. The LIDAR is wired in such a way that requires the battery (have a 5V 5A regulator that is powered from the 6S).

Everything but the LIDAR works. PH just doesn’t see it unless I am in terminal using CLI.

10

I didn’t see anywhere that you tested both sensors on both quads ?? Base config for the senor(s) itself?

ptegler

1 Like
11

Thank you for your suggestion and I am sorry for the late reply. Yes I did - first test was a swap. I should have mentioned this. Also on a non cube Pixhawk both LIDAR units work in both serial and I2C so there does not appear to be an issue.

Interestingly enough I now believe it is a firmware issue with some rangefinders. The first drone with a PH2.1 was working fine and after a firmware update to 3.5.5 it stopped. I Believe I was on 3.5.4 from November but so far I have not been able to find it. It is not listed in previous versions in MP so I will have to track it down. I am not certain but I know the first PH2.1, the working one, was on an older firmware from late last year.

So the latest firmware appears to break the rangefinder (at least for me). I will try a few previous versions to see what happens to be sure as I am aware correlation does not imply causation. I need more hard data.

12

I think you may be on the right track.
There were some issues if I recall correctly about the order in which drivers are loaded.
I have also noticed a few issues with 3.5.5 on Pixfalcon where the previously working M8N GPS now takes up to 10 minutes to satisfy the EKF where previously it was only 2 or 3.

1 Like
13

Thank you for that information! It is a bit if a sanity check for me :slight_smile:. It looks as if there are several things not quite right in 3.5.5.

I have been on another project as of late but I am getting back on this sometime this week. I intend on trying to confirm that the FW upgrade was the issue.

Strange. Now that you mention GPS, perhaps it is my imagination but it appears the GNSS is taking a bit longer too.

I will post some updates when I get a chance to more thoroughly test everything.

14

I fought this myself about 1 week ago. I’m also finding many of the same things as you and @mboland mentioned.
I’ve had a real go with PH2.1’s being far more finicky and downright odd in behavior.

Anyway…
Haven’t had my big rig out since Fall. Loaded newest AC and went to checking everything.
Pixhawk 2.1/Cube. Lidar is a SF11/c on i2c (so this may not even apply to your situation).

I’d moved my rangefinder on my rig. Found it was too close to the receiver and it was bugging it out. It was 5" away, but only by moving farther was it able to be discovered.
Moved it back to the original spot, however, I found it to be buggy. It was intermittent.

After replacing cables, rewiring, and other things, I eventually found that I needed to remove the redundant ground/neg I was using to the i2c connector. Odd, since I’ve changed nothing else, and it worked just fine prior to this, but nonetheless was the solution. All works fine now.

This was MY experience with it. Just figured I’d add it in.

1 Like
15

I will give this a try. Thank you SO much for sharing your experience. Hopefully this helps the issue. I am now back on the project so I am anxious to give this a shot but my situation may be reversed.

You had a redundant ground to the I2C 2. I am using the cable to the I2C 2 splitter and then to the device but I am only running supplemental power from a regulator. I hadn’t thought to remove the power from the PH to the splitter.

This may explain why even plugging in direct - not using the splitter - the device didn’t work after the FW update as well. I have 2 power sources - even if coming from the same source (the battery) this could indeed cause a conflict. I am going to try separate power and ground entirely! This is a GREAT idea. I can’t thank you enough.

I will report back with my findings.

16

There we go again, emotional shields up every time a perceived criticism of Pixhawk2.1 is made.
This political correctness is a true disease. There is absolutely nothing offending in what the poster expresses on his experience using Pixhawk2.1 and it does not feel at all like an attack on anyone.

17

hundred ways you can say things, I typically chose my words better when asking for assistance
that is not political correctness, that is civility