Harakiri aka multiwii port to stm32

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

I have been flying now a couple of flights with my latest Quad build. And with that being my first serious experience with GPS PH in Harakiri, I am tremendously impressed by how well it works. It is all on default settings and the copter is PH'ing just like it was nothing. Mr. Fiero, I absolutely agree with your comments to PH quality of Harakiri.

Now, the only thing I would like to improve is the way it reacts to stopping in PH mode. When flying around and releasing the sticks in PH, it always backs up and flys back like 2 meters until PH stops it at the spot. I would prefer if upon release of sticks it smoothes into position and then stays where it is without flying back. This would make it easier for slow camera flights in PH mode. Does anyone know if there's a way to configure that?

Cheers,
Olli

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I agree. The flying back for me is only 1M but I am used to that now. I slow down before PH, give it a few seconds and then release. also I set my gps_settlespeed = 200 and it seems to average starting sooner so therefore it reduces my wait time before PH. If I give it 2 to 3 seconds it will hold upon stick release. Still I would prefer the same as you and not have it drift back upon quick release.

Rob has stated there is a 5 second window before it settles.

I too am curious if we can disable this, or shorten it. I did look at the code Rob posted but I dont know how to change it as my programming skills are limited.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi, guys! That is actually not perfect - but I was searching for a method to keep the user always in control and not let the gps fly the copter too much. IMHO some other things concerning the GPS need to be adressed first - aka errorhandling, that must be improved to make GPS functions generally safer.

User avatar
bulesz
Posts: 71
Joined: Mon May 06, 2013 8:03 pm
Location: Hungary EU

Re: Harakiri aka multiwii port to stm32

Post by bulesz »

Guys I have two silly questions:

1. why not implement the GPS part of Harakiri to Baseflight and make one FW to better and better.... ?
2. is Harakiri stable enough to use it instead of Baseflight?

Sorry, just I'm hesitating whatttodo....currently I'm using the latest Baseflight, but for my big bird I need the good GPS...Baseflight is working too (is enough for survive), just not that precise as I have heard how the Harakiri is compared to it...

Cheerz,
B

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Just try it out it has no serious design flaws I know of that will kill your copter. GPS is something you can always oversteer. BF is also fine.

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

bulesz wrote:Guys I have two silly questions:

1. why not implement the GPS part of Harakiri to Baseflight and make one FW to better and better.... ?

:lol: :lol: :lol: :lol: :roll: yeah right. Go read what Timecop thinks about GPS functions, and how he treats others who try to contribute to his Baseflight.

2. is Harakiri stable enough to use it instead of Baseflight?

Sorry, just I'm hesitating whatttodo....currently I'm using the latest Baseflight, but for my big bird I need the good GPS...Baseflight is working too (is enough for survive), just not that precise as I have heard how the Harakiri is compared to it...

Cheerz,
B

Yes, Harakiri is definitely "stable", there's nothing to worry about. Just forget about fancy GUI's cause Harakiri uses the old MultiWii 2.2 gui still.

User avatar
bulesz
Posts: 71
Joined: Mon May 06, 2013 8:03 pm
Location: Hungary EU

Re: Harakiri aka multiwii port to stm32

Post by bulesz »

Thanks guys for the feedback! I will put on HK on my big bird. Why could be when connect to MW gui, that the sensors are not moving? I mean the compass and the quad indicator are not moving... ? I remember something from the MW era...need to REcalibrate the acc and mag?

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Harakiri aka multiwii port to stm32

Post by brm »

Crashpilot1000 wrote:Hi, guys! That is actually not perfect - but I was searching for a method to keep the user always in control and not let the gps fly the copter too much. IMHO some other things concerning the GPS need to be adressed first - aka errorhandling, that must be improved to make GPS functions generally safer.


the error handling is tough.
in certain conditions you can trust the gps - like when the number of satelites grows.
the other way round you get jumps - 10 meters is nothing special as i found out.
trusting the accelerometer is very special. in this area i dislike the mpu-6050 in general.
my two step filter trusted the acc unit too much and i ended up at 3200 meters above sea level where
it should be something like 468 meters ... :roll:
and now you like to override gps ph with your sticks ... trusting the gps or accelerometer.
filtering too much much makes the gps position info sluggish.

it has been fixed - but when testing near the house i constantly lost the gps fix status.

just a lot test of cases ...

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi BRM, i see we are on the same page here. However your approach seems to be more scientific using accelerometer help for validating gps feedback probably in a kalmanfilter with predictive elements and evaluating probabilities. My approach was more crude in this regard because I find acc data not reliable for that (btw I have 3 devices here with mpu6050 and they work well within specs, I've read in the pro thread that there were wrecked SPI mpu6000 parts/flightcontrols around - dunno but it seems unlikely that invense releases non working parts - dead on arrival - at a scale and not writing a letter "hey lot number xxx - xxx may be faulty because our factory fu**ed it up and we will replace them because we want to stay in business and would not like to see our customers to buy adxl, stm, bosch etc" it seems more likely that they were killed in the following process - maybe overheat during reflow - or kicking around the FC in delivery etc). I think I have a concept in my head after some time of thinking about it. The major lack is not the filtering/sensorfusion (cf/Kalman/probabilites etc) but a better general concept so the rest can follow with whatever precision or future expansions. From what I've seen in mwii/eos and arduc it's not what I really want to have. So taking a step back from the features and the low level filtering/fusion capabilities seems to be a fruitful move to me and think about the concept and how it should be done in code. We have already good working GPS/ACC/GYRO/MAG parts here that could be expanded but the context must be reconsidered in my opinion because it will actually safe a lot of time and hassle (&crashes) if we get that straight in the first place.
Cheers Rob

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi, since I've seen the video (http://www.youtube.com/watch?v=EViw4lBRa94) of DC how the ppsum decoder fu**s up - I was thinking what makes this go wrong and what can be done about it without copying over openpilot code (that doesn't even fix frsky 18ms).
The present state in Harakiri (not BF because it is actually worse concerning the failsafe):

