Baseflight aka multiwii port to stm32

[nicodh]

Hello,

It's been a while since Timecop (RCgroups) created a board called naze32 wich is multiwii compatible.
There is a firmware, that works, and is based on multiwii. It's called Baseflight.

For instance it has the same features as multiwii but with the additional cli mode which makes easier the life to change types, and a lot of other features like PPM failsafe without the need of recompile every time.

The starting thread for all this is here:
http://www.rcgroups.com/forums/showthread.php?t=1595761

And some tools to work with all the features of the baseflight soft exists.
naze32 AIO which combines gui and cli and firmware download and update. And of course the naze32 android BT configurator.
the info is findable here. http://www.rcgroups.com/forums/member.php?u=342216

I think it's important to understand that TC put a great effort on this port on his side at starts. And I think it's a good Idea to continue his work.
Of it's opensource and you can find the repository here: http://code.google.com/p/afrodevices/so ... baseflight

See you.

[copterrichie]

Kudos!

[Hamburger]

Yes it is a good starting point.
But I do not want forks but one multiplatform MWii source tree.

[copterrichie]

Yes it is a good starting point.
But I do not want forks but one multiplatform MWii source tree.

I am not sure of the reasons but Doug has his own source tree.

[Hamburger]

With all the problems of separate forks.
Porting new features over required
Missing features
Constant workload for syncing

[copterrichie]

Well, that is all being done now. Up until now, he has done all of this without anyone's help.

[copterrichie]

Additionally, what I am saying, every time there is a new Development or Official release, Doug ports it over to the STM32 sometime,within a matter of hours.

[nicodh]

That's right. Tim is really fast on updating. Well, he updates just what he likes, and others adds features like sonar or gps.
There is another thing going on, a new start from scratch development. With a lot of potential, but for now it's not on any repository.

[Hamburger]

The good thing with baseflight is that it exists and is working. To my knowledge it is the only fork of MWii that has made it into a working flight controller project and for some time too.

that is all being done now. Up until now, he has done

yes, that is part of what I call a problem in the long run. It _needs_ doing, because it is separate forks.

he updates just what he likes

yes. So not all features from arduino-mwii make it into stm32-mwii. Last I looked the entire LCD & telemetry stuff was not there.

Besides, there is no 'backchannel'. New features from the stm32 fork have no designated mechanism to become part of the arduino-mwii in an orderly fashion.

That's all rather typical with forks and it is one of the reasons I'd rather see one multi platform MWii source.

[tovrin]

please excuse my ignorance, but I'm very interested in this project, and have a question about the topic in hand.

TC has taken code from here and created his own fork, doing his own thing using MWC code. all fair within the rights offered.
What is to stop us from taking a page from his book and creating our own fork, here, using his current code that members of MWC work on, and he continues to do his own thing, and we can merge as needed, and likely help each others code get stronger. or so it would seem on the surface.

seems straight forward to me, but I'm uncertain of the code of ethics and standards of practice, etc involved.

[Hamburger]

- no legal problems
- maintaining two forks in parallel over long time is not desirable- about twice the work, never in sync, etc.

[tovrin]

ok, so its will TC move his branch here and allow MW Community to help code, or do you start your own fork and deal with potential inefficiencies?

what we need is TC on the forum adding his $.02, right?

[dr.tom]

if you read what is written here...
http://www.rcgroups.com/forums/showthre ... st22208331

it looks someone else must integrate MS5611 sensor into baseflight
or at least write driver folowing timecop's rules.

+ integrate new Marbalon's code for althold using accZ+baro

what we need is TC on the forum adding his $.02, right?

timecop is already here, but under dong username

[itain]

it looks someone else must integrate MS5611 sensor into baseflight
or at least write driver folowing timecop's rules.

dr.tom, I think you are missing the major point here. It is about doing changes to MultiWii so that:
a. It will be portable to other architectures and other development environments.
b. Every new feature (and that includes new sensors, flight modes and more) will be automatically available in all supported architectures (except those architectures that do not have enough memory or IO to support it).

