But it may not immediately be apparent to a novice that DSHOT is the optimal protocol and BlHeli_S is the firmware in use.
A wiki overhaul is probably also warranted. The topics are logically laid out with respect to development topics and backend drivers (ESC protocol, ESC firmware, and ESC telemetry). But a single page laying out all of the info from more of an end user perspective would probably be easier to find/follow.
Thank you for clarifying this. I will try to read up on the documents posted to this thread and try not to miss these parameters as you were right in I overlooked a fair amount probably.
It is overwhelming at times seeing so many parameters to set and learning what they mean and their functions and consequences of entering the wrong ones.
ArduPilot succeeds in having massive configurability and flexibility - something lacking in some of the other usual firmware variants.
But where the other variants often do better is user friendly configuration. Betaflight, for example, does an excellent job of abstracting away much of the frustration. I’ve only used it a couple of times and had very few issues getting it up and running. But it’s kind of a one-trick pony. If you aren’t interested in pure FPV-style flying, have a unique physical configuration, or want a high degree of autonomy, you won’t get there with BF.
Even if you think a section doesn’t apply to you–read it anyways. There’s a trove of information in the wiki. If you struggle to understand something, keep on reading and come back to it later.
When you feel like you understand more than 50% of it, start at step one again, and this time configure your drone.
Ardupilot has a very steep learning curve, but just push ahead and it will start making sense at some point. Also just randomly read through the forum! Lots of unsorted information contained here as well.
I wasn’t aware if there were many other software especially for autonomous flight only. I knew that there is QGroundControl, however I don’t think that gave the option of autonomous flight and was only RC option hence why I switched to mission planner since I can’t use an RC.
It’s a project and it’s meant to be an autonomous drone controlled from mission planner. I’m meant to get it to hover at a certain altitude and then land for this project.
Thank you for clarifying that. To properly configure and tune the craft with an RC does that for it to fly properly and if I did use an RC for proper tuning would that help to fly autonomously if I tuned it with an RC but didn’t actually use it?
Yes. You really cannot perform the required actions with just a ground station. But, a Ground Station is sufficient to run an Auto Mission once it’s configured and tuned. However, it’s a good idea to have an RC system as Backup to take manual control when things go wrong. And things go wrong…
I suggested that as well, but the teacher insists on it being an autonomous drone as it’s for communications in carrying a base station on the drone. I had a feeling that an RC would be needed for proper configuration. I’m just hoping it’s enough for it to hover for a certain amount of time as I don’t plan to have other movements such as roll, pitch or yaw.
Describe the components on the craft (motors, flight controller, props, battery power) and it’s take-off-weight (w/ battery) and we can suggest a starting point.
Good to see a decent kit of parts. That’s a pretty heavy battery for that craft. You better weigh everything for a total weight including it and we can determine what the thrust/weight will be. It’s critical this is not too far off of 2:1 on the high side.
One good thing is there is a set of parameters available in Mission Planner for the X500V2. This will make it more likely it will initially fly.
What do mean by “base station on top”? I guess some payload that you will want to include in the overall weight.