Code: Select all

static void ppmCallback(uint8_t port, uint16_t capture)
{
    static uint16_t now, last = 0;
    static uint8_t chan = 0;
    uint16_t diff;

    last = now;
    now  = capture;
    diff = now - last;

    if (diff > 2700)   // Per http://www.rcgroups.com/forums/showpost.php?p=21996147&postcount=3960 "So, if you use 2.5ms or higher as being the reset for the PPM stream start, you will be fine. I use 2.7ms just to be safe."
    {
        chan = 0;
    }
    else
    {
        if (diff > 750 && diff < 2250 && chan < MAX_RC_CHANNELS) captures[chan] = diff;// 750 to 2250 ms is our 'valid' channel range
        chan++;
        failsafeCnt = 0;
    }
}

This routine is an interrupt handler that is called when there is a change of flank on the ppsum input pin (so the time between signaledges can be measured).

So look at this part of it:

Code: Select all

        if (diff > 750 && diff < 2250 && chan < MAX_RC_CHANNELS) captures[chan] = diff;
        chan++;

The measured pulsetime is compared against a valid range and the result is stored as result in "captures[chan]" however the index "chan" is always increased (on flank change of course), whether the signal is correct or not. So if an invalid signal arrives (like a spike of some sort) it is not stored but the index is increased and the next valid signal will be stored (if the index is within the arraybounds - of course) with an index+1 (" chan++"). In thoses error situations the channelorder is disrupted and bogus data make it into the wrong "capture" variable ("software channel"). So you can end up with a result of mixed up data for that complete frame / channelset, until a new sync gap is detected - then the process starts over again (EDIT: probably undistrubed this time). Most probably those mixed up channel situations are limited to one frame only (if they occure more often because your ppm line suffers from severe EMI disturbance you have a real problem). But there is more. Some older Frsky sumsignal RX can produce trouble because they transmit 8 channels in 18 ms (8Ch * 2ms = 16ms, so only 2ms left for sync but minimal 2,7+ms are needed for sync detection = fail). This will only happen if 7 channels are maxed out (7Ch * 2ms = 14ms) and one channel exceeds 1300us = 1,3ms (in reality the 8th channel may be more limited because the other channels may be 2010us or 2050us or so.. due to potentiometer drift). There is a frsky 27ms (frametime) firmware available but some RX are not flashable and they will reduce the transmitting frequency to (1000ms/27ms) 37,03HZ so you will add 35% more unnecessary inputlag (27ms vs 20ms since the read out is at 50Hz) to cover those rare situations. (Note: Arducopter has out of control situations for other reasons than some RX problem alone - they are a good habit of their code for YEARS now. So pointing the finger at another company is not enough). Another way to keep 50Hz is to reduce aux1-aux4 to 1500us (so it's mid switch position in the GUI). That will do: 4ch * 2ms + 4ch * 1,5ms = 14ms so 4ms left for sync (2,7ms is needed) in the 18ms frame. That will fulfill most needs for safety (won't get better with 27ms FW) and low latency (stays at 1000ms/18ms = 55,6Hz, interpreted at 50Hz rate in code) - of course you will loose one possible state on each aux channel (so only on and off are possible). When you have an undisturbed line between RX and Flightcontrol (naze, flip, mw32 whatever) - maybe twisted cables - maybe with a ferrite you can cover up those rare and brief situations in software by forcing a sync every 8 successfuly read channels. I tried it and provoked possible out of sync situations for MINUTES and my altered code kept perfect track. It was tested on affected Frsky RX D8R-II and D4FR. The normal sync operation is used (2,7+ms gap) of course most of the time because problematic situations are rare. The altered code does an autocheck for ca. 500ms that is done on first radiocontact (so most probably on powerup, or do you power up copter before TX... and even if so, no problem). It checks frametime below 18,3 ms and 8 channels if true for 30 consecutive reads (540ms) the frsky workaround is engaged for that flightsession. I can not guarantee that my frskypatch will always work because there is always a statistical chance to loose the sync in such "too small gap" situations but it works for me. From looking at the mwii code it seems to have the same issues but I haven't fought my way through the "#define" stuff to make it readable for me. So here is the proposed code that fixes both issues (bogus data and small frame Frsky). The code is mostly (however not exactly in the present form) submitted to BF as pullrequest (since it's safety relevant) but I will not bother wasting more time on BF.

Code: Select all

static void ppmCallback(uint8_t port, uint16_t capture)
{
    uint16_t        newval = capture;
    static uint16_t last = 0, frametime = 0;
    static uint8_t  chan = 0, goodcnt = 0, frsky_problemcnt = 0;                    // Frsky 18ms on 8 Channel Problem Autodetection
    uint16_t        diff = newval - last;
    bool            sync = diff > 2700;                                             // rcgroups.com/forums/showpost.php?p=21996147&postcount=3960 "So, if you use 2.5ms or higher as being the reset for the PPM stream start, you will be fine. I use 2.7ms just to be safe."
    last = newval;

    if (frsky_problemcnt == 30) sync |= goodcnt == 8;                               // FrSky 18ms Fix, force sync after 8 good channels in a row
    else frametime += diff;

    if (sync)
    {
        if (frsky_problemcnt != 30)
        {
            if (frametime < 18300 && goodcnt == 8) frsky_problemcnt++;
            else frsky_problemcnt = 0;
            frametime = 0;           
        }
        chan = 0;
        goodcnt = 0;
    }
    else
    {
        if (diff > 750 && diff < 2250 && goodcnt == chan)                           // Only capture if channel order is correct and Range: 750 to 2250 ms
        {
            if (chan < MAX_RC_CHANNELS) captures[chan] = diff;                      // Wanted and presented channelnumbers can be different.
            goodcnt++;
        } else goodcnt = 0;
        chan++;
        failsafeCnt = 0;
    }
}

