Smoothing out the micro corrections
I just took my Mini for it's inaugural flights using Dronelink. Two flights based on the path command and one using Orbit. I'm using an iPhone 8. Everything worked great however I'm disappointed with the way Dronelink is sending what seems like micro corrections to the drone that look to be continually causing small jerks in the flight when the drone is curving from waypoint to waypoint. The resulting video is nowhere as smooth as what I can achieve with just manual flight albeit I would have to practice for hundreds of hours to make the accurate paths that Dronelink can. I have the waypoints set to Curved. Are there any other tips to reduce these micro corrections?
Example Here: https://photos.app.goo.gl/ioZcvMbBjuwBEFkP9
Comments
20 comments
https://www.youtube.com/watch?v=sfaZnqdPX8g some users are getting great success with running through a video stabilizer as is in davinci resolve
Thanks Andrew. I'm a commercial video editor by trade so I'm aware of most of the post production tools available for stabilizing footage. I was hoping for tips on what to do earlier in the process when programming the flight to smooth out these micro corrections.
I did read somewhere that when the MP2 came out they had similar issues with the SDK and DL so maybe it's something that will evolve over time with the Mini?? Fingers crossed!
Have you tried it on a faster mobile device? The internal command rate is 20hz, but if the mobile device falls behind and only achieves 5 or 10hz you might start to notice this (as described here).
This was my first use of Dronelink with my Mini. iPhone8 is all I currently have to experiment with. I was hoping there was a way to smooth out the interpolation points in-between the waypoints while programming the mission. Is there a way for a user to determine if the internal command rate is not nominal?
It already interpolates down to centimeters, which is not the issue. The control loop is allowed to operate anywhere between 4hz and 20hz. If it goes below 4hz, it gets 5 strikes and if the device cannot keep up, you will see the Device Running Too Slow message. Having said that, allowing 4hz may not be a good decision. The choice is whether to allow your device to operate at all (with sub-par results) or just immediately give you the device running too slow message.
Personally I would appreciate an error message that told me that the control loop was not operating at preferred frequency rate and that continuing would possibly result in sub-par results. At least that would give me a starting point for troubleshooting. While researching Dronelink it seemed like anything above an iPhone 6 was going to be adequate so I thought my iPhone 8 would be fast enough.
The system requirements state that you should use a device that was released within the last 2 years for the best results.
Also most people don't understand what "control loops" or "frequencies" are.
Yep! that's me :-)
Guess I'm destined to either give Apple more money or use some video stabilization after the fact. However getting back to control loops.....the user doesn't need to know anything about loops or frequencies. They just need some feedback with the threshold possibly set higher than 4hz that tells them that their mobile device is under powered. But I'm not complaining. For $20 my Mini can hit waypoints. I may be limited to using it for photos at the moment though unless I want to stabilize the video afterwards.
Today I have finally tested my first missions (orbit and path) and am also a bit disappointed with the result. I don't know if I have a too slow device (Snapdragon 845) but I would very much like to know what would make the control loop run slow. We are talking modern processors than can easily do >100 million floating point operations per second. Even with the most complicated and involved sensor fusion I don't see how you would need more than a few thousand operations per second for smooth flight. Even as a complete drone newbie, I can do much smoother orbits with basically keeping the stick positions completely still so the goal for the autonomous orbit is to converge on the 'correct' stick inputs as soon as possible and keep it there, ignoring the slight sensor noise. Correct me if I am wrong (I am certainly not a control loop expert) but to me this current jerky behavior seems like a problem with the control loop algorithm. Are you using a full PID? Looks more like a simple proportional control with very little input (GPS position) filtering. Do you think the loop can be improved in the future or is this as good as it can possibly get.
Otherwise, I love the idea and the way that the Dronelink is implemented. It's a neat and very flexible architecture. I just wish that the control loop could be better optimized.
It's less about how much raw processing power your particular device / processor has, and more about how much usable processing power is left over after all other factors are considered (the OS, background apps, battery level, ambient heat, etc). Then you layer on the fact that modern software uses programming languages that are 3 or 4 times higher level than assembly, which of course make it easy to program but have more overhead, and further complicate things by the fact that the Dronelink kernel is written in JS (so as to have one, cross platform codebase), which means it needs to run inside a sandbox and be interpreted all the time.
Having said all of that, it very well may be that your device actually has enough power and the reality is other factors are the real culprit. The Mini is very light and susceptible to wind, for example. We just ran several test missions last night on a brand new iPad Pro and did not experience any such issues.
I'm positive that the many algorithms that comprise the Dronelink kernel can be optimized to achieve even better performance, and in fact I have been endlessly pursuing this since I first started writing virtual stick applications for the DJI SDK back in 2014 with Autopilot (for the last 6 years). No one has been doing it for longer than me in this industry for the DJI SDK.
If I were to invest a bunch of time into this, the very first step would be to gather much more data in an attempt to isolate the variables. For example, write a simple loop that sends a constant strafe velocity combined with a constant yaw velocity, and see if the Mini can pull that off without "sudden corrections" (which everyone so readily attributes to my code). If the wind or latency make something simple like this impossible, there is no hope. But of course I will need to do this with a wide variety of mobile devices and in a wide variety of environmental conditions (low, medium, high, wind, etc). The bottom line is: this can be extremely time consuming, and the one thing we know for a fact is that larger drones and faster mobile devices seem to suffer far less or not at all from this issue. Again, not saying there aren't Mavic Mini specific tweaks that can be made to the algorithms, but making such modifications incurs another toll (regression testing) on all the other drones and devices.
The final consideration when making a decision to spend a bunch of resources on something like this is: what are the majority of the users asking for / complaining about? At the moment, the % of people having this particular issue is relatively small compared to the % of people asking for new features like follow mode and uploading waypoints (non Mavic Mini of course), or even just written documentation. One thing you can be certain of though: I will never stop trying to make Dronelink better nor will I stop listing to our users. I have been doing this for years already and have the track record to prove it.
Thank you all for being so interested in my work and having a passion to help me! If any of you are software developers and are looking to join a fast-paced startup, let me know!
Thank you for the extremely detailed and fast reply, Jim! Don't get me wrong, you did a terrific job with the Dronelink. I am not much of a programmer so don't put too much stock in what I say but It's hard to believe that CPU can be a bottleneck in this situation, even with high level interpreted languages like JS. Doesn't the drone's on-board processor handle balancing and any wind influence on it's own? It certainly does while flying manually. Even with the tiny MM, smooth stick movements always get translated to smooth drone movements. I certainly don't have to make any sudden and high frequency corrections while doing a manual orbit to get perfectly smooth results, even if it's moderately windy. If the SDK really controls the drone through virtual sticks that send the same type of data the controller would normally be sending, then it should be possible to get better results with a better algorithm.
Are you using the PID control or something similar? I don't see why the drone shouldn't relatively quickly converge on the 'correct' set of stick positions (specially for the orbit mission) and not keep oscillating around the ideal curve. Maybe make a test where the drone uses the first orbit to calculate the average stick positions needed and then do another with those fixed stick positions.
I understand that your time available to develop any one feature is very limited but excellent and flexible core loop should be pretty high on the list. Let us know if there is anything we can do to help.
Not sure how else to explain it. You keep zeroing in on CPU and I am trying to tell you there are many other factors that could be the cause. Again, the only data point we have for sure is that the issue does not happen on larger drones and with faster mobile devices under the same conditions. I'm not saying we can't try to make it better, just trying to give you the facts.
No, I am quite willing to accept that CPU is probably not (or at least shouldn't be) the main issue, specially for simply missions such as the orbit. I would be vary surprised if the original controller was doing complicated calculations and corrections and sending them to the drone just to keep it flying smoothly. If manually fixing the sticks to a certain position gives you a perfectly smooth circle then the same should be possible through virtual stick control. For the orbit mission, once the control loop zeroes in on the correct values, even a <4Hz refresh rate shouldn't be a problem as you basically just keep sending the same set of numbers or am I wrong in my understanding how virtual sticks work? Looking at my orbit video, the slide / yaw oscillations and jerks don't seem to be getting any better as the orbit progresses. That tells me that the algorithm possibly doesn't integrate enough of the past errors in the correct output calculations. That's why I have asked if the algorithm only considers the current drone state ('proportional' control) or does it also take info account the past curve it has traveled and from those used values tries to extrapolate the set of parameters needed to smoothly continue the curve. The calculated output should be a combination of extrapolation from the past values and a new input from the drone. I am definitely not saying I would know how to write a better algorithm but from my _very_ limited experience with control loops in robotics, these kinds of oscillations and instability I had when I have used a wrong type of control loop or had badly tuned PID parameters. Maybe I am completely off target and I am sorry that I don't know more about control loops to be able to offer some actual useful advice. I just basically wanted to check with you do you think that this is something that can be improved in the future or are there some obvious problems with control exposed through SDK that would make a truly smooth curves impossible.
PS: As for the documentation, yes please! :) There really should be a reference manual.
Like I already said multiple times, I do think there is always room for improvement, and yes it is a real PID.
Hi - I'm also a new user flying the Mavic Mini. I'm just wondering if there is a command to set the rotation speed of the drone? I can set the max fly speed and gimbal speed, but it seems like the rotation is super fast. Maybe slowing this would reduce the jitters? thanks!
https://support.dronelink.com/hc/en-us/community/posts/360049314013
Settings for rotation speed / accelerations are at the plan level (...).
Please sign in to leave a comment.