Personally, I do not think that timecop's port is a good base for this. He has ported parts of MultiWii to a specific board. Adding the missing features and making it run on atmega328p again may be more work than doing the required changes to the current codebase.

[copterrichie]

Personally, I do not think that timecop's port is a good base for this. He has ported parts of MultiWii to a specific board. Adding the missing features and making it run on atmega328p again may be more work than doing the required changes to the current codebase.

In addition, not bashing TC because he has done a fantastic job at porting the MWC to the STM32 platform however, TC only included items important to him. There were a number of requests made to support the "SO-CALLED Hack GPS I2C" and he claimed Baseflight will never support it. There are a number of other items not included for example, Airplane Mixing.

[aidensere07]

I think maybe if people helped implement them instead of tc doing all the work I can't see why he wouldn't include them, just seems the only person porting code is tc. I wish I could code, I have naze32. I'd love to help port stuff over but its out of ny comfort zone right now. Just my opinion

[copterrichie]

There are people attempting to do just that BUT.....

[nicodh]

And people that make it. GPS and SONAR where added by people having the iniciative to do so, and TC include it even if he didn't want to do it at first. I also did some mods that I neeeded for my rigs, and TC is adding them since it find it would be useful for other.
I know as a fact that a lot of people like the way TC does, but hey, he start it alone, did a very big part of the work, you disagree don't use his soft.Simple as that.

[tovrin]

Nico, that doesnt seem to be a very fair comment as we are discussing a complete port for the specific use of the MW Community, and not just to help make TC's port work for those who need it.

I have no doubt that TC is not only a respectable programmer, but a sincere person who is more than willing to help work something out, but we have yet to hear his POV in this discussion.

maybe it would be appropriate to just start over, but i think it would be useful to hear what Dong has to say.

[rreims]

Good news! There is a change that TC will add MS5611 to baseflight. Ordered MS5611 imu to him, so he could to the magic So anybody who want to help look here:

http://www.rcgroups.com/forums/showthread.php?t=1668273&page=14

[timecop]

OK, here's what I got to say

Hamburger:

yes, that is part of what I call a problem in the long run. It _needs_ doing, because it is separate forks.

There is no way to "just use" mwc-8bit code directly because:
1) everything is a forest of #ifdef (here it's all compiled and and configurable at runtime)
2) drivers/control code is all mixed and there's no attempt to have any sort of abstraction layer - particularly bad examples: mag and baro stuff
3) 8bit shortcuts are done all over the place - 16 vs 32 bit multiplies if expected value < 65000 etc.

So not all features from arduino-mwii make it into stm32-mwii. Last I looked the entire LCD & telemetry stuff was not there.

LCD is unnecessary because of serial console. It would be basically duplicating all the same functionality of serial console and STILL wouldn't be able to be used as-is because there are a LOT more parameters to configure. For example I'd have to hack in way to change motor mixer or any of the other settings that are only exposed by serial console.

Besides, there is no 'backchannel'. New features from the stm32 fork have no designated mechanism to become part of the arduino-mwii in an orderly fashion.

It's a rewrite for proper hardware only reusing basically bits of control code. Any improvements, if any, would be made with assumption that the hardware is capable so adding an extra sinf() in the main loop doesn't take a week of deliberations and confirmation that it won't affect loop time on atmega168 running at 8MHz. As others said, the code is open and you're welcome to take back ideas or features - I'm sure mega2560 users would like to have a working serial console and all the settings configurable instead of having to recompile stuff. Or heck, forget console and just add them all to LCD if you're into that.

.. and yeah, MS5611 is now officially supported and autodetected even if it's on the same address as BMP085.

[Hamburger]

Hi timecop,
you respnded to my post from June 29th - more than 2 months old.
You really do some catching up

yes, that is part of what I call a problem in the long run. It _needs_ doing, because it is separate forks.

There is no way to "just use" mwc-8bit code directly because:
1) everything is a forest of #ifdef (here it's all compiled and and configurable at runtime)
2) drivers/control code is all mixed and there's no attempt to have any sort of abstraction layer - particularly bad examples: mag and baro stuff
3) 8bit shortcuts are done all over the place - 16 vs 32 bit multiplies if expected value < 65000 etc.