- Sorry for my English-
Cheers Rob

Note: I will not flash my D8R-II to the 27ms FW.....
Edit: Here is an older incarnation of the code with no autodetection fixing frsky 18ms problem: https://vimeo.com/101973730
Last edited by Crashpilot1000 on Mon Aug 04, 2014 2:44 am, edited 12 times in total.

User avatar
bulesz
Posts: 71
Joined: Mon May 06, 2013 8:03 pm
Location: Hungary EU

Re: Harakiri aka multiwii port to stm32

Post by bulesz »

Guys, where can I find the latest hex for rev5 board? (I guess it is the Test code 4 aka Summer Games pre 2.6?)
Many thanks,
B

gerardo85
Posts: 8
Joined: Sun Aug 03, 2014 6:33 am

Re: Harakiri aka multiwii port to stm32

Post by gerardo85 »

Hi guys, I have a question regarding Magnetic Declination, I read in an earlier post for example if your magnetic declination is 13 degree 13 east it should be "set mag_declination 1313" so what if my location the degree is 0 and 13 east? Do i just set it as "set mag_declination 13" ?? Or just leave it at the default 0? I'd love to give Harakiri a try but I can't seem to find sufficient information on it. Like what do you guys use to view it or change cli in it. I've tried to flash it using baseflight chrome gui and also using the flash loader demonstrator stated in the naze32 manual. Both times successful, tried to view it with both multiwii 2.2 and 2.3. It connects saying version 211 the graphs move but i don't see the model moving. Also there is no cli in it. So i'm kinda clueless here. A rough guide would really help.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi.
In opposite to multiwii the mag declination needs not to be calculated. The degrees must be in the "hundreds" and the minutes are the last 2 numbers (if the sign is negative you have to write it as well). So 1 deg 16 minutes East (positive) will be mag_dec = 0116. 13deg and 13 minutes east are mag_dec = 1313. (Edit: So 1 deg 1 minutes West (negative) is mag_dec = -0101 or mag_dec = -101)

Since I've been so lazy with the gps stuff I updated Testcode3 with some fixes (note: Testcode4 was just a different gps spikefilterhandling that some ppl didn't like..). Here is the repo https://github.com/Crashpilot1000/TestCode3 I tried to commit and ended up with number 26 so the following zipfile is called "Testcode3_r26.zip". The changes:

- Some tailwag in fast FF was reported. That was most probably a problem with the "Yaw I" calculation. *fixed*
- Horizonmode was too weak on the stick edges for my taste - comes around better now. *fixed*
- Frsky telemetry: wrong formated GPS data, wrong formated Heading, negative hight not possible (so zero is minimal hight). *fixed*
- Reworked the mixer upper limit handling. The overshoot is limited to throttlerange + 85% and if the throttlerange is exceeded it is scaled down now. The former mwii approach was to simply substract the overshoot and done. Dynamically adjusting the scale gets better stability in those situations from my testing. So better fullthrottle handling, Yaw is kept, copter still *somehow* steerable with way too high P oscillations.
There is a parameter in cli "esc_nwmx" that means "newmix" it is per default on ("1") but you can choose to use the orig. multiwii handling as well with "0".
Note1: Going full Throttle in multicopters will always get you into more or less stability trouble.
Note2: TPA - users. Due to the nature of the changed full throttle behaviour of the mixer it may be resonable to reduce your TPA.
Note3: The normal mwii full throttle handling is also a little better (esc_nwmx = 0) because it is limited to not cut off all the PWM range -> keep yaw.
- The RX sumsignal handling is improved (see post above).

* Use mwii 2.2/2.3 gui for setup and a serial monitor like https://sites.google.com/site/terminalbpp/ (EDIT: Other guis and stuff will most probably not work and might freeze - though naze&harakiri are working and doing fine. Note: Due to some mavlinkstuff implemented the parameterlist can be edited with missionplaner, however it will complain about missing arducopter stuff) . 3 times return or # enters cli "<RETURN><RETURN><RETURN>" or "###". "RRR" enters flashmode or type "flash" in CLI.

EDIT EDIT: Don't use some GUI besides the STM Flash loader for flashing.
Here are 2 downloadlocations:
http://www.st.com/web/en/catalog/tools/PF257525
https://code.google.com/p/afrodevices/d ... p&can=2&q=
Both tested and work. Make sure you tick "Global Erase" and "Jump to the user program" in the flash tab. Check if your device is recognized with correct 128K rom, otherwise change it in the drop down menue (I have one older naze3 that is detected with 64k for whatever reason).

Preset values you might want to change:
QUADX
FEATURE_PPM
expo 80% (gui)
esc_min = 1100
esc_max = 1950
mag_dec = 113

