Baseflight aka multiwii port to stm32

Re: Baseflight aka multiwii port to stm32

Postby timecop » Tue Sep 04, 2012 12:04 am

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.
timecop
 
Posts: 1433
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Postby Hamburger » Tue Sep 04, 2012 9:55 pm

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

timecop wrote:
Hamburger wrote: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?
User avatar
Hamburger
 
Posts: 2261
Joined: Tue Mar 01, 2011 2:14 pm

Re: Baseflight aka multiwii port to stm32

Postby copterrichie » Tue Sep 04, 2012 9:59 pm

Hamburger wrote: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. :(
copterrichie
 
Posts: 2107
Joined: Sat Feb 19, 2011 8:30 pm

Re: Baseflight aka multiwii port to stm32

Postby timecop » Wed Sep 05, 2012 2:02 am

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.
timecop
 
Posts: 1433
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Postby nicog » Wed Sep 05, 2012 6:49 am

TC, I can update my configurator to use that telemetry max min stuff and all telemetry data, can't be that dificult.
nicog
 
Posts: 86
Joined: Tue Aug 21, 2012 2:21 pm

Re: Baseflight aka multiwii port to stm32

Postby timecop » Thu Sep 06, 2012 2:15 am

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.
timecop
 
Posts: 1433
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Postby Hamburger » Thu Sep 06, 2012 9:28 am

timecop wrote: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.
User avatar
Hamburger
 
Posts: 2261
Joined: Tue Mar 01, 2011 2:14 pm

Re: Baseflight aka multiwii port to stm32

Postby nicog » Thu Sep 06, 2012 9:45 am

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.
nicog
 
Posts: 86
Joined: Tue Aug 21, 2012 2:21 pm

Re: Baseflight aka multiwii port to stm32

Postby Hamburger » Thu Sep 06, 2012 10:25 am

nicog wrote: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.
User avatar
Hamburger
 
Posts: 2261
Joined: Tue Mar 01, 2011 2:14 pm

Re: Baseflight aka multiwii port to stm32

Postby nicog » Thu Sep 06, 2012 10:43 am

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.
nicog
 
Posts: 86
Joined: Tue Aug 21, 2012 2:21 pm

PreviousNext

Return to Software

Who is online

Users browsing this forum: No registered users and 1 guest