I wanted ardopilot so bad but Im completely new to all this. Setting up a Nano Talon and couldnt get the BN-880 setup in Mission planner. After half a day of my life wasted, I switched to INAV and followed their tutorial. It works… Dont think I will be looking back!!! See yall
should just get a plug and play with if you don’t want to deal with stuff like this. I’ve never had to “set up” a GPS other than just plugging it in. iNav is cool as well though so best of luck to you
After having gone through the same issue (and being far from new to the hobby), that’s a terrible attitude. I put most of the blame on the cheap BN-880, but why doesn’t arducopter have the most basic tools to allow one to sort out these issues? A simple 3d display of the aircraft orientation would go a long way to providing a user confidence that the sensor configuration is correct.
Sorry, but what is so hard to look at a simple artificial horizon and a direction indicator ? I don’t want to be mean, but if a user needs a 3d display instead of these to get confident in aircraft orientation then there will be much bigger problems…
You’re really going to argue against making something easier and more straightforward to “weed out the dumb users”?
Of course you can get the information from the pilot display, but a 3D display gives you exactly what one needs in a way that we are used to and is obvious. You hold the model in your hand, spin it around, and the display model does exactly what the real model does. Do you not see a benefit in that?
Well, IMHO the added value of a nice 3D spinning model is exactly zero. Let me explain. You can indeed verify the gyro and the accel configurations with it, but ArduPilot has a supported board list and firmwares are compiled for a specific board with accel and gyro orientation baked in. So to have a wrong accel or gyro orientation is highly unlikely.Plus, most of the boards have 2 or three set of sensors and you can run multiple versions of EKF paralel with multiple set of sensors, a small 3d plane graphic does not give you any plus information, but if you rely on that only it can give a false sense of confidence, unless you go through all sensor sets and all EKF versions running.
The origins of that flashy 3d model is dated back to the Multiwii era when we built our flight controllers from scratch with sensors from Wii controllers. Having a quick way to check of correct sensor orientation was important back then. But with ArduPilot and mass produced controllers this has almost zero possibility.
So spending developer time on something that has no real value, just fancy, is waste of resources.
Regarding to “weed out the dumb users” Yes I would really like to see less dumb users (not inexperienced ones, but heavy weight, Karen level dumb ones.) like the one who cannot comprehend the simple concept of TX goes to RX and RX goes to TX, or the ones that disable arming checks and then complaining of loss their copter due a configuration error.
I see more and more developer time spent on making configuration more fool-proof and more and more dumb users who happy to circumvent any warning and protection. If they lucky they only lost their small copter, but what to do with those who build a 25kg octo as their first try. They endanger themselves and innocent bystanders. So yes I want to weed out dumb users.
3 Likes
Yes. This where the rubber hits the road:
So spending developer time on something that has no real value, just fancy, is waste of resources.
There was a post that went on for weeks/months about “Enhancements to Mission Planner” but IMO it was mostly fluff. And it didn’t go anywhere. The professionals using Ardupilot don’t need it and the hobbyist would learn a lot more by understanding the nuts and bolts of of the system rather than a layer of dummy proofing on top of it.
4 Likes
You do support boards other than Pixhawk, some of which don’t have an integrated magnetometer. Even if they do, it’s very common practice to locate the magnetometer away away from the ideal location of the flight controller due to magnetic interference. Oh, wait. I actually have two commercial ardupilot platforms that have such a configuration.
If you don’t plan to properly support such configuration, then I suggest you remove the capability from your repository and not list such hardware/configurations as supported hardware. There are others that are perfectly able to support the more diverse hardware.
FWIW, I’ve been involved with both developing for and flying multicopters since when arducopter was actually running on an Arduino. This is exactly the kind of attitude that has kept me away from ardupilot.
The only reason that I’m trying to better understand Ardupilot is because I now have to support a rather expensive airframe that runs Ardupilot, but I want to have some degree of confidence that I understand how the hardware/software is working before I risk flying it.
Lacking some of the most basic diagnostic tools doesn’t give me much confidence. Maybe it’s okay to just arm it, give it throttle and give it a toss, but I can’t believe that adding additional diagnostics displays is a bad thing.
I have no issues with the opensource developers, since I am one myself and I respect that it takes time and everyone has their priorities, but to out-of-hand reject suggestions for improvements just because they don’t fit your model of what the ideal user is, is ridiculous, especially when you’re using commercial interest to justify decisions for opensource projects.
If you want to produce commercial grade products, then don’t don’t rely on the services of opensource developers, or compensate them appropriately. Pixhawk hardware has enough of a cost premium over hobby-grade hardware to support development of a professional-grade configuration application, and commercial users that are spending thousands of dollars for aircraft, not including payload, deserve better.
Okay, since you conveniently ignoring complete sentences from my post, let me dramatize it for you.
User: I want a spinning 3D plane display to check magnetometer orientation
Developer: Sorry, but magnetometer has nothing to do with attitude of the craft, we use gyros and accelerometers for that, magnetometers give only magnetic orientation and we display it on a compass, all you have to check is the movement of the compass when you rotate your plane.
User: But it is too complicated, I want a spinning 3D plane, 3D graphics are cool.
Developer: As said, magnetic orientation cannot be displayed on a 3D plane, but you know what, I give you a single indicator that shows discrepancy between the attitude and magnetic orientation, all you have to do is to rotate your craft and check this indicator, if it goes to red, then your compass has wrong placement. We call it EKF compass indicator.
User: Broaf, I have to click on it to show, not good. I want my 3D plane.
Developer: Sorry, I cannot imagine how to display magnetic orientation on a 3d attitude indicator. But since we have many users who does not care about compass orientation we added a function that automatically detect and correct compass orientation during calibration, new releases will have this function turned on by default. Isn’t it great ? You don’t have to care about compass orientation.
User: Noooo, I want to check my compass on a 3d plane, why is it so hard to understand ? I don’t do calibrations anyway.
Developer: Ooookay then, what about an intelligent algorithm that can detect and correct compass orientation errors in flight, within seconds? I just added it to the master branch of code.
User: Pfff, you are sooo stupid, and cannot understand users. I rather go and use another autopilot.
Developer: Well, it is your decision, have fun.
6 Likes
After spending much more time in the field with a plane that has three compasses, each of them generally pointing a different direction (even after calibration), I can say that any additional help debugging and fixing compass issues is not wasted. Just getting an indication that your compass is not oriented correctly does very little to figure out what the problem is.
All those improvements that you describe sound very good and reasonable. Is there documentation on those? I can’t find any.
Oh, and the magnetic field does in fact exist in 3-space. In fact, your advanced compass celebration describes moving the craft around in 3-space to ensure that the values are changing appropriately, which, of course, would be easier and more accurate with a 3-D visualization…
I’m new to flight controllers, but a year or so ago I must admit that after countless failed compass Cal attempts I had to load px4 fw just so I could see the x y and z values of the onboard compass and the external compass so that I could determine what mistake the chinese had made orienting the internals of my gps mag chip.
I couldn’t find the live values anywhere in MP and I go sick of guessing what variation of compass orientation to use when both the FC and gps/mag were installed matching.
Once I worked out with px4 that it was a roll 180 I went back to MP and happy days.
If we all used propper hardware not chinese rubbish BG specials then we wouldn’t need this info, just install the hw and select the appropriate orientation.
1 Like
Orientation is automatically determined. It’s what the parameter compass_auto_rot does.
Yes, I guess I was trying to ‘take out all the variables’ so i selected the (what should have been) appropriate orientation manually, but due to manufacturing stuff up of my gps, the flight controller would never cal the mags successfully.
But you are correct. If I had have let it do the auto orientation, it would have picked up the error and worked fine.