MultiWii

OK, as you know I'm working on making multiwii run on the $50 goodluckbuy STM32 thing called "FreeFlight".
90% of functionality I want is already implemented, of course things like RC input (pwm, ppm), motor/servo output,
uart comms, flash loading/saving, i2c, sensors (used on that board), etc. There's stuff I don't care about like I2C LCDs and other marginally useful (t0 me) junk which I havent bothered with.

First stupid question of the day:
The gyro is MPU3050.
I configure it in 2000dps mode, 8khz sampling, no lowpass filter. The values look sane in GUI.

i followed this for graph orientation:

Pitch forward and the gyro pitch numbers should go positive (up on the graph).
Pitch back and the gyro pitch numbers should go negative (down on the graph)
Roll right and the gyro roll numbers should go positive (up on the graph)
Roll left and the gyro roll numbers should go negative (down on the graph)
Yaw right and the yaw gyro numbers should go positive (up on the graph)
Yaw left and the yaw gyro numbers should go negative (down on the graph)

.

I can examine gyroADC and accADC values while running, and those also follow the pattern above.
However, gyro response is almost non-existent.
Once I tilt the board in pitch or roll axises, it slowly rolls there, then stays at an angle.
So something tells me gyro data is either not being used as good as it should be or I'm failing something.

The only thing is different would be cycle time which is around 1300 now.



In the screenshot below, i rolled the board hard to the left, but you see the 'roll' diagram tilting to the right f irst, then it would slowly float over to say 45" left or wahtever I tilted it to.

Where did I fail?
Using latest released -dev (0203)

Problem self-solved.
silly #if GYRO stuff to define proper scale factor and then more of currentT/previousT stuff moving to 32bit ints - now works perfectly.

http://www.youtube.com/watch?v=-AVkSCi78J0

Dude, sometime I am totally taken with your brilliance!

Very nice job Dongs,
I am excited to see what happens in flight
Do you share the code ?

Matt.

I'll have the code in my afrodevices googlecode page once I'm done cleaning it up and refactoring.
First hover = http://www.youtube.com/watch?v=cCloC5bhwL0
Kind of hard to fly and hold camera at same time, sorry.
But it works as expected i guess.

Could you paste link to this board in shop? I found it but looks different then yours, and don't have HMC5883L on the board. If you could put photo of this board.

Marcin.

Edit.
I found you make a clone of this board. It is possible to share schematics or maybe PCB files ? I have some plans to make STM port too, so maybe if more people want to use STM32, better if we keep the same pinout and the same repo...

original chinese pinout:


you have some "plans to make"? but it's already made and it works.
the problem is now, with a proper processor, all the stuff that has been hiding inside a forest of #ifdefs can actually be turned into dynamic runtime features.
and this would require major changes to the GUI.
I'm thinking maybe just dropping multiwii gui alltogether and instead use something that makes more sense, like openpilot gcs or similar. because hacking in all t he configurable stuff into nasty java GUI is not something I'm interested in doing.

So what are your plans?

Yes I know it is available, but I want to expand it a little. I think about compass, I2C header to external sensors like MAG or GPS_i2c (or uart header), gimbal, battery monitor etc. But your information is enough. I think we can create separate GUI, but you can find screenshot from new WinGUI for MWC and it looks interesting, and will be available with sources, so it should be ease to make some changes.

Generally I'm thinking about new CPU with more mips,ram,program memory because want to use it with more sensors and more features lik RTH as filesave etc.

Adding a bunch of new sensors takes no skill. Just look at the current multiwii code.
What would make much more sense is using more available CPU to do things properly, i.e. proper IMU without 8bit shortcuts, proper fusion of acc/gyro/mag instead of approximations, that kinda thing.

dongs wrote:Adding a bunch of new sensors takes no skill. Just look at the current multiwii code.

Yes this is true, but If I build make new board I want to expand it a little to be sure that It will work with GPS etc.

dongs wrote:What would make much more sense is using more available CPU to do things properly, i.e. proper IMU without 8bit shortcuts, proper fusion of acc/gyro/mag instead of approximations, that kinda thing.

I agree. Since few versions I made some changes for ACC calcuation using floats and have much stable platform and no drift problem. But Atmega don't like floats...

Hmm so it is time to design new STM board.... But I didn't work with this CPU till now so need learn new programming/debugging methods IDE, etc.

The board is already made. $50 chinese freeflight is more than sufficient to start proper development. it has a working acc and gyro. arguably, that's probably cheaper than most multiwii boards go for these days

Yes but in this price I can design onw PCB without any problem with headers, size etc. like I want with Gyro + ACC should cost about 35$ in Poland (but with gyro L3G4200D and ADXL345 acc).

Go ahead, let me know when you're done. btw that pinout is terrible waste of 48pin package - with proper pinout planning (such as openpilot did for example), you can have 2 SPI buses, 2 uarts, on-board USB, etc.

Anyhow, hardware is not the limiting factor, never been. It's finding people who are tired of wasting time optimizing each cycle out of motor PWM output routine. Heh, you can have $10 or whatever STM32-discovery board and do same thing with it. That's been available for years. How many people are flying multiwii on STM32? Just me.

Nice hover

Do you think i can use your code on a chipkit uno32 ?
good luck for the futur

Matt.