Cheers Rob
Attachments
Flashloader options that should be ticked
Flashloader options that should be ticked
Testcode3_r26.zip
Contains .bin and .hex file so you can choose what you need.
(180.51 KiB) Downloaded 228 times
Last edited by Crashpilot1000 on Tue Aug 05, 2014 5:18 am, edited 12 times in total.

User avatar
bulesz
Posts: 71
Joined: Mon May 06, 2013 8:03 pm
Location: Hungary EU

Re: Harakiri aka multiwii port to stm32

Post by bulesz »

Many thanks Rob!

The esc_min / max is the min/max throttle?

Just as on the sides: would rename the testcode3 to something "newer", coz beside the testcode4 it is a bit confusing for the newcomers, which one version to pick.

Many thanks,
B

strips
Posts: 163
Joined: Thu Apr 03, 2014 1:28 pm

Post by strips »

Hi Rob,

Where do you stand in the Oneshot world? Is it something you would concider to implement?

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@Bulesz you are right. I did some renaming a (hopefully) complete list is in the readme https://github.com/Crashpilot1000/TestC ... E.txt#L390
@Strips: I followed the oneshot discussion and reasoning in the BF part of this forum and I can not comment on their function besides all the strong opinions there I am not so sure that oneshot isn't working at all. I think Flyduino should really release a special naze fw for those esc (they also sell mw32v2) so that their oneshot ESC customers can see/feel the difference - shouldn't be hard to do for them. Oneshot is currently not on my agenda, I prefer headshots with a silenced Bulldog in Battlefield 4...

User avatar
bulesz
Posts: 71
Joined: Mon May 06, 2013 8:03 pm
Location: Hungary EU

Re: Harakiri aka multiwii port to stm32

Post by bulesz »

OFF: Hohohohoooo! Another Bulldog noob.. :D I love the Bulldog too in BF4... ;) very naice weapon for the medic. ;) what's your nick there? We could hunt together sometime... ;)

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

Fiero, here is an older (March 2014) post from Rob/CP1000 where he describes the workings of braking into PH. You probably know that already, but maybe to serve as a basis for discussing that.

http://fpv-community.de/showthread.php?18349-NAZE32-alternative-Software&p=565713&viewfull=1#post565713

To quickly sum it up:
- First the prebrake takes gps_ph_brkacc (in cm/s), which is the applied "braking power" to brake the copter down to gps_ph_settlespeed (this is also cm/s). The prebrake is limited to 5 seconds max.
- Then the true PH code kicks in.
- PH code first waits as long as gps_lag, to give the GPS time to deliver newer coordinates (as GPS is always lagging behing)
- Then this latest GPS position is taken as PH position. This is were is can happen that the copter is moving backwards, as it might have already flown further as the GPS coords after gps_lag.
- Rob also said that he had some tries with lookahead GPS coord calculations, but this did not work out.

So theoretically with a higher gps_ph_settlespeed we should also have a bigger "overshot". I have already set it to 200 cm/s, but have not yet had a chance to try it out.

DIE_KUH
Posts: 19
Joined: Thu Feb 06, 2014 4:18 pm

Re: Harakiri aka multiwii port to stm32

Post by DIE_KUH »

For some reason I had problems with Testcode3_r26: First it appeared to flash successfully using the Baseflight Configurator for Chrome, but the Naze32 was non-responsive and I had to re-flash it to Baseflight using the bootloader pads.

Then I tried it with the Baseflight GUI (which isn't developed any longer, iirc). Flashed successfully.

Then I wanted to calibrate the ESCs because the motors started at different throttle values (which they didn't with Baseflight), so I used "feature pass" in the Baseflight GUI and could calibrate the ESCs. Unplugged the battery and USB, plugged in USB again to disable the pass-through mode with "feature -pass", but... the Naze was unresponsive again, didn't boot correctly and I also couldn't connect via USB. So, a second re-flash to Baseflight using the bootloader pads, and then I gave up.

Is it normal behaviour that I can't reconnect to the Naze32 after a "feature pass"?

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

Kuh, there have been some problem reports with leaving the pass feature, but none I know of where the CLI was completely unavailable. KB59 had written something qualified:
http://fpv-community.de/showthread.php?49746-Befehl-quot-feature-pass-quot-wieder-verlassen

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Thank you very much Bamfax for straightening out some things here!
Die_Kuh: Your lockups/problems are completely gui related - over and out. It seems you are through all the non recommended stuff and found out why it isn't in the list. I updated the post with some info on flashing just to be sure. feature pass (and feature -pass for disabling) and selecting separate motors with pass_mot = X (x = motornumber, x= 0 = all motors) works like a charme (don't forget to save between commands). "feature foo" always ENABLES and "feature -foo" always DISABLES a feature that's the logic behind all feature - cli - stuff. "save" actually saves the data in eeprom and does a reset, "exit" doesn't save.

DIE_KUH
Posts: 19
Joined: Thu Feb 06, 2014 4:18 pm

Re: Harakiri aka multiwii port to stm32

Post by DIE_KUH »

Danke! :) What was weird however was that not only could I not disable passthrough, I also couldn't connect at all. I do understand the logic behind the CLI stuff ('-', save, exit...), I just couldn't access the Naze _at all_ (with Baseflight GUI).

I would have preferred to use the Baseflight Configurator because I think using the sliders in the motors tab is safer than using the radio. Easier to access single motors, set defined values and instantly switch the motors off.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »


So theoretically with a higher gps_ph_settlespeed we should also have a bigger "overshot". I have already set it to 200 cm/s, but have not yet had a chance to try it out.


Except I saw in the code that it was also a condition that had to be satisfied before allowing PH, so it will not kick in until speed is less than.

