wow that is pretty impressive how it records the stats.. that has to be helpful in developing..
Yeah, that was one of the first big changes they did so they can get more consistent and reliable feedback from users to determine what needs fixing where and how. GCS also has tracking built in (which you can opt-out of when you install it) which reports back and helps then track usage. *flight actually does that too but doesn't really tell you and doesn't give you an opt-out option - but they use google analytics in the configurator app which reports back when it's being used and how.
The autotune reporting really rocks though. You can even follow the link at the bottom of an autotune to get the full details about the setup that was used. So for example this was my autotune on the angle arm UMBQ:
http://dronin-autotown.appspot.com/...hdXRvdG93bnIYCxILVHVuZVJlc3VsdHMYgICAwO6_gQoM
You can see that I had a 31ms Tau which isn't very impressive...but keep in mind I'm not running oneshot or damped light on that due to the old "simon series" emax ESC's on it. My hover is at 16% which again isn't bad but isn't great. Predicts 29883 is how many measurements the FC took during the 60 seconds of autotune and Spilled 0 means that the FC was able to keep up and measured every data point it expected to (if you see anything but 0 in there you're loosing data and are unlikely to get a good tune - that happens for example if you raise the gyro rate on a Naze32 or CC3D and the CPU can't keep up.)
There's ongoing work to build a system for comparing tunes so we can better detect if a tune was "good" or not - the problem is there's no standard way to enter things like motors and ESC's - though one of the dev's who works at google has done some slick stuff to help sanitize those fields.
But you can also click the "raw data" link down at the bottom:
http://dronin-autotown.appspot.com/...hdXRvdG93bnIYCxILVHVuZVJlc3VsdHMYgICAwO6_gQoM
That's probably kind of hard to read...it's raw
JSON data as reported by GCS to autotown. This plugin for chrome makes it MUCH easier to view:
https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc?hl=en
But basically what you see in there is the equivalent of a full CLI dump from *flight, everything you'd need to replicate the setup is listed there and it's possible to make an import script that would format it so you could import it from GCS to duplicate a configuration.
the more i read the more impress i am with dRonin. the future seems brite for the firmware and to be honest its development time is quite impressive.
What I love about dRonin is that it takes everything I love about Tau - but is far more focused on usability and increasing user friendliness. The ultimate goal of the dRonin devs is to get it to where setting up a new multi is almost completely automated - you just answer a few simple questions and it does the rest. Tau and dRonin are both great in that they're very data driven - they approach things from a more solid technical basis than *flight which takes more of a "lets just toss things at the wall and see what sticks" kind of approach. They're also more focused on good development practices, CF uses CI like dRonin does (details here:
https://dronin.readme.io/docs/using-automated-builds-from-jenkins) but some of the other *flight versions don't.
The underlying structure is also more modern. OP/LP/Tau/dRonin all use a
RTOS instead of a main loop like *flight. That helps make things more modular and consistent and is why "looptime" isn't really a concept for them. Instead it's data driven, an interrupt from the gyro tells the flight software when new gyro data is ready - with *flight and a loop instead they just read from the gyro as fast as they can whether it's new data or not. (that's a major simplification but this is getting long already!) there's been a lot of work on raceflight/betaflight to add a scheduler which gives some of the functionality of a RTOS but it's basically just still tacking hacks on top of hacks instead of starting with a clean design from the base.
For something as complex as what *flight and OP/LP/Tau/dRonin have become the RTOS makes a lot of sense. On the other hand there's still something to be said for the approach KISS takes and going for a far simpler architecture - as long as you keep things simple and focused. Once you start adding on extra features though that kind of approach can quickly deteriorate. In some ways it's analogous to functional vs. object oriented programming with *flight and KISS being more of a functional approach and OP/LP/Tau/dRonin being an OOP approach. Functional programming is much quicker to get up and going with - but can quickly become a mess as functionality grows, while OOP is a lot more overhead getting started...but once things build in complexity it greatly streamlines and simplifies maintenance and adding new features.