No because I don't give the slightest caress about pic32.
Anyone who does can, this port took me a few hours after I moved it to a driver framework I wrote for unrelated project.

Hello dongs,
This is my first post on the forum. I'm starting to build a multicopter for the first time, I'm already looking for an upgrade to a multiwii clone I have yet to receive! the stm32 arm looks like a good choice, and the board you bought looks like a suitable inexpensive platform to build it on. I was atracted to the rabbit board but as far as I can tell the software source is unavailable. WIll / have you made your software available yet? do you want some help in developing it more?
Best regards, David.

I just committed the stm32 bits to afrodevices repo on google code: http://code.google.com/p/afrodevices/
they're far from being clean and etc, but they work on freeflight hardware as well as my clone, auto-detecting present sensors out of the choice of adxl345, bmp085, hmc5883 and always-required MPU3050.

I'm using Keil MDK for environment for this project.

Thanks for posing the source. I've tried building it but the code size just exceeds the limit for the free version of Keil.
Perhaps I can trim it down or port it to IAR for which I have a full license.
Best regards, David.

Keil forces fairly strict ANSI-C coding, so it should be compileable by just about anything.
You can make some Makefiles and use it with CodeSourcery or similar toolchain. Of course, the whole point is being able to debug on-target and I'm not sure how that works out with GCC and Makefiles.

Hi,

is this http://www.st.com/internet/evalboard/product/250863.jsp
board also suitable?

Best regards,

Tobi

If you think you can make that fly for less than $50 that goodluckbuy freefight costs, yes.
You will need:
0) install compilers/ide for cortex m3
1) change pin out from f103
2) get some overpriced sensor breakout board
3) add support for those sensors

yep...this was what I was thinking of

Thanks for your quick reply

MWC on STM32 with warthox flying

http://vimeo.com/37479111

dongs wrote:If you think you can make that fly for less than $50 that goodluckbuy freefight costs, yes.

For prototyping purposes, I have the stm32vldiscovery board (10$) paired with an ATAVRSBIN1 9dof sensor (http://www.atmel.com/tools/AVRSBIN1.aspx, at 54$). I also use a USB to 3.3v serial cable for 20$. Plus perfboards and wirewrap -- total is definitively more than 50$... I am currently using native C-code using ST's peripheral libraries directly, but plan to migrate to this code base for testing as I really like the GUI options available.

Robert B.

Here's a great reason for opensores:

http://www.rcgroups.com/forums/showpost ... tcount=779

With just some minimal changes, this gentleman was able to get baseflight (stm32 mwc port) to run on FY90Q hardware.
That's cool, because I heard original firmware on those is quite teh suck.

So you can get a cheap hw (FY90Q), flash mwc port on it, and go flying. Very cool.

1+ From my window seat, everyone benefits from Open Source

May I suggest cross-Posting the above comment here: http://www.rcgroups.com/forums/showthread.php?t=1610439

http://www.youtube.com/watch?v=bVand2vhFXg

headfree mode is awesome, now I can spin like a pro

@dongs
Just compiling the head revision of your stm32 port. I am using codesourcery g++. I am breaking now the flash, the binary size is > 64 k. Your hex file seems to be 30 % smaller than mine. Any hint? Compiler options: -mcpu=cortex-m3 -mthumb -auxbase-strip src/gps.o -Os -Wall -version -fmessage-length=0

Best regards
Peter

Yes, I'm not using gcc.
Bump flash size to 128k in linker script, change FLAHS_NUM_PAGES (or something like that) in config.c to 128.
rebuild/upload.
64k devices have actual 128k of physical flash.

2 months without new maj...does it already death?

baseflight.hex 118 KB r174 Jul 2, 2012
yes, deader than Linux on desktop.

Dongs, you ride this high horse about how much better this ST32 is over the Arudino, Well it isn't all that period!

Hi,
here a new version of the STM32 port based on r181 of the afrodevices svn repository. Download
Differences:
- main loop fixed to 5 ms
- changed altitude hold

I made the main loop at fixed intervalls, because I and D-Term are dependent of the loop time in the code today. I found the default loop time of about 1,4 ms too low to get good results. I made experiments upt to 10 ms. 5 ms are working fine for me.

I changed the altitude hol to a different alghorithm wich reacts a little bit faster on *real* changes in altitude. Due to my changes, the PIDs have a different scaling. In the file a screenshot of the Multiwii configuration as a start.

Best regards
Peter

Hello, any news about multiwii for the Rabbit FC ?

Ask the rabbit producer. They stole MWii code already.

From what I have been able to determine, the Rabbit is a dead issue in the way of, there is not much development happening.

Hamburger wrote:Ask the rabbit producer. They stole MWii code already.

That's a constructive answer... Thank you.

copterrichie wrote:From what I have been able to determine, the Rabbit is a dead issue in the way of, there is not much development happening.

I confirm that their code is crap, as they are unable to make the GPS works properly, and many other things. If the board was interesting regarding the hardware it's far to be the case for the software... I still wish that someone finally find the way to make the MWii soft run on it so we could fully use it.

The hardware is boring, anyway. Its cortex M0 (no hardware divide) at 50mhz, only 64k flash and like 4 or 8k ram.
its even less interesting than any of the (cheaper) kcopter boards.