Wednesday, March 23, 2016

diversionTx - a fork of deviation

Introduction

Over the last year, I haven't blogged much because I've been working on deviation - the open source firmware I use on my rc controllers. Over the past few months, I've been thinking about forking it, and finally decided that I really need to do that.
Not that there's anything wrong with deviationTx as it is, it's just that the current project leader and I have radically different goals for what we want from the project. More than once, this has prevented changes I - and others - have wanted from making it into the deviationTx code. So at this time, I'm announcing a plan to create diversionTx as a fork of deviationTx to get feedback from the community.


This fork is not happening. The original project is moving to deal with these at least some of these issues.

The goals

My primary goal is to make things easier for the DIY'er, even if it means dropping support for popular transmitter models. Along the way it should incorporate some of the changes that the user community expressed a desire for in the survey I ran a while back.
A particular strength of deviation is it's ability to support a wide range of protocols. That shouldn't go away, and at the very least the diversionTx project will track those changes. Ideally, the protocols will fork into a separate project that can be shared between the two, as well as with other projects that are currently porting protocols to/from deviationTx.

Technical changes

To do that, the major changes are going to be to the configuration software. In particular, having tools to edit the configuration files on the desktop, and hopefully on portable devices with OTG support, and possibly even web based. This is a desire expressed in the survey. This would also allow for versioned configuration files that could be updated from an old version to a newer one by the desktop software when the user updates diversionTx.
The primary configuration change would be moving as much of the hardware configuration as possible out of software and into the hardware configuration. It should be possible to add switches, buttons and analog inputs just by editing the hardware configuration. One target of this would be the ability to use standard build on a Devo7E with an upgraded processor as in the "Ultimate 7E" project.

GUI Changes

For the record, the standard GUI has got to go. It was crucial when first written, and still useful for collective pitch helicopters with flybars, but little else. The features that make that setup easy are simply confusing for a modern 'copter with a flight controller, and it's impossible to make use of the more advanced features of those flight controllers. It's also relatively large, making it a problem for the 7E and similar controller. These two combined are why it's got to go.
Should someone step up and take ownership of it - at the very least stepping up to provide a new mode for modern flight controllers in the "Multi" aircraft type, and hopefully support for fixed wing aircraft - it would be worth keeping around if the results can be made to fit. Otherwise, it's gone.

Community changes

I would also like broader community participation to be possible. In particular, the web site and other major sources of information should be editable by the users, not just by a select few. User contributed howtos and tutorials and the like should be editable by all users and given broad exposure. Good documentation that for whatever reason isn't added to the community supported pages would be relegated to a page listing such. That page would of course be user editable so outdated resources can easily be removed.
Similarly, I would like better community involvement in the build & release process. Making it easier to do custom builds is a goal. Possibly even a web-based build system with the ability to select features to turn on and off. The release process also needs to be documented and accessible. In fact, along with the ability to commit to the official source tree will come the requirement to monitor the official builds, and fix them should you break them.

Release changes

The release strategy should leverage the advantages of the open source bazaar better by having three different levels of automated build.
The dev build would be similar to the current nightly builds. Ongoing work that is deemed ready for broader public testing. Most changes to it should have gone through a developer-run test phase and then a code review. This would be for more hard-core users, who are following the community fairly closely.
The doc build would incorporate changes from the dev build after some period of time - say a few weeks. They would also require that any user-visible changes be merged into the documentation at the same time. This would be the default install for most members of the community, as it should be properly documented.
Finally, the fixes build would be branched from the doc build whenever the configuration file version number changed. After that, it would get bug fixes - and only bug fixes - from the doc build. This would be the proper build for a first install, or for someone who only looks at the community when things go wrong.

Transmitter support changes

Transmitter support will be a bit more formal. If an error prevents building software for a transmitter with primary support, the entire build would be considered a failure, and the distributions wouldn't be updated. If the transmitter only had secondary support, the build would continue and there just won't be a software for that transmitter in that build. Unless somebody steps up to support a transmitter, it will only have secondary support.
I will support the 6 and 10 directly, and as much as possible the 8 and 12.
The transmitters with limited memory - the 7E, F7 and F4 port that's under development - have more than once side-lined desirable work, and avoiding that is a major point of the fork. I don't own one, so really can't support them. Unless someone steps up to support the limited memory versions - and will take responsibility for cutting features when the build outgrows them - they will get at best secondary support.
The case for the video transmitters - the F7, F12E ongoing F4 port - is the same. While I would like to support them, I don't own one and can't justify the expense, so can't really support them, so they will get secondary support unless someone steps up to handle them. An F7 or F4 would be an ideal transmitter to have for supporting both the lesser cpu and the video transmitters.
Hopefully, the hardware configuration will make supporting new, similar transmitters easier, and allow folding some of the secondary transmitter builds into a build with primary support.

Roadmap

The first step will be setting up a diversion build that uses updated tools and libraries, and moves the documentation build into the source tree for the doc build. The split in support status should happen then as well.
The first change will be to remove the standard GUI, or at least disable it, and merge in the new toggle code. That would probably be the first build that would qualify as a fork.
The second change - and test project - will be rewriting the current sound.ini file to use the proposed new configuration system, along with an editor for it. Extending it to support the in-development ability to use an external audio player to play back sound files is the primary goal here.
Once that's working and we have a desktop editor, the next step would be to see about getting mobile apps for editing config files, so they can be done in the field.
Assuming that works, the first major step can be taken - sucking in hardware.ini and making as many things as possible configurable.
And then - well, we'll see.