yes, I understand the different capabilities of the hardwares and the non-portable structure of current mwii code.
Still, two separate forks will either require continuous work on both sides for porting back and forth or will drift apart over time.

So not all features from arduino-mwii make it into stm32-mwii. Last I looked the entire LCD & telemetry stuff was not there.

LCD is unnecessary because of serial console. It would be basically duplicating all the same functionality of serial console and STILL wouldn't be able to be used as-is because there are a LOT more parameters to configure. For example I'd have to hack in way to change motor mixer or any of the other settings that are only exposed by serial console.

from what I understand your console is the equivalent of the lcd config menu in MWii. Of course you provide more/other options since you converted compile time switches into cli-selectable items; I like that runtime-select over compiletime.define; MWii on 328p cannot do that for all supported hardware and features due to limited resources.

In MWii, the lcd also serves the purpose of telemetry - via serial over wireless (BT or other) or to i2c displays. Dunno if/how baseflight does telemetry.

Anyway, LCD was only meant as an example to drive the point - baseflight and MWii are already apart; supported sensors might be another example?

Besides, there is no 'backchannel'. New features from the stm32 fork have no designated mechanism to become part of the arduino-mwii in an orderly fashion.

It's a rewrite for proper hardware only reusing basically bits of control code. Any improvements, if any, would be made with assumption that the hardware is capable so adding an extra sinf() in the main loop doesn't take a week of deliberations and confirmation that it won't affect loop time on atmega168 running at 8MHz. As others said, the code is open and you're welcome to take back ideas or features - I'm sure mega2560 users would like to have a working serial console and all the settings configurable instead of having to recompile stuff. Or heck, forget console and just add them all to LCD if you're into that.

so indeed there is no backchannel.

I have 2 stm32 boards plus ulink2 in the drawer. I am waiting to see telemetry in baseflight with options for i2c displays and serial (over wireless, BT) gadgets (like smartphones with terminal programs).

You have done a load of work on baseflight and still do, I applaud you for that.
For the sake of MWii, I still think it could benefit from a common source base instead of drifting forks. Alas, when I asked for input on a multi-platform MWii code there was little response. I understand it would not be easy. So it seems the pain is not yet strong enough, the benefits not sweet enough.

We shall keep watching out, right?

[copterrichie]

For the sake of MWii, I still think it could benefit from a common source base instead of drifting forks. Alas, when I asked for input on a multi-platform MWii code there was little response. I understand it would not be easy. So it seems the pain is not yet strong enough, the benefits not sweet enough.

We shall keep watching out, right?

The only way I see this happening is, upgrading to an ATMEGA2560 and nothing less. Truth is sometime hard to accept.

[timecop]

The only supported telemetry currently is output of FrSky binary protocol for either FrSky LCD or er9x+mods receivers. This dumps flight time/gps data/accel values (fairly useless)/battery voltage.

Normal flight telemetry (via bt/xbee/whatever) and going to multiwiiconf works too.
I know there's some stuff like minmax counters for various sensors, but that didn't make it in since the only way to view it was by lcd , i could put same stats in serial console .. but dunno if its any useful there. though I suppose things like max height/etc might be interesting.

[nicog]

TC, I can update my configurator to use that telemetry max min stuff and all telemetry data, can't be that dificult.

[timecop]

Right, I might consider readding it in some form at some point.

However what I did commit with r205 is redone mixer code. Moved all hardcoded stuff into tables, in preparing for custom mixer.
RIght now, any of the predefined tables are copied into the custom mix and used that way. if cfg.customMixer[] is filled with data and MULTITYPE_CUSTOM is chosen, this is used instead. The custom stuff is still work in progress as there's no UI to configure it.

I did triple-check all mixers and hopefully didn't break anything BUT I only hovered quadX mix - people using QuadP or hexa/octo please check CAREFULLY motor responses.

