Harakiri aka multiwii port to stm32

Crashpilot1000 · Post by **Crashpilot1000** » Mon Jan 06, 2014 7:10 pm

@PacciK: I've been able to *somehow* reproduce that with nz4 and mma.
Observations:
1: Althold does an hight jump like if the accz would have the wrong direction - but it hasn't in the gui. Probably a LPF / CF thing that probably can be tuned out. Not tested further.
2: GPS PH only (no althold) sudden throttlecut to cfg.esc_min - after turning GPS function off needs some time to recover and accept stickinputs again (thats where my thumb lost a little skin during handtest). Very obscure.
Looked in the code to find occasions where minthrottle (cfg.esc_min) could occure - still clueless maybe the last mixer step. Really have no idea what is going on since GPS is angle restricted and has no way (I see) to influence throttle directly - esp make it unresponsive stuck at minthrottle.

Since I have an older Naze with adxl/bmp/MPU6050 I uploaded the code there and choose ADXL as acc (set acc_hdw = 1). I was happily surprised that the old adxl345 does a good job on supporting althold and gps AND NOTHING FISHY happened it simply worked like supposed.

So at the end of the day I really don't know whats up. Use ADXL for now.
I will upload the tested code later in my repo https://github.com/Crashpilot1000?tab=repositories

Cheers
Rob

PacciK · Post by **PacciK** » Tue Jan 07, 2014 8:13 pm

Fullsize-Herehttp://postimg.org/image/n8ou1gtr3/

This is my testbed for faceplants.....and it just had one.... :evil:

Film starts: It was perhaps 1 or 2 m/s this calm evening, the GPS and RED led on the Naze starting showing good signs of life within 20 seconds> I waited for another minute more, so that the GPS would settle, ( I had no Bluetooth or phone with me to verify the 12 usual satellite count ) ..
and soon after, I takeoff into a mild headwind ( a cute evening medium chilled breeze),....( enough movie now ) ....

Anyway... so I immediately switched on GPS PH.
The copter went back perhaps 2 to 3 meters, then began holding against the breeze, then attempted to move forward to where I switched on PH.
Just 3 seconds go by ...got a little wibbly-wobbley....and WHACK....a full left ROLL by itself and the copter ROLLS 2 times faaaast loosing just 1 meter every roll..( during which I switched off GPS PH ) but it was too late...( I was only 0.733333F of a mistake high...around 4 meters high :cry:

)

Only lost two front props, because it came head first, but sadly broke the Sarantel antenna of the GPS. So.... I was a bit more pissed off than usual.

So.. Rob, I really need to see where this is coming from... I need to learn how Git works, and then copy the repository you'll tell me.
Glad you use uVision environment.

reading your above post, I am a bit reluctant to take that in...because exactly the same behavior is happening on the Pink Naze32, which i believe is Rev5 ( Mpu6050 ).
Can you expand what you had reproduced ?
and last question... I would like to hear from your regarding which debug parameters should I export and monitor in real time.

Cheers !!!!

PacciK · Post by **PacciK** » Tue Jan 07, 2014 8:16 pm

And NO....the blue and yellow props do not overlap.... they are usually spaced about 5or 6cm.
I built it with just 1 bolt holding the arm so that a sideways crash will be absorbed by the arm twisting about the pivot )....

PS>> hope your thumb is OK... Rob !!

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jan 08, 2014 5:31 pm

Oh, shit. As said before, I really don't know what is up. BTW have you mounted the naze way back at the ass of the copter? That will most probably cause a lot of problems - starting by the mag etc. "I need to learn how Git works, and then copy the repository you'll tell me." yes, me too. I just use github as a private websave and there is a button "Download ZIP" so you can download the whole selected repo. I found a self introduced bug in the mma driver getting crazy last 2 bit - but that doesn't do much since their effect is minished during scaling, even with the corrected driver I get the same idle shutdown in PH (but no flip).
What I observed: GPS PH: MPU & ADXL working like expected (nz4 and an older nz with BMP). Nz4 with mma enabled: Hight jump in Baromode, stable angle mode, PH: sudden shutdown to idle of copter (vertical smack to the ground) and unresponsive - can be tested in hand: PH engaged motors running slightly above idle (for safety...) and move around with copter - at some point it will idle motors. Really have no clue what's causing that and I really want to know.
BTW There are no GPS debug[X] parameters put out during flight but I could put out a bunch of data over the mavlink protocol to telemetry it to your laptop where MP could record the shit.

PacciK · Post by **PacciK** » Wed Jan 08, 2014 5:59 pm

Hi Rob.... OK..thanks for the explanation. I have not seen the Bumps up in Baromode....and I also have not seen ( or identified yet ) the sudden shutdown of all 4 ( or more depending on your rig ) motors.

Mavlink....yes..interesting... I need to learn/research how this works ( never really looked into how mavlink protocol works ). It probably the neatest solution to monitor stuff.
However, for first try I will just select 4 parameters at a time, and debug them via Android GCS when at the field..first with hand tests, then with flights.

I will also try with MMA and ADXL and see if I can observe differences, and perhaps help if I can.

I have created a fork of your last code, and then DL'd the zip, installed it in my PC, and will now attempt to link that folder to a new branch. I have tried it once but it did not work.
Guess its another short learning curve.

Rob, I have tried to load your code in my uVision, but it will not compile....its reporting errors like as if your work is being done in GCC environment ( even though its a uvision project ).
Can you please PM me with your "Control Strings", for the C/C++ , ASM, and Linker tabs in Keil's Options popup.