I could be wrong how it works, but it is working well for me at this point. At times i do travel quickly then release and it does a pretty good job braking and then PH with maybe a quick circle at 1M max. Sometimes its a circle, sometimes it drifts back over previous flight path. It seems the faster speed I travel will invoke the circle as its fighting with the braking. When my circle fight on PH/stick release happens, usually its in a hostile environment as we have allot of wind where i live . The wind is probably the cause of the circles, but really its very small and I can work around it. I would adjust my braking but everything works so well if my speed is less than 200cm/s that I dont want to change anything. PH has been so dead on for me, on all my machines and I have been able to move forward with other projects on the multicopters now. Like putting the wife's samsung nx2000 on the hexacopter....LOL, for real its going up as soon as I get my last parts.

------------------------------

> Crashpilot1000 : Since you updated TestCode3, did you fix the PH mode, alt adjust, having to return to center first, issue? I didnt see it in the notes about your update. i am scheduled for major flying today but after I am going to update the firmwares and re-test.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Mr-Fiero wrote:------------------------------

> Crashpilot1000 : Since you updated TestCode3, did you fix the PH mode, alt adjust, having to return to center first, issue? I didnt see it in the notes about your update. i am scheduled for major flying today but after I am going to update the firmwares and re-test.


The PH stuff is in the other codebase that isn't online and it isn't fixed yet. The annoying althold not recognizing the throttlestickcenter when you are too fast on the throttlestick is also in that codebase but not ported over to testcode3 r26 because there were also some changes that were to hard to decomb for a "quick" update. The main reason for that update was to bring the fix for ppsum and the more agile horizon. I will port that throttlestick althold anti annoying patch in the evening and testflight it (it's 6 am, sitting here with my morning coffee..).

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

OK. I understand. If you are successful porting the fix for alt adjust it would be awesome.

Every once in a while it gets me if I am PH in a tight spot, and low altitude. Finding that centre first then back to throttle up for alt gain, sometimes I miss and when I get critical for low altitude if it is slightly loosing altitude and I need it to either stay, or gain. When things are tight I don't look at my radio to see if its centre because of the distraction. so I end up trying to find it by random stick positions but ready to take it into stabilize quickly if needed. Its only on my photo unit that I feel this pressure as its usually the only one that would be in a tight spot and using PH.

Its a small problem, but at times its just a pain. Cant wait to see if you get the patch into TestCode3, but no pressure. I have been having sooooo much success with your TestCode3 and am very happy.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Well Mr-Fiero I think you will love this one then as well!
The integration was a breeze. Althold, Autostart and Autoland tested - works like expected. Besides the better "has passed throttlemidstick position" (better means, it can not be missed anymore if you are "too fast" on the stick) you will notice that the hightchange is more agile and that the stoppingpoint prediction is better.

Cheers
Rob
Attachments
Testcode3_r30.zip
Contains hex and bin. Presets are the same like already posted.
(181.33 KiB) Downloaded 241 times

User avatar
bulesz
Posts: 71
Joined: Mon May 06, 2013 8:03 pm
Location: Hungary EU

Re: Harakiri aka multiwii port to stm32

Post by bulesz »

Thanks Mate for your hard work, I could try it out in the weekend with my big bird.

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

Mr-Fiero wrote:I could be wrong how it works, but it is working well for me at this point. At times i do travel quickly then release and it does a pretty good job braking and then PH with maybe a quick circle at 1M max. Sometimes its a circle, sometimes it drifts back over previous flight path.


I have flown two LiPos today with Fiero's gps_ph_settlespeed 200 and also a much more gentle RC Rate, to be able to have a more gentle steering style.

First the bad thing, releasing the sticks at fast forward did not work out at all for me, this ends in a random position somewhere up to 20 meters away from where I released the sticks. This is surely influenced by the very 'scale' like PID config I am flying with. There's also no prebrake tuning done yet.

Now the good thing, moving into PH is now without flyback at all. So if I move it manually into position and let go of the sticks, it just stays there. Rhis is absolute great and just what I had hoped for. Thanks for the help Mr. Fiero.

And everyone was again amazed by how stable the PH was.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I attribute the quick release and position jumps at high speeds due to the fact you might be over the 200cm/s speed. Brake settings and PID tweaks will help with that fur sure, but PH will not be accurate until it has time to average and your speed is under the 200cm/s.

For myself I realize that flying while in PH not a normal practice. Most people dont fly while in PH. PH is usually activated once in postion, not full time. I find it works well flying full time and its very useful for my purposes mostly of which are photography and surveys. At times I am using PH now with only maybe 2M clearance all sides or less, and its tight PH drifting maybe 10-20cm . My buddy that is another multicopter pilot was so amazed it was that tight for a whole lipo. If it didnt work, I have NO room on the sides, so I am so happy it is so accurate! I think my GPS upgrades also enables this to be possible. I have never seen any other setup be this tight on PH, ever......till now.

Being as functional as it is only verifies that Harakiri is very functional for GPS functions, if thats what one desires. I have now tons of hours on TestCode3 %90 PH mode, and no incidents. I have been launching even sooner as I dont wait for all the SV's, and as soon as I hit 6 or more, I launch. Usually later I gain more, but while in PH, it has never jumped or done anything different as SV's increase.

gerardo85
Posts: 8
Joined: Sun Aug 03, 2014 6:33 am

Re: Harakiri aka multiwii port to stm32

Post by gerardo85 »

Hi all,

Is there a way to see like my rc connections with Harakiri? I've managed to flash it in, able to enter cli in putty but when i open the multiwii gui, the sensor graph is moving but nothing else moves. The model of the quad doesn't move when I rotate it and I can't check if my rc connections are working. Also do you connect gps to 3 and 4 in the rc connections like in baseflight? Is there any settings that need to be done? Wingui didn't seem to work as i couldn't find any .exe file in the folder downloaded. Take it as i'm a total noob because I am for now... As for magnetic declination, I live in singapore, the info at http://magnetic-declination.com/ says Magnetic declination: 0° 13' EAST. So does that mean when i set it harakiri it should be "set mag_dec=13" Because i tried keying in "0013" the number just becomes 13. Any help would be greatful.
Last edited by gerardo85 on Wed Aug 06, 2014 8:30 am, edited 1 time in total.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Crashpilot1000 wrote:Well Mr-Fiero I think you will love this one then as well!
The integration was a breeze. Althold, Autostart and Autoland tested - works like expected. Besides the better "has passed throttlemidstick position" (better means, it can not be missed anymore if you are "too fast" on the stick) you will notice that the hightchange is more agile and that the stoppingpoint prediction is better.

Cheers
Rob


You rock! Thank you very much..... I am going to flash tonight, charge all the batts, and try it tomorrow as I am currently on holidays. I cant wait to try the code. I just noticed, its already compiled! Thanks again!

Hydroculture
Posts: 5
Joined: Wed Jan 22, 2014 5:42 pm

Re: Harakiri aka multiwii port to stm32

Post by Hydroculture »

Hi Roberto!

Thank you for continuing the good work!
As some people seem to have installed your Testcode3,

can someone tell me if the Buzzer is working?

Its important for me to be able to find back my FPV-model.

Thank you

Holger

gerardo85
Posts: 8
Joined: Sun Aug 03, 2014 6:33 am

Re: Harakiri aka multiwii port to stm32

Post by gerardo85 »

Hi all, i'm getting more results now but still not quite there yet. For now after calibrating acc and mag i have that small model of the hex moving. Compass is also moving. Basically all my guages are working in the multiwii gui. Everything other then my receiver. But when i flash baseflight or cleanflight both will show that my receiver is working. Only harakiri i have no signal. I have my gps hooked up to connectors 3 and 4. The gps word is also lighted green. So am i missing something guys? I'm using a taranis with a x8r receiver.

edit
I somehow got it working by enter cli enabling ppm, save, disable ppm, save and now it works...!! Not sure why but it does.
Last edited by gerardo85 on Wed Aug 06, 2014 1:49 pm, edited 1 time in total.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Thx for the nice feed back Fiero and Holger but check it out first..... Buzzer should be running even on Naze5 since the first Testcode3 and I have reports that it is actually working - sorry for just 3rd hand feedback, I have no buzzer installed. BTW I wished the BF ppl would have looked at the sonarcode in Harakiri instead of implementing exactly the same faulty logic like seen in Arducopter...
Declination 0° 13' EAST is mag_dec = 13. Multiwiigui 2.2 and your terminal program can not be used simultaneously (btw putty is sh*t) you have to exit the cli first ("exit" or "save" like described above). The default is set to sumsignal. If you are not using that you will have to disable it in cli.
Cheers Rob

DIE_KUH
Posts: 19
Joined: Thu Feb 06, 2014 4:18 pm

Re: Harakiri aka multiwii port to stm32

Post by DIE_KUH »

Maybe a stupid question: How sensitive is the Harakiri GPS-code to magnetic interference? I'm asking because I just built a new copter with a full-featured Naze (normally I only use Acros), and the first time I switched on the mag, the heading got out of control pretty quickly while hovering. Mag was calibrated of course, and on the bench it showed the correct heading and orientation... is RTL (I only need RTL) dependant upon good mag values or can it work with just the GPS heading?

To the people who successfully use GPS on a Naze32: How did you cope with magnetic interference? Is it possible to use an external magnetometer with Harakiri and a Naze rev.5? Or did it just work?

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

Kuh, a good working Mag is essential for GPS functions. You need to verify it on the bench by also giving it throttle (=current). Disturbance of the mag is primarily hardware related, not software.

DIE_KUH
Posts: 19
Joined: Thu Feb 06, 2014 4:18 pm

Re: Harakiri aka multiwii port to stm32

Post by DIE_KUH »

Yup, I know it's hardware related, I just wanted to know if the software can somehow cope with it. Guess I'll need to take it apart and check how the ESC/FC placement and cable routing affect the mag. Not easy on a small(ish) frame. :( Would be much easier with an external mag.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

The gps groundcourse is not meshed with the magnetic heading. In planes the GPS gorundcourse can be enough since they can't go suddenly 90deg right or even backwards in the same moment, they fly forwards and do turns like an oiltanker. It might be possible with interpreting the stickinputs and not too much wind (so the assumed flightdirection is mostly in line with actual flightpath) to correlate wrong mag readings with gps reports but I have not seen any flightcontrol that can reliably do that. So have your mag undisturbed, put the FC higher above the powerdistribution, twist powercables and put an aluminium plate (or copper etc) below the naze to short cut inductive magnetic fields. The closed plans hardwarerefresh of TC with N5 didn't implement some solderpads that could be unsoldered to disable the onboard mag. Due to the HMC devices having an unchangable I2C adr. it is not possible to solder up another HMC mag and software disable the onboard one. So it's a hardwareproblem in every aspect you are facing (copterdesign and FC) GPS functions will not work with disturbed mag.
EDIT: However I see a way to do GPS functions in a copter completely without Mag and declination that would have some shortcomings and would require some attention in flight and a feedback to the pilot in some way (buzzer, telemtry etc to show gps might be usable now). On launch GPS functions would not be available. The pilot then flies with some good speed (and enough sats) only into ONE direction then the yaw gyro could be aligned to be GPS north (incl declination). The north direction will be known for SOME time (depending on gyro drift, benchtests are not enough since gyros drift besides temp and vibration on acceleration as well) so that is something that could be done and may produce *somehow* usable gps functions without mag. A possible situation could be: You fly out of RC range, FS and RTH are engaged and you already speeded enough to align gyro yaw to know north. In that case the copter would come back some way and then may loose heading and screw up the RTH but he would be already in RC range again and you could control it. Hmm. I am pretty sure there are more ways but after all it is unpractical to have GPS without a working mag.

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

One question I always wondered about is, does the "autonomous steering", for example stabilizing and GPS PH, always go through the PID controllers? Ok, for stabilizing this is quite clear, since this is what we are tuning. But all GPS steering is also handled this way? So if I have an oscillating copter, it will also oscillate when it's autonomously GPS PH'ing? And the other way around, with a sluggish oiltanker PID I will also have a sluggish oiltanker prebrake, GPS PH'ing etc.? Is that somewhat correct?

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hallo Bamfax! Somehow I don't get your question :). Besides Autoquad wich uses (unpublished?) advanced adaptive control all opensource FC run their data through ordinary PID controllers. GPS functions use the level mode in multiwii so that has to be tuned and working in the first place. If you get small shakyness it's most probably the D part of the main PID loop. You can adjust the filter for it with maincuthz = 12 Hz (default). Lowering that value will filter more but may make the D term useless / kill the function.

User avatar
Bamfax
Posts: 55
Joined: Thu Jan 10, 2013 9:08 pm

Re: Harakiri aka multiwii port to stm32

Post by Bamfax »

I admit it was a slightly dumb question, the more I think about it. I was thinking about how the code steers the copter, e.g. how you do a "drift left 10" or a "brake with 40 cm/s, but max. tilt of 15 degrees". So I kinda got confused if that is directly done in the sense of "instantly pitch 10 degrees and give throttle until brake completed" or in a more indirect way. And then if and where the PID controller comes into play. With a little thinking I would have realized that everything goes through the PID controller.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Mr-Fiero wrote:
Crashpilot1000 wrote:Well Mr-Fiero I think you will love this one then as well!
The integration was a breeze. Althold, Autostart and Autoland tested - works like expected. Besides the better "has passed throttlemidstick position" (better means, it can not be missed anymore if you are "too fast" on the stick) you will notice that the hightchange is more agile and that the stoppingpoint prediction is better.

Cheers
Rob


You rock! Thank you very much..... I am going to flash tonight, charge all the batts, and try it tomorrow as I am currently on holidays. I cant wait to try the code. I just noticed, its already compiled! Thanks again!


Looking forward for your report :geek:

User avatar
farzadsw
Posts: 10
Joined: Tue Mar 19, 2013 8:20 am

Re: Harakiri aka multiwii port to stm32

Post by farzadsw »

Hi all
I have a custom build stm32 hardware, recently I tested Baseflight code and it was OK but default (baro)althold and (GPS)PH didn't work properly.
So I Want to try harakiri code on my hardware.
Does it configure GPS module (Ublox) automatically or I should configure it manually using U-Center? What is preferable Settings?

I have just started reading the code, Hoping to contribute to project.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

OK, I have flown 8 batteries with 15 minutes each battery on the TestCode3 r30 code and here is some results.

The altitude adjust while in PH is great. Works well but I had to adjust my PID's as at first it was up and down a bit +/- .2M. reduced the d and it helped allot. Its now as tight as ever.

The mag/yaw had issues at times so I recalibrated and tested again. It was the same thing, while in PH it would twist, I would adjust and it would do it again. I suspect I need to play with the PID on that also. I did notice that it only does it while in a wind, so I re-tested at a low level and it was not doing it. This is something that I think can be adjusted out.

Flying in PH is different. The flyback is HUGE. Even if I reduce speed, hold position for 5 seconds, it still will try to flyback, and after 20M I get back on the sticks. But, If you fly in stabilize to position, activate PH, It locks right away. And its really tight so PH is fine, just flying in PH and releasing sticks even if its a slow speed causes allot of flyback. This is very different from previous code. before I had my flyback down to 1M with speeds under 200cm/s. This is something I feel I can not adjust for.

Another thing I noticed, is that I was able to increase the Level PID to higher P and it helps with PH mode. before I could never set my P that high, but now it seems to respond crisper. I need to fly more to see but the unit does act slightly different in all aspects. Like I said, I will play with all my PID's and see if I can get it calmer for FPV/GPS . I was flying with my previous settings but they are now slightly different.

I do really like the alt adjust in PH not having to hunt for centre, so I am going to continue to adjust the other changes and see if the flyback can be reduced somehow. Thanks Rob for the new code. I had no incidents that indicated and bugs, just differences so far.
Last edited by Mr-Fiero on Fri Aug 08, 2014 5:03 am, edited 1 time in total.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

farzadsw wrote:Hi all
I have a custom build stm32 hardware, recently I tested Baseflight code and it was OK but default (baro)althold and (GPS)PH didn't work properly.
So I Want to try harakiri code on my hardware.
Does it configure GPS module (Ublox) automatically or I should configure it manually using U-Center? What is preferable Settings?

I have just started reading the code, Hoping to contribute to project.


You need to setup your GPS via Ucenter to start. If you set gps_type = 1 it tries to pass basic settings to your GPS from your FC, but if you baud is wrong at first, it does not seem to autobaud well, I have never seen it work. To be honest, I didnt look at the code to see if it even has autobaud. Your better off setting everything via Ucenter anyways and make sure to save to eeprom. multiwii gui will let you know if your GPS is working as it should.

once you have your GPS working, (check baud) make sure you calibrate your mag as the firmware will not enable GPS functions until your calibrations have been done.

I am going to upload a GPS config for Ucenter to get you started. Feel free to find any better tweaks. Match your baud of GPS in Harakiri when your done. Also if you get errors while uploading into GPS, most can be ignored because all GPS's are not the same, (watch with ones are errors) but double check for anything wierd in Ucenter. Sorry about the older file, but I have not completed my Hex as I am waiting for parts.... When I do get it flying, and tested, I will post a newer config for the Ublox. Do check the "rate" setting because I might have it set to 10Hz. if your GPS is a "6" series like NEO6, LEA6, or such, use 5Hz. If you cant find the message rate in Ucenter, 10Hz wont hurt too much, it just does not help and it burdens the GPS a bit.
Attachments
GPS Neo6 35mm May 25 2014.rar
Load into Ucenter, save to GPS, and make sure GPS save eeprom.
(823 Bytes) Downloaded 207 times

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@Bamfax: Having condition X and tilt Y into direction Z degree will end up in an never ending casemachine but hey, no problem!
@Mr-Fiero: Thank you very much for your extensive report! If you look at the code changes https://github.com/Crashpilot1000/TestC ... its/master you will see that the GPS part is completely untouched. Maybe you changed some parameter within your former setup and just didn't change that after the reflash with the actual version? Just guessing here. The main PID controller behaviour may have changed for you because of the altered mixing procedure dealing differently with exceeding maxmotor situations, you may recheck with orig. mwii behaviour with esc_nwmx = 0. Hmm.

EDIT: I have ported over g-tune (viewtopic.php?f=8&t=5190) to harakiri but that is currently by far not a working option. It seems to be *somehow* getting a P term but then overshoots and not backs off adequately to counteract severe oscillations. I-term seems way to low, D-term is not calculated. The basic idea seems good but there is much development (and high grass) needed to make it actually safe and usable.
Cheers Rob

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I will double check all my settings from previous, but I dont think anything would of been ignored unless there is new variables because I use the CLI dump, copy text into spreadsheet, and then insert column with "set", export to text space delimited and then copy paste into terminal while in CLI. Usually this works %100 for a copy from one FC to another. It also enables me to edit in the spreadsheet.

Hopefully I can test more today. I am going to focus on GPS/PH and see if I can tweak it out for flyback. Like I said, if I fly in stabilize, then activate PH, it locks so well, even if its still moving before activation. PH is VERY tight once locked! Its just the flying in PH, then letting go of sticks, it acts different. I didnt think you changed the GPS code, but now that you confirmed that, I will focus on my settings. Something is different for me and I will find it eventually. I am going to test PH mode more next flights. I was mixed modes before while testing so I didnt spend enough time on the PH.

about the g-tune, what an awesome idea. I would be very interested once the code is working to test!
Last edited by Mr-Fiero on Fri Aug 08, 2014 8:10 pm, edited 1 time in total.

User avatar
farzadsw
Posts: 10
Joined: Tue Mar 19, 2013 8:20 am

Re: Harakiri aka multiwii port to stm32

Post by farzadsw »

@Mr-Fiero: Thanks a lot, I have configured the GPS and every thing seems OK. I will test the quad tomorrow.

@Crashpilot1000: I tried to compile the testcode3 project file using Keil uvision 4 (RealView compiler), but It failed. Did I missed something?
(I managed to compile the code successfully After changing projects setting to GCC compiler)

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Mr-Fiero: I keep my fingers crossed! I fiddeled a little around with G-tune. Currently it could be used very well on the yaw axis - it does a good job there, have to do further tests but the Yaw P autosetting has a good chance to make it into harakiri as an option (like setting yaw P to 0 and MHefnys' code will be engaged).
farzadsw: Last time I checked Keil uvision was 2000$ or something like that so I just use GCC. Since you've spent the money you must be a pro, maybe you can report back how you fixed the compiling issues. I will not download or use hacked/cracked stuff like advised/mentioned by e_lm_70 in another thread here in the multiwiiforum. I am using the free demo version of it for editing and like it very much.

User avatar
farzadsw
Posts: 10
Joined: Tue Mar 19, 2013 8:20 am

Re: Harakiri aka multiwii port to stm32

Post by farzadsw »

Crashpilot1000 wrote:farzadsw: Last time I checked Keil uvision was 2000$ or something like that so I just use GCC. Since you've spent the money you must be a pro, maybe you can report back how you fixed the compiling issues. I will not download or use hacked/cracked stuff like advised/mentioned by e_lm_70 in another thread here in the multiwiiforum. I am using the free demo version of it for editing and like it very much.


I'm using my university's license for RealView. Anyway, adding "--c99 --gnu" to misc controls (target option->C/C++) solved the problem.
It is a bit confusing, Isn't it better to change default project file's setting to GCC compiler?

Previously, I have used multiwii project and write small programs for relative altitude holding (SRF08 Sonar and Sharp IR), auto take-off and PH based on optical-flow data (No GPS). I can port it to STM32 platform but considering required hardware (SRF08, GP2Y0A02, MK808,webcam), I guess it wouldn't be useful for every one. If there is some planned new feature, I would be happy to help.

Post Reply