r207 now has custom mixer loading stuff.
http://code.google.com/p/afrodevices/so ... tail?r=207
example of using it in cli:
http://bcas.tv/paste/results/xToE9w26.html
setting throttle of any motor to 0 will disable that motor. all 5 parameters are required, and space between params can only be one space, not several, or else stuff will break.

Mixer will do a sanity check (sum of powers) to see if mix is valid or not. You can still fly with wrong mixer, but don't expect it to work.

[Hamburger]

Normal flight telemetry (via bt/xbee/whatever) and going to multiwiiconf works too..

I find using an old BT enabled smartphone/gadget with a terminal program is much more versatile. And I can live without fancy graphics for tradeoff.

Currently available info via telemetry includes
- rx signal input values
- motor+servo output values
- gyro&acc sensors readings
- battery voltage, amps
- battery remaining capacity
- armed time, uptime
- alittude, max. altitude
- active options (level, angle, althold...)
- diagnostics (failsafe, i2c errorcount, cycletime min/max, debug[])

it is quite useful info at times.

[nicog]

I'm sorry hamburguer,

but:

- rx signal input values this is done with numbers and line bar to be much faster reading (a green line that move is better than a small number that changes)
- motor+servo output values same as above
- gyro&acc sensors readings graph does that in visual way, but if you want to see the numbers I have them just next to the graph
- battery voltage, amps yes my batery alarm show voltage and vibrates if the alarm is set!
- battery remaining capacity powermeter stuff?? If you ask me nicely I can add it.
- armed time, uptime also ask me nicely I'll do it for you
- alittude, max. altitude I will add it, that is in the todolist
- active options (level, angle, althold...) the switch tab show the active options in green. Please tell me that is easier to get them on a terminal
- diagnostics (failsafe, i2c errorcount, cycletime min/max, debug[]) I also can add a tab for you if you ask nicely

and finally:

I find using an old BT enabled smartphone/gadget Naze32 configurator is android 2.1 compatible, wich seems to be an old one.

[Hamburger]

I'm sorry hamburguer,

but:

... If you ask me nicely I can add it.
...
I find using an old BT enabled smartphone/gadget Naze32 configurator is android 2.1 compatible, wich seems to be an old one.

NicoG,
I am not competing with you.
Yes, a text based (terminal) interface has its shortcomings and advantages when compared to a real GUI.

With the current implementation of telemetry integrated in MWii, it is all open source, so I need not 'ask nicely' and wait but do it myself if I want to. When developing new features this has proven to be a huge benefit.

An android app will not work with anything but android. That leaves old palmos, symbian, win* and everything else useless.

Please understand not everyone likes using a closed source app in the context of open sourced MWii or basefilght. I certainly do not but that is for everyone to decide for oneself.

[nicog]

I'm not competing with you either.
But my code is free to everyone. it's not closed source. Maybe closed mind. But hey, everyone do what he wants right? free world?

So yes, asking nicely is a way to do the things right. And you know something? It works really great.

Please understand that the telemetry implementation maybe is not needed in the 32bits port. And if you want to use it, as you said, code it and commit to svn.

[fiendie]

And if you want to use it, as you said, code it and commit to svn.

Or better yet, open a pull request on GitHub! https://github.com/fiendie/baseflight
I am maintaining an up to date clone of the SVN repo just there to piss dongs off ;P

[Hamburger]

I'm not competing with you either.
But my code is free to everyone. it's not closed source.

ok, so your app is GPLed open source and I mixed that with another android app which is closed source. When I followed the link in the initial post here, all I found was a binary download. So it was my fault, good.

Please understand that the telemetry implementation maybe is not needed in the 32bits port.

so long as everyone is happpy to own and use an android device.

My post was meant as an answer to timecop's statement and not to critizise your app. As I am not intending to use baseflight in the imminent future, I feel it not appropriate to comment on baseflight more than I already have.

In earnest, have fun. It's a hobby.

[timecop]

the 'serial console' / cli stuff already works from regular vt100 terminal and every setting thats available in GUI can also be changed there via the 'set' command. I'll see about doing printing out raw rc/motor numbers + some telemetry. not anything i'd ever use but could be fun.