Cheers !!

PacciK · Post by **PacciK** » Wed Jan 08, 2014 6:16 pm

It does not really matter where the naze is placed.....faceplants happened on any rig I tried GPS hold on....some where straightforward X-Quads with the board exactly in center, others like this design.( Actually this one flies really nice in Angle or Horizon mode ).
Even on another Naze where I've hot-aired off the MAG and hooked up another Mag breakout board on the GPS elevated platform.
( don't worry, I've O'scoped the I2C bus and verified that the edges are still nicely square and that no I2C errors happen ).
So.... we move on from here.
I hope I can be of good contribution to your code.

one thing which I'm still baffled about is .. It seems like my setups are the only ones suffering from this faceplant flip ( of death ).
No one else reported this it seems.

I will now try with a different GPS since the UBlox with Sarantel said Bye Bye...

hinkel · Post by **hinkel** » Fri Jan 17, 2014 5:19 pm

Hi Crashpilot1000 ! frohes neues Jahr

There is a lot activity and changes on your Harakiri software, is the last SGTodaySnapShotSave2 well for flying and testing ?
Or is it better to wait for next "official revision" ?

Regards
hinkel

ABL · Post by **ABL** » Fri Jan 17, 2014 5:29 pm

PacciK wrote:one thing which I'm still baffled about is .. It seems like my setups are the only ones suffering from this faceplant flip ( of death ).
No one else reported this it seems.

I had few of them in previous summer. With different firmware and different boards.
I'm not sure if it's board fault or something else, i didn't tried to use harakiri after flips, returned back to baseflight. Last board i tried with harakiri was broken in half on last flip, so i can't verify if this happens in baseflight.

hinkel · Post by **hinkel** » Fri Jan 17, 2014 6:20 pm

ABL wrote:
PacciK wrote:one thing which I'm still baffled about is .. It seems like my setups are the only ones suffering from this faceplant flip ( of death ).
No one else reported this it seems.

I had few of them in previous summer. With different firmware and different boards.
I'm not sure if it's board fault or something else, i didn't tried to use harakiri after flips, returned back to baseflight. Last board i tried with harakiri was broken in half on last flip, so i can't verify if this happens in baseflight.

I can not report faceplant with Harakiri for now ! But by testing newer Baseflight on Naze32 rev0 I had a faceplant issue an
kopter had bad flying ( working well with old baseflight r225 GPS hold and RTL was working ) but also some GUIs introduce fails
( setting false parameter by herself ) and seems not compatible with all software and hardware it is very hard to find all this issues !

.
For the moment I stop using baseflight because GPS navigation is Taboo and if you have a failsafe issue you just fall from sky !

Crashpilot1000 · Post by **Crashpilot1000** » Sat Jan 18, 2014 6:50 am

Hi, Hinkel & ABL!
Well I use Github mainly as websave and the current version is not tested so not really recommended. Currently I am reworking a lot of stuff from the ground up and already found/eliminated some issues. But that takes time. The faceplant stuff was not reproducible for me but a sudden motor idle with mma acc enabled & althold & gps & mag not calibrated & whole shit activated by aux1 - so horizontally to the ground without flip. Currently I have no clue what is causing that.

IceWind · Post by **IceWind** » Sat Jan 18, 2014 1:50 pm

What's the current Harakiri version?
I checked on my quad and I thought I was running 2.5 but no it is 2.6 >> Harakiri10 Summer Games 2.6 Oct 14 2013

Not that I want to change it as this so far is running perfectly but just to keep track of the changes.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Jan 18, 2014 2:05 pm

Hi IceWind! Keep the soft that works for you (like 2.5), I don't keep version numbers up to date (all after 2.5 is pre 2.6), since I am still testing around but I think I have something at play right now (not yet in repo) that is very promising. Against popular belief it is not about copying code from other projects but doing own stuff, so testing takes the longest time. If I have a version that is in my opinion "tested and found worthy" you will read a note here and a link to the hex for sure.

brm · Post by **brm** » Sat Jan 18, 2014 3:00 pm

ABL wrote:
PacciK wrote:one thing which I'm still baffled about is .. It seems like my setups are the only ones suffering from this faceplant flip ( of death ).
No one else reported this it seems.

I had few of them in previous summer. With different firmware and different boards.
I'm not sure if it's board fault or something else, i didn't tried to use harakiri after flips, returned back to baseflight. Last board i tried with harakiri was broken in half on last flip, so i can't verify if this happens in baseflight.

hi abl,
do you fly with gps?

me in most cases not.
without gps it is stable.

will go through testing the latest stuff - plus a changed mixer.

Crashpilot1000 · Post by **Crashpilot1000** » Mon Jan 20, 2014 12:03 pm

Short notice: Updated Repo. Just had the chance for a quick spin. The IMU part is time independent now so you can set a looptime "0" and it flies very well. Note: When you do that, I assume that you want speed, so the timeconsuming serial part is put into "emergency low power mode" - that means it will send serial/GUI/OSD data only at 100Hz rate and process only ONE command per loop. The GUI will be choppy then and look like tetris, but that is NOT a stall of your naze and done on purpose to use the speed in the main loop. A long standing megastupid monsterbug has been removed, that - at least with the alternative PID controller - could produce a faceplant. I did my best to repair the Buzzer code for nz4/5 should work now. There is no hex included in the repo because I haven't had a chance to test GPS functions yet.

EDIT: I add the compiled hex here for the risky guys - but FFS do a Handtest if everything works like expected because some of the RC part is also redone! It's the compiled version of "SGTodaysSnapshotSave666" the readme is in the repo: https://github.com/Crashpilot1000/SGTod ... README.txt
EDIT EDIT: The red LED will strobo flash to signalize "take care I am hot and ready to start", GPS sats will override that (see readme). During ACC calibration even the gyro offsets are saved, just in case you want to arm on a swinging boat. That is done to be able to launch under all conditions. To provoke that you can powerup your copter and swing it around for 20+ seconds, then the presaved Gyro Offsets are taken. Note: Let the FC warm up ca 5 Minutes (you can see detailed sensorinfo with cli "status" including temperature) before pressing the ACC calibr. button. During ACC calibration the GUI will freeze (I still use mwii gui 2.1) and naze will not blink - it takes some (longer) time just wait and don't move it around/shake the table!!

Update:
Flightmodes tested so far (DJI450 frame, Robbe 980KV, BLheli esc, APC style 10''/4.5, 3S3300, 1Kg) with "normal main PID controller":
Acro
Angle
Althold MS/BMP
Sonar (MB1200XL)
Autostart
Autoland
GPS PH
Other functions tested so far:
- feature pass (ESC calibration not tested - but should work like always): OK
- cli passgps (ucenter): OK
- feature lcd: NOT OK (LCD is working, but you cant arm anymore with that feat enabled. LCD exitmessage is displayed too shortly) Fixed: lol - yes but unreleased (Edit: see post below)

Note: I will not test my flipsupport for Acro/Horizon mode - because I love my copter..

IceWind · Post by **IceWind** » Mon Jan 20, 2014 10:33 pm

Crashpilot1000 wrote:Hi IceWind! Keep the soft that works for you (like 2.5), I don't keep version numbers up to date (all after 2.5 is pre 2.6), since I am still testing around but I think I have something at play right now (not yet in repo) that is very promising. Against popular belief it is not about copying code from other projects but doing own stuff, so testing takes the longest time. If I have a version that is in my opinion "tested and found worthy" you will read a note here and a link to the hex for sure.

I will for sure until you release some major change... and you just did.

Need to get a second Full Naze32 to test bleeding edge code and leave my main one moving only from stable to stable version.

Keep up the great work!

Crashpilot1000 · Post by **Crashpilot1000** » Tue Jan 21, 2014 1:14 pm

Thank you very much IceWind for the flowers, but it's not a major release just a compiled hex of work in progress (with most probably repaired buzzer part but fu**ed up LCD part - LOL). I think there is a lot of headroom when tuning acc_lpfhz and gy_cmpf. Maybe it is time to delete that "looptime and cycletime" stuff completely. Hmm...

EDIT: I attach the version here with the LCD call repaired

Hydroculture · Post by **Hydroculture** » Wed Jan 22, 2014 5:47 pm

Thank you Roberto!

Successfully flashed your 666.
Works very nice for me on an naze32V5.
No GPS/BARO/MAG on my board.
Used Horizon to test it.

Thank You
Holger

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jan 22, 2014 6:30 pm

@Hydroculture: Thank you very much for your feedback! Actually you didn't notice it as well:
The rx latency increased instead of decreasing because of a "volatile" I added for the Interrupt there - I didn't notice that in the first place but an email drew my nose to that and it is right - so that is NOT a safety problem but nasty. I am also working on improving the flight performance in level. If you are using one of the last hex files set Level I to zero, it will just lead to delayed level. The alternative controller from alex khoroshko doesn't use level I at all (there it is the "P" for horizon). Expect an update soon.
Cheers Rob.

alistairr · Post by **alistairr** » Thu Jan 23, 2014 6:45 am

You have been busy Rob.! Looking forward to trying the new firmware. ..

Crashpilot1000 · Post by **Crashpilot1000** » Thu Jan 23, 2014 9:25 am

@alistairr: Yes! Check out the attached version here (Source is in repo).
The timing is smoothed out for the main pid control -> over all more stable, Mainpid roll/pitch D is more solid now. Serial timing reworked, no visible "tetris mode" anymore, if in trouble serial will slow down for max 3 cycles in a row, that is normally enough to deal with a spike but don't slow down serial too much. Rc volatile stuff reworked.
Level, acro, Althold, GPS PH tested, Basic RTH with Autolanding tested.
Flipsupport should be possible in baromode now as well - I don't dare to test.
Cheers
Rob

mbrak · Post by **mbrak** » Thu Jan 23, 2014 7:23 pm

hi rob

great to see new versions here!!
whats about oled? it is working ?

br michael

Crashpilot1000 · Post by **Crashpilot1000** » Thu Jan 23, 2014 7:36 pm

I have no OLED (and will not go for one..) but my serial LCD works, and I just reworked the OLED stuff to be a little shorter - so it SHOULD work like before (but it's still a waste of eeprom

).

subaru4wd · Post by **subaru4wd** » Fri Jan 24, 2014 7:01 am

Crashpilot1000 wrote:@alistairr: Yes! Check out the attached version here (Source is in repo).
The timing is smoothed out for the main pid control -> over all more stable, Mainpid roll/pitch D is more solid now. Serial timing reworked, no visible "tetris mode" anymore, if in trouble serial will slow down for max 3 cycles in a row, that is normally enough to deal with a spike but don't slow down serial too much. Rc volatile stuff reworked.
Level, acro, Althold, GPS PH tested, Basic RTH with Autolanding tested.
Flipsupport should be possible in baromode now as well - I don't dare to test.
Cheers
Rob

Sounds like you have been busy Rob. Good to see you making progress with the firmware. I am eager to try this new version. Should we continue to use MultiWii 2.2 GUI or is your firmware taking advantage of the new MW2.3 GUIs?

scrat · Post by **scrat** » Fri Jan 24, 2014 7:13 am

Crashpilot1000 wrote:@alistairr: Yes! Check out the attached version here (Source is in repo).
The timing is smoothed out for the main pid control -> over all more stable, Mainpid roll/pitch D is more solid now. Serial timing reworked, no visible "tetris mode" anymore, if in trouble serial will slow down for max 3 cycles in a row, that is normally enough to deal with a spike but don't slow down serial too much. Rc volatile stuff reworked.
Level, acro, Althold, GPS PH tested, Basic RTH with Autolanding tested.
Flipsupport should be possible in baromode now as well - I don't dare to test.
Cheers
Rob

Sorry for asking...what is Flipsupport? And what software are you using for CLI? For PID's can I use mwii gui 2.2 or 2.1?

Thanks.

LVNeptune · Post by **LVNeptune** » Fri Jan 24, 2014 7:22 am

I believe by flip support they are referring to the Flip FC.

timecop · Post by **timecop** » Fri Jan 24, 2014 7:25 am

LVNeptune wrote:I believe by flip support they are referring to the Flip FC.

I believe you're a fucking retard.
Based on the context its something about flipping (you know, the quad) while baro mode is enabled.

LVNeptune · Post by **LVNeptune** » Fri Jan 24, 2014 7:30 am

^ just trolling you, was hoping to get a rise.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Jan 24, 2014 1:10 pm

I use this terminal program: https://sites.google.com/site/terminalbpp/ that is very nice and the mwii gui2.1. That is much faster and stable that most other combinations I've seen. BTW: A looptime of 0 is pointless, since the mpu6050 can deliver data with 1kHz - so looptime = 1000 should be the reasonable lower limit.
The flipsupport was just following idea:
When you fly acro or horizon and want to do a flip it will reduce (just scale down) the motorthrottlecommand when upside down to the half of your actual throttle input. Since althold is also working in acro and horizon modes it was just logical to take care of that situation as well (EDIT: Of course: baroinfluence is zero when upside down - otherwise it would nail into the ground. The Throttlecommand in this situation is initial hoverthrottle/2) but that function is just hand tested so fly high when testing it... ( rc_flpsp = 1)
The "flip32" seems to be good as well

.
Cheers
Rob

brm · Post by **brm** » Fri Jan 24, 2014 7:03 pm

timecop wrote:
LVNeptune wrote:I believe by flip support they are referring to the Flip FC.

I believe you're a fucking retard.
Based on the context its something about flipping (you know, the quad) while baro mode is enabled.

you're back to live.
i have it black on white ...

Crashpilot1000 · Post by **Crashpilot1000** » Sat Jan 25, 2014 8:07 pm

Hi!
Welcome back BRM!
Short notice: I extended the flipsupport now the throttlereduction is adjustable:

From the readme:

- Added rc_flpsp = x (Range 0 - 3) When enabled and upside down in acro or horizon mode only reduced throttle is applied.
Also works in combination with althold.
-- rc_flpsp = 0 |Disabled. Default value.
-- rc_flpsp = 1 |1/2 throttle - input is applied when upside down.
-- rc_flpsp = 2 |1/3 throttle - input is applied when upside down.
-- rc_flpsp = 3 |1/4 throttle - input is applied when upside down.

If you have a little acro copter and do flips anyway, it would be nice to hear if that function is something for you or if it is just a mindfart....
Code is in the repo. I attached the hex here.
Cheers
Rob

scrat · Post by **scrat** » Sun Jan 26, 2014 12:00 am

Crashpilot1000 wrote:I use this terminal program: https://sites.google.com/site/terminalbpp/ that is very nice and the mwii gui2.1. That is much faster and stable that most other combinations I've seen. BTW: A looptime of 0 is pointless, since the mpu6050 can deliver data with 1kHz - so looptime = 1000 should be the reasonable lower limit.
The flipsupport was just following idea:
When you fly acro or horizon and want to do a flip it will reduce (just scale down) the motorthrottlecommand when upside down to the half of your actual throttle input. Since althold is also working in acro and horizon modes it was just logical to take care of that situation as well (EDIT: Of course: baroinfluence is zero when upside down - otherwise it would nail into the ground. The Throttlecommand in this situation is initial hoverthrottle/2) but that function is just hand tested so fly high when testing it... ( rc_flpsp = 1)
The "flip32" seems to be good as well .
Cheers
Rob

Thanks Rob. Naze32 rev5 on my quad. Will test 23Jan.zip soon.

rank · Post by **rank** » Mon Jan 27, 2014 9:45 am

23jan.hex is the first hex I got the gps functions to work to some extent. Gps hoover works just about fine, RTH was a little aggressive, so I shut it down. Will try once again later. What's the GPS AUTO function?!

Crashpilot1000 · Post by **Crashpilot1000** » Mon Jan 27, 2014 3:30 pm

@scrat: Looking forward to you short report.
@rank: Thank you very much for your feedback! Yes the imu part has seen some major overhaul to improve GPS ins functions. I am still not happy with all the filter values (but they can be adjusted in cli - see sourcecode config.c where every parameter is described with it's function). The RTH is a little more on steroids because nav_tiltcomp is "30" now, was 20 default before.
GPS AUTO has no code behind it yet (just a box), because I wanted to iron out everything before moving on. That seems reasonable to me before going on and stumble over old errors and fu** ups and make it a russian roulette.
Currently I am investigating the MARG algor. from Madgwick (modified by J. Ihlein & G.K. Egan & now myself). The results for acc NED are better than before but overall it's currently worse. I will not spend to much time on MARG, before moving on because the results of the current IMU (last posted hexfiles) are good and sufficient.
Cheers Rob

scrat · Post by **scrat** » Mon Jan 27, 2014 6:06 pm

It is snowing and can't test the copter.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Jan 28, 2014 8:26 pm

@scrat: Yes the weather here is also a downer.
Just for info played around with the marg implementation. I tried to understand the underlying scientific paper but I am to dumb for that. So just playing around there. The basic code was liftet from J. Ihlein (jihlein on github) - I know mindless copying

. I published the code in the repo just in case other project will benefit from it / have a look/good laugh at it. I am really not shure but there might be a problem in jihlein original acc handling and the scaling concerning G.K. Egans' "accel confidence calculation" - I tried to correct that. Hmm, the results so far are not really more usable than the current IMU part. From what I understand kiAcc and KiMag could compensate for a long term error, if that is true and I can get it to work reasonable it would be real benefit over the current IMU approach I wouldn't want to miss. So interesting stuff maybe someone with insights into that subject could give me a hint or piece of information here?
Cheers
Rob

aadamson · Post by **aadamson** » Thu Jan 30, 2014 1:56 am

Crashpilot1000 wrote:@scrat: Yes the weather here is also a downer.
Just for info played around with the marg implementation. I tried to understand the underlying scientific paper but I am to dumb for that. So just playing around there. The basic code was liftet from J. Ihlein (jihlein on github) - I know mindless copying . I published the code in the repo just in case other project will benefit from it / have a look/good laugh at it. I am really not shure but there might be a problem in jihlein original acc handling and the scaling concerning G.K. Egans' "accel confidence calculation" - I tried to correct that. Hmm, the results so far are not really more usable than the current IMU part. From what I understand kiAcc and KiMag could compensate for a long term error, if that is true and I can get it to work reasonable it would be real benefit over the current IMU approach I wouldn't want to miss. So interesting stuff maybe someone with insights into that subject could give me a hint or piece of information here?
Cheers
Rob

I really think that if you check out some of the *newer* of johns code (the AQ32PLUS stuff or the FF32 stuff) you'll find that the Marg implementation is correct, it's been flying for a number of users on both the original naze32 platform as well as the AQ platform and John just recently implemented a new version on the new (not sure it's been released officially) - naze64pro (all spi sensors, and an F303 with hardware floating point).

I know personally that John and Dr. Egans worked countless hours to correct that Accel cutoff feature (a while ago) and from those that have flown his full code, they will tell you it's by far and away the most stable code they have ever flown.

*I also think* that he's recently updated his baseflightplus code - now called ff32lite (I think ) using some tricks we figure out dealing with gimbal controllers and given it a few more features....

NOT TRYING to promote another code, I really don't have a dog in this hunt, but I know John personally and I know how much of a perfectionist he is (plus what he does for a living) and before he creates any code he simulates most of in entirely in Matlab so he knows *exactly* how it's going to behave in real life.

Have fun, but I just saw this post and figured that I'd let you know that there *may* be a newer - what I think they are calling MARG+ out there.... Also remember, MARG is called MARG because it needs a magnetometor, the non-mag version is just called ARG.

Alan

Crashpilot1000 · Post by **Crashpilot1000** » Thu Jan 30, 2014 11:59 am

@Aadamson: Thank you very much for your reply!!! First of all it's a pleasure to look at jihleins' code, it's clear and not overcrowded. I would love to test out his flightcode but didn't find the hexfiles - do you have a link to them - or is there a thread somewhere? Or will I have to do an own makefile?
I had a closer look into the calculateAccConfidence - where I thought a problem could be, and there is none. I now see what striked me on the first glance is a double reference to 1G. On the hardware acc level there is a datasheet reference to 1G (MPU6050_ACCEL_SCALE_FACTOR) and then there is accelOneG gathered upon the mounting and actually measured/reported 1G. In my opinion the real world "accelOneG" would be sufficient as reference. In the MARG (that quiet happily works without any MAG data - just as 6DOF IMU, BTW) there are error accumulating terms for mag and acc (exAccInt, exMagInt etc) but I don't see them being "static" - am I wrong? While not understanding the guts of MARG I wonder how it is supposed to filter/cope with all the acc jitter from the raw acc 500Hz data. Maybe using prefiltered values (like multiwii) wouldn't be bad and that would most probably eliminate the need of the "HardFilter(O,N)" the gyro authority has to be higher then (of course). Currently I am getting MAG data at ca. 70Hz is it better to poll the MAG with 10Hz?
Just my 2 cents, I know I am stupid when it comes to that mathlab & imu stuff, just questions that arose while trying to understand what is going on in the code.
I played around with the MARG stuff a while now and I am very happy with the results concerning precision of attitude angles and heading. So a very BIG thank you to Mr. Ihlein for putting the code on display.
Cheers
Rob

aadamson · Post by **aadamson** » Thu Jan 30, 2014 2:40 pm

Crashpilot1000 wrote:@Aadamson: Thank you very much for your reply!!! First of all it's a pleasure to look at jihleins' code, it's clear and not overcrowded. I would love to test out his flightcode but didn't find the hexfiles - do you have a link to them - or is there a thread somewhere? Or will I have to do an own makefile?
I had a closer look into the calculateAccConfidence - where I thought a problem could be, and there is none. I now see what striked me on the first glance is a double reference to 1G. On the hardware acc level there is a datasheet reference to 1G (MPU6050_ACCEL_SCALE_FACTOR) and then there is accelOneG gathered upon the mounting and actually measured/reported 1G. In my opinion the real world "accelOneG" would be sufficient as reference. In the MARG (that quiet happily works without any MAG data - just as 6DOF IMU, BTW) there are error accumulating terms for mag and acc (exAccInt, exMagInt etc) but I don't see them being "static" - am I wrong? While not understanding the guts of MARG I wonder how it is supposed to filter/cope with all the acc jitter from the raw acc 500Hz data. Maybe using prefiltered values (like multiwii) wouldn't be bad and that would most probably eliminate the need of the "HardFilter(O,N)" the gyro authority has to be higher then (of course). Currently I am getting MAG data at ca. 70Hz is it better to poll the MAG with 10Hz?
Just my 2 cents, I know I am stupid when it comes to that mathlab & imu stuff, just questions that arose while trying to understand what is going on in the code.
I played around with the MARG stuff a while now and I am very happy with the results concerning precision of attitude angles and heading. So a very BIG thank you to Mr. Ihlein for putting the code on display.
Cheers
Rob

No, there is no pre-built hex, you'd have to build the code from his sources.

As for the 1G reference there are 2 in use... the Accel provides something close to 1G, that you have to calibrate to get corrected, then there are reference for 1G used throughout the code where needed for comparison.

Of course you can use MARG without a mag, but you loose all of it's benefits. The mag plus the accel cutoff is what keep the attitude in check during high acceleration. We used to call this the *leans*... and that accel error will continue to build up unless the 2 sensors are using in concert with one another.

As for MARG, I'm fairly sure (but I haven't played with this code in a while) that there are low pass filters on the raw data prior to use. John uses a cascading loop to setup separate timed events - poor mans multitasking if you like. Those are 1000hz, 500hz, 100hz, 50, 10, 25, 5, and 1 (different codebases have different version so he can keep his processing *lock* in time). He traditionally uses the systick timer to maintain this loop timing. This means that all of his uses of dT are accurate where as other code bases don't do this.

Those cascaded steps in the main loop, one of them will aquire the raw data, and another will run it through a low pass filter prior to it being used in MARG.

All the FF32 code bases are the most recent. The AQ32Plus stuff came from the original work on AQ32, and about a year ago, he started with the FF32 versions, there are both a NAZE32 and an NAZE64pro version of those.

you don't need mag data any more frequently than 10hz, and the Kp, Ki values are most likely already tuned for usage.... But again, you need mag and accel data in marg to be the most effective.

Beyond that you are on your own, I've not messed with these for a year, but talk to John frequently about them and other projects that we are working on.

Alan

Crashpilot1000 · Post by **Crashpilot1000** » Sat Feb 01, 2014 3:00 pm

@aadamson: Thanks again for your input! I want to keep you posted on my MARG progress. The main problem I have is that I can not get the parameters tuned in well to rival the over all result of the existing core. I just upped my actual marg status and will leave it at that stage. Maybe I messed up some axes? The sliding accel cutoff however could be beneficial for the mwii core - have to check that.
Cheers Rob

EDIT: Found another nasty bug, have to re-eval MARG. The big benefit of marg is that it gets rig of the sin/cos party a great deal and gives excellent heading and generally it is superior - but still too dumb to get it really working better outside the bench..

subaru4wd · Post by **subaru4wd** » Sun Feb 02, 2014 5:43 am

Rob, do you see any reason not to try out your latest Jan 23 release? I am eager to get my Return to Home working, and summer games 2.5 just isn't doing it for me. I'd like to try out some of your new code, but if you are talking about finding bugs maybe its just best if I stick with my copy of 2.5??

Crashpilot1000 · Post by **Crashpilot1000** » Sun Feb 02, 2014 7:19 pm

Would stick to 2.5 for now, still figuring out stuff. You can also use that viewtopic.php?f=23&t=3524&start=520#p45985 it's also test flown.
Still can't get marg working better but the accConfidence stuff seems to be good for althold in motion.

aadamson · Post by **aadamson** » Mon Feb 03, 2014 4:47 pm

Crashpilot1000 wrote:Would stick to 2.5 for now, still figuring out stuff. You can also use that viewtopic.php?f=23&t=3524&start=520#p45985 it's also test flown.
Still can't get marg working better but the accConfidence stuff seems to be good for althold in motion.

One thing to remember, John uses a right hand coordinate system for everything, and usually it's used throughout his code. If the axis's aren't completely setup to use this from end to end, you may think you have functional code, but it's just the Kp/Ki that working too hard to correct a sign issue.

You'll need to verify end to end that the axis alignments, signs and units are correct.

He also uses SI units throughout and converts for them at the initial sensor read.

Again, I really don't have a dog in this hunt, but I've heard from more than a couple who have flown a CF, DCM or Kahlman type attitude estimator that by far and away the MARG+ (with accel cutoff and mag) implementation gave the smoothest, most locked in feel... But again, that is just passed along info... I really haven't flown his latest work - yet

Alan

Alan

brm · Post by **brm** » Tue Feb 04, 2014 1:09 pm

mag and acc unit are normalized.
in case you are short on cpu cylces just forget si units and all the scaling.
what does count in is a normalised vector for acc and mag.

and for shure the axis have to be correct.
carefull calibration is also a big plus - the calibration in johns code is correct but can be done better for the acc unit.

the ethz ekf is the best so far ... and to be usefull it needs an fpu ;-)

Crashpilot1000 · Post by **Crashpilot1000** » Tue Feb 04, 2014 6:06 pm

@aadamson: Agreed. Probably mixed up some axes, I orientated myself with the NED nomenclature. I keep the code in the repo, just in case it might be a starting point for others. I thought I solved the problem but freeflight test showed me not a good result. I will check back to MARG sometime (and trace each sensoraxis in j ihleins code

). I don't want to bother him with emails, and you until I did that.
@brm: Agreed. I started a normalizationparty with the mwii core and have good results so far (even the mag heading is better now

). I eliminated the trig. doublecalculations in rotateV, so I hope the additional sqrt stuff comes for free. Those fast inv sqrt algos (I tested two) are not so good since they lead to unneccessary errors that harm "I" and "D" calculations (from what I've seen with my results). I'm quiet happy with the normalization, but the GPS ins is completely wrecked for now. BTW: Whats wrong with johns acc calibration?

hinkel · Post by **hinkel** » Tue Feb 11, 2014 8:49 am

Crashpilot1000 wrote: The last days I did some work on the pidcontrollers as well and tried out the mwii2.3 yaw algo. Due to weather I can mostly do benchtesting but it seems to be an improvement. I enabled that for both pid controllers (mwii2.2 and alexK) and doubled the scaled the alexK "D". Hmm I think with proper scaling and "I" limits the alexK could replace the orig mwii but still include the mwii2.3 yaw code. The code is in my really messed up github "JustTestCode" for now in mw.c maybe you can have a look as well if it's any good. Not sure since it's unflown, NOTE: the GPS ins is not expected to work in that because there were changes that need rescaling parameters (not done due to weather).
Just posting the altered main Pid stuff here, hopefully nobody gets hurt looking at this.

Code: Select all

        MwiiTimescale = FLOATcycleTime * 3.3333333e-4f;
        dT            = FLOATcycleTime * 0.000001f;
        RCfactor      = dT / (MainDptCut + dT);                                 // used for pt1 element
        prop          = (float)min(max(abs(rcCommand[PITCH]), abs(rcCommand[ROLL])), 500);
        for (axis = 0; axis < 3; axis++)
        {
            if (axis == YAW)                                                    // We use mwii 2.3 YAW for both pid controllers
            {
                tmp0  = (int16_t)(((int32_t)rcCommand[axis] * (2 * (int32_t)cfg.yawRate + 30)) >> 5);
                error = (float)tmp0 - gyroData[axis];
                if (abs(tmp0) > 50)
                {
                    ITerm            = 0.0f;
                    errorGyroI[axis] = 0.0f;
                }
                else
                {
                    errorGyroI[axis] += (error * (float)cfg.I8[axis] * MwiiTimescale) * 0.001f;
                    errorGyroI[axis]  = constrain(errorGyroI[axis], -268370.0f, 268370.0f);
                    ITerm             = (float)constrain(errorGyroI[axis] * 0.1221f , -250.0f, 250.0f);
                }
                PTerm = (error * (float)cfg.P8[axis]) * 0.015625f;
                if(NumberOfMotors > 3)                                          // Constrain YAW by D value if not servo driven in that case servolimits apply
                {
                    tmp0flt = 300.0f;
                    if(cfg.D8[axis]) tmp0flt -= (float)cfg.D8[axis];
                    PTerm   = constrain(PTerm, -tmp0flt, +tmp0flt);
                }
                axisPID[axis] =  PTerm + ITerm;
            }
            else
            {
                rcCommandAxis = (float)rcCommand[axis];                         // Calculate common values for pid controllers
                if ((f.ANGLE_MODE || f.HORIZON_MODE))
                {
                    error = constrain(2.0f * rcCommandAxis + GPS_angle[axis], -500.0f, +500.0f) - angle[axis] + cfg.angleTrim[axis];
                }
                switch (cfg.mainpidctrl)
                {
                case 0:
                    if (f.ANGLE_MODE || f.HORIZON_MODE)
                    {
                        PTermACC           = error * (float)cfg.P8[PIDLEVEL] * 0.007813f;
                        tmp0flt            = (float)cfg.D8[PIDLEVEL] * 5.0f;
                        PTermACC           = constrain(PTermACC, -tmp0flt, +tmp0flt);
                        errorAngleI[axis] += error * MwiiTimescale * 0.01f;
                        errorAngleI[axis]  = constrain(errorAngleI[axis], -100.0f, +100.0f);
                        ITermACC           = (errorAngleI[axis] * (float)cfg.I8[PIDLEVEL]) * 0.002441f; // Scaled down by 10
                    }
                    if (!f.ANGLE_MODE)
                    {
                        error             = (rcCommandAxis * 64.0f / (float)cfg.P8[axis]) - gyroData[axis];
                        errorGyroI[axis] += error * MwiiTimescale * 0.01f;
                        errorGyroI[axis]  = constrain(errorGyroI[axis], -160.0f, +160.0f);
                        if (abs((int16_t)gyroData[axis]) > 640) errorGyroI[axis] = 0.0f;
                        ITermGYRO         = (errorGyroI[axis] * (float)cfg.I8[axis]) * 0.012207f;
                        PTermGYRO         = rcCommandAxis;
                        if (f.HORIZON_MODE)
                        {
                            tmp0flt = 500.0f - prop;
                            PTerm   = (PTermACC * tmp0flt + PTermGYRO * prop) * 0.002;
                            ITerm   = (ITermACC * tmp0flt + ITermGYRO * prop) * 0.002;
                        }
                        else
                        {
                            PTerm = PTermGYRO;
                            ITerm = ITermGYRO;
                        }
                    }
                    else
                    {
                        PTerm = PTermACC;
                        ITerm = ITermACC;
                    }
                    PTerm           -= (gyroData[axis] * dynP8[axis] * 0.0125f);
                    delta            = (gyroData[axis] - lastGyro[axis]) / MwiiTimescale;
                    lastGyro[axis]   = gyroData[axis];
                    lastDTerm[axis] += RCfactor * (delta - lastDTerm[axis]);
                    axisPID[axis]    = PTerm + ITerm - (lastDTerm[axis] * dynD8[axis] * 0.09375f);
                    break;
// Alternative Controller by alex.khoroshko http://www.multiwii.com/forum/viewtopic.php?f=8&t=3671&start=30#p37465
// But a little modified...
                case 1:                                                         // 1 = New mwii controller (float pimped + pt1element)
                    if (!f.ANGLE_MODE)                                          // control is GYRO based (ACRO and HORIZON - direct sticks control is applied to rate PID
                    {
                        tmp0flt = (float)(((int32_t)(cfg.rollPitchRate + 27) * (int32_t)rcCommand[axis]) >> 4);
                        if (f.HORIZON_MODE) tmp0flt += ((float)cfg.I8[PIDLEVEL] * error) * 0.039063f;
                    }
                    else tmp0flt      = ((float)cfg.P8[PIDLEVEL] * error) * 0.022321f;
                    tmp0flt          -= gyroData[axis];
                    PTerm             = (float)cfg.P8[axis] * tmp0flt * 0.007813f;
                    errorGyroI[axis] += (float)cfg.I8[axis] * tmp0flt * dT * 4.883f;
                    errorGyroI[axis]  = constrain(errorGyroI[axis], -20972.0f, 20972.0f);
                    ITerm             = errorGyroI[axis] * 0.01221f;
                    delta             = ((tmp0flt - lastGyro[axis]) * 0.01638f) / dT;
                    lastGyro[axis]    = tmp0flt;
                    lastDTerm[axis]  += RCfactor * (delta - lastDTerm[axis]);
                    axisPID[axis]     = PTerm + ITerm + (((float)cfg.D8[axis] * lastDTerm[axis]) * 0.023438f); // D scaled up by 2
                    break;
                }                                                               // End of Switch
            }
            axisPID[axis] = (float)((int32_t)(axisPID[axis] + 0.5f));           // Round up result.
        }

Cheers
Rob

Hi Crashpilot1000,
Thanks for your reply, I will test flight this in the next days

Regards
hinkel

hinkel · Post by **hinkel** » Wed Feb 12, 2014 11:05 am

Hi Crashpilot1000,
I made a little test with the last version on your Github ( altered MainPID ), the yaw control seem to be slower with default values there was no issue with it, the level angle mode is drifting ( alternately front or right direction in my case ) but not alltime , also the gyro mode seems to self level sometimes .

mj666 · Post by **mj666** » Wed Feb 12, 2014 3:21 pm

@Crashpilot1000

I'm actually working on adding a new sonar sensor (SRF02) to Harakiri. My code is now nearly ready and I most likely will finalize this today. I published an earlier version of the code (based SGTodaysSnapshot2NoHex) already in the German "FPV-Treff" forum. You published a recently a "mostly tested" version on Github some days ago "SGTodaysSnapshotSave666". This version already disappeared. You also released a few updated versions after this with finally the Flipsupport.hex in this forum. I'm not sure if the "SGTodaysSnapshotSave" is the successor of this versions? I have actually based my changes on this version. The workbench test of "SGTodaysSnapshotSave" where looking good but...? I'm looking for your advice since the code changed since SG2.5 and SG2.6pre in the areas where I was working on. What is a version witch is actually the best version to fly the Copter and finalize my code and make it easy for you to integrate this into the next release. For flying I was using SG2.5 before. I'm using and MW32 v2.2 FC and an UBlox Neo-6m based GPS. I'm looking forward to your feedback. Thanks.

timecop · Post by **timecop** » Wed Feb 12, 2014 3:32 pm

good god will you people start using source control properly.
what the fuck is it with these "snapshot save" shits and starting a new repo for each change, that's basically as useful as posting zip files in a forum....

larzac · Post by **larzac** » Wed Feb 12, 2014 5:29 pm

hint: branch
you also want to split your commits into smaller ones.

Able to code and not able to use git ? gosh you're lucky to get that much interest, it's supposed to run on expensive and dangerous copters, isn't it ? If you're not able to use git rigorously I can't expect your code to be somewhat serious. that's such a waste !

I guess If upstream was using a more restrictive licence we wouldn't see that much silly hex-in-zip files in forums...
While we're at it, upstream might also think of providing a HOW_TO_CONTRIBUTE.md file in their repo with all the steps contribute, for ex: fork, set remote/master, create feature remote tracking branch, edit, commit, rebase, push, talk, and possibly pr...

subaru4wd · Post by **subaru4wd** » Wed Feb 12, 2014 9:15 pm

timecop wrote:good god will you people start using source control properly.
what the fuck is it with these "snapshot save" shits and starting a new repo for each change, that's basically as useful as posting zip files in a forum....

Why does any of this concern you? Don't you have your own project you can maintain?