The last week or so we've spent porting a version of the AeroQuad AQ32Plus code over to run on the AshimaCore board. One of our goals has been to get a common board that can run (or has the hooks put in place to run) several of the more popular open source flight controllers. Here's some video (why did we do this at night?) of us flying on our own old aluminum frame and on a couple of different Turnigy quad frames (nothing crazy, just hovering mainly):
Flying with our new controller
Posted by Mark Richardson on May 17, 2013 at 5:30am
Comments
I think you have the problem on its head. Porting tends to expose bugs, bodges and poor architecture in extant flight control software. This ends up being good for everyone in that it provides a great mechanism for unearthing and fixing these things and contrib'ing back. Although cool in its own way, a second processor would just be a bodge put in place to compensate for an original bodge.
Flight safety is something we should all worry about and we need to be careful not to be putting home-made vehicles using software downloaded off the internet into a position where it can cause significant property and personal damage.
hmm I have visions of the multiwii boards when the code is bodged onto the boards. works poorly with the hardware, the code is not explained and is behind the newer code versions
I have two suggestions, Can you write one code for the board that is compatible with the different software packages so rather than modifying code which can be risky and is a down rite bodge in my opinion, you simply download the one set of code and it works with all the different software packages.
OR you make a "base" layer code that converts the chip and sensor data to the expected output for the code you flash to the board, so you can literally flash any firmware straight from its website repository unmodified and have it work , this could be done by having two Atm chips on board, the flight chip and the conversion chip. or one chip with a special ROM that converts the sensor data to the expected data for the software.
the reason i cannot use bodged code is because no mattery what it was not made for the board and so there may be a bug and that but could cost a lot of money when it appears in property damage but also in physical damage to people or animals.
Not to mention you have to rely on people modifying the variants of the code like Ardupilot and Ardurover which do not get so readily converted.
Really if you want something which is not just another multiwii i am expecting to see something like i suggested as simply having a bunch of the same sensor types but different brands would be kinda overkill,
It just greatly expands your freedom to play with different types of systems. We're obviously still dev'ing this, but the goal would be so you don't have to guess what flight controller software you might want before you buy your hardware. For some autopilot software systems, the boards also go into long periods of unavailability, and this then also provides a second channel for getting up and flying (I'm sure we'll have unavailability periods, but probably not the same ones).
cool idea but besides prototyping etc i do not see why you would need this?