[nicog]

I added the custom mix feature into the windows based GUI. You can download it here:
http://tinyurl.com/8evhl7n

You should read the manual about motor order. I will simplify the use of this (for now it's the user who calculate the values).

[msev]

Nico could one do an aeroplane or flying wing mixer with that custom mixer?

[nicog]

Msev, I don't think so because custom mixer is for motor position only. No servo can be mixed for now, board side.

I need to rewrite the equations to try to simplify the method of calculation.

[timecop]

Yeah airplane mix stuff will be done separately, to allow servos/direction/etc.
Still planning a good way to do that.

Will probably merge flying wing and aeroplane mixers together, and just allow enough customization so it can be configured either way.

[msev]

Very cool ... Baro and magneto will also have influence on aero/wing flying mode right?

[copterrichie]

Yeah airplane mix stuff will be done separately, to allow servos/direction/etc.
Still planning a good way to do that.

Will probably merge flying wing and aeroplane mixers together, and just allow enough customization so it can be configured either way.

LOL, you don't have a solution but yet you BASH others for their work in progress?

[timecop]

I have a solution that looks like a turd, I can commit it today.
Or I can spend some time on it and make it nice - something most 8bit devs dont seem to care about.

p.s. enabled GPS in PWM mode as well - reduces number of channels to 4RC+2 AUX.

[copterrichie]

Well, an I2C-Servo or an I2C-GPS seems to be in other but that will never meet the TC's standard. Hmmm.

[timecop]

With 8 servos available in airplane mix mode, I doubt there's going to be any need for a HACK.
And with serial GPS working in both PPM and PWM input modes, what's the point for I2C GPS again? Remind me. Another point of failure? OK, thanks.

[copterrichie]

With 8 servos available in airplane mix mode, I doubt there's going to be any need for a HACK.
And with serial GPS working in both PPM and PWM input modes, what's the point for I2C GPS again? Remind me. Another point of failure? OK, thanks.

Your Words: "p.s. enabled GPS in PWM mode as well - reduces number of channels to 4RC+2 AUX."

P.S. I count six motor pins, where do the other two servo pins come from?

[timecop]

last I checked, that was the max number available on your beloved tarduino pro mini without hacks.

[copterrichie]

I'm asking about the Naze32, how would one go about connecting eight servos to it?

[timecop]

There are total 14 PWM channels that can be configured as inputs or outputs in various groups.
If you truly care, have a look around http://code.google.com/p/afrodevices/so ... /drv_pwm.c

There are 6+8 header pins where things can be connected. Infact if one so wishes, the 6 motor pins can be used as RC inputs and the 8 pins on the side can be outputs etc.

[copterrichie]

Thank you for the information and Yes I do care. Just don't like the BaShing at times.

[multimee]

p.s. enabled GPS in PWM mode as well - reduces number of channels to 4RC+2 AUX.

Great, TC! I'm sincerely grateful

[frog32]

I have a solution that looks like a turd, I can commit it today.
Or I can spend some time on it and make it nice - something most 8bit devs dont seem to care about.

but it would be good for all who are also coding on the same project. i am waiting for your solution i nearly went back to the last commit having flying wing support. you could push those things to a feature-mixer branch and let others participate in searching for ideas.

i don't knew ho expensive merging or rebasing is with svn but i am doing this up to 20 times a day at work using git where branching and merging is low cost.

[timecop]

Basically the problem with current solution is lack of flexibility. Too much stuff needs to be configurable, even previous builds needed recompile. I'll bring that back in a bit w/some more options as a temporary solution (flyingwing only) but for future, proper mixer needs to be reimplemented.

edit: k, flyingwing mixer is back. airplane mixer will happen later.

as far as ideas/discussion, go ahead.
basically: it has to be configurable, nothing hardcoded, fairly flexible (i.e. completed airplane mixer would be able to do flyingwing just by configuring it as such), and be able to mix in X number required servos in whatever orientation.