Harakiri aka multiwii port to stm32

[mr.sneezy]

Hi All.
An update on my wresting match with the magnetometer on my grafted on GY-86 IMU module. At the end of successful wresting I now have the IMU board facing so the mag chip is oriented same as Naze, and the MPU6050 is now flying 'backwards' to Naze.

The mag turned out to be a PITA to try to reverse in the CLI table, but reversing the Acc/Gyro was not hard to do. The settings FYI are:
align_gyro_x = -1
align_gyro_y = -2
align_gyro_z = -3
align_acc_x = 2
align_acc_y = -1
align_acc_z = 3

I have the Harakiri SG2.3 firmware loaded. The quad flies very well with default SG2.3 PID's. Flown in 15 knots of wind too mind you.

Tried PH and RTL. No response from the Quad in flight, just drifted off till I manually brought it back.
I guess either I've missed a feature or CLI setting, or there were not enough Sat's locked for 3D fix. Not sure which, and I'll try again as soon as I can.
I do accurately get my current map position on the Map GUI tab of BaseFlight-GUI2 though, and GUI shows my TX PH and RTL active when I throw the switches. Any hints welcome...

Edit: Reading back 5 pages I see now that 'BOVI' reported the same thing with his quad and PH. I wonder if it was sorted out, we probably both missed the same magic parameter ?

Regards,
Martin

[Truglodite]

Roger that Rob, I did cut the proper trace. I wired in a 3V compass module I had on hand, and now it works! Fortunately it was not very hard to get 3v3 from my board. I shall revert to SG2.3 (from 2.4), and flight test PH/RTH with my new external compass. If that goes well that maybe... maybe I will very carefully flight test 2.4.

Oh, and thanks again z01z!

I hope everyone doesn't mind me going OT a little here. I need to know if that 5V compass module I bought on ebay was DOA; so I know if I should proceed for a refund or not. I don't have any special equipment other than the usual FTDI and USBasp, and a DMM with frequency measurement. It has an onboard voltage regulator, and the SDA/SCL lines go through a second IC... not sure what that does nor can I identify it. As I mentioned the module does have a DRDY breakout, and that 3V module does not. I powered it's VCC with 4.7V. I did measure a varying frequency of around 26k on the SDA line while it was running. Does that mean anything? Shouldn't I expect it to work like my 3V module did? Do you think it is DOA?

[subaru4wd]

Hey Rob. I am having an awfully hard time flashing new firmware to my flight controller. I keep getting the same error from STMFlashLoader.exe. I am using the BaseFlightGUI to initiate the update, so maybe something is wrong there?

Can you give me a brief run-down on what you do to update your boards?

[Crashpilot1000]

I did a fotostory of the flashprocess: http://fpv-community.de/showthread.php? ... post404293 (don't click on the photos unless you want to become a member of that chinese style censorship site). NOTE: The picture ordering is messed up there (hover with mouse over picture to see the ordernumber), and German "Falsch" means "wrong" and "Richtig" means "right / OK". Meanwhile I upped a new version with a lot of changes here: http://fpv-treff.de/viewtopic.php?f=18& ... 576#p20576 (Scroll a little for summergames 2.4) hopefully that zip packer is now more pc friendly.
There was actually a BUG in PH that prevented holding/finding the spot... it was just trying to do relative PH (one bool variable was not set ).
Normal PH will bail out / not work at the following conditions:
- having less than the spec number of sats (gps_ph_minsat = 6 as default) or satfix. Exception: RTL is possible with 5 Sats or more.
- user oversteers (roll/pitch) additional gps deadband (gps_adddb = 5). It adds up to the normal RC deadband (deadband = 15).
- having no homepos or having uncalibrated mag.
That is all that comes to my mind right now.
Cheers
Rob

[subaru4wd]

Thanks Rob. I ended up finding a RCGroups thread with details on how to use that STM flash program, but I was still getting errors. I had to short the two "BOOT" pins and then the STM flash program identified my board and finally allowed me to update the .hex

I am now on SummerGames 2.3 and having great fun tuning PID's

[Crashpilot1000]

Thanks Rob. I ended up finding a RCGroups thread with details on how to use that STM flash program, but I was still getting errors. I had to short the two "BOOT" pins and then the STM flash program identified my board and finally allowed me to update the .hex

I am now on SummerGames 2.3 and having great fun tuning PID's

Hehe, check out 2.4 a well.
BTW: I never released a hexfile that required that bootpin shortage (though I produced some for myself ) . The main problem is that gui you use.

[bovi]

HI,

Today I loaded latest harakiri code (Source280713-2000Uhr.zip [1008.43 KiB] ) ...
After successful update, the board goes to some mode, with green blinking and I can not connect anymore properly.

In gui, I can see this, going on and on:

$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g$M>ftANGLE;HORIZON;BARO;MAG;CAMSTAB;CAMTRIG;ARM;GPS HOME;GPS HOLD;GPS LOG;PASSTHRU;HEADFREE;BEEPER;HEADADJ;g? 3
?? 4
?? 5
?? 6
?? 7
?? 8
?? 9
?? :
?? ;
?? <
?? =
?? >
?? ?
?? @
?? A
?? B
?? C
?? D
?? E
?? F
?? G
?? H
?? I
?? J
?? K
?? L
?? M
?? N
?? O
?? P
?? Q
?? R
?? S
?? T
?? U
?? V
?? W
?? X
?? Y
?? Z
?? [
?? \
?? ]
?? ^
?? _
?? `
?? a
?? b
?? c
?? d
?? e
?? f
?? g
?? h
?? i
?? j
?? k
?? l
?? m
?? n
?? o
?? p
?? q
?? r
?? s
?? t
?? u
?? v
?? w
?? x
?? y
?? z
?? {
?? |
?? }
?? ~
?? 
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?? ?
?

I tried on 2 boards, same results...
What to do?

Regards, Bovi

[Crashpilot1000]

Ignore that mavlink heartbeat garbage and setup with mwii gui 2.1(auxchannels / calibration). Well I also installed it on 2 Naze without problem.

[bovi]

Ok,

it works with mwc 2.1,
but how can I enter cli mode to configure while "mavlink" is talking?

Thanks, Bovi

[Crashpilot1000]

Harakiri Summergames2
=====================

- Feature telemetry is gone and replaced by "tele_prot = X"
- Some basic Mavlinksupport. It's beta but there are a few things you can do already.
- Autosensing Mavlink/Multiwii protocols (can change every 4 seconds)
- Due to Autosensing you will see the Mavlink "1Hz Heartbeat - garbage" in cli.
- Entering the CLI requires three times "#" now! ("###"). Alternatively 3 times <RETURN>. CLI entering is only possible when disarmed.
- Flashing requires three times "R" now! ("RRR")
- Reworked PH PosrD Controller. PosrD is scaled down now (factor 30)
- Re-enabled crosstrack support. Crosstrack gain can be adjusted or turned off

WhyTF nobody looks in the readme???????????????????????????

[bovi]

Sorry, all my fault. It must be the heat outhere . I am jumping from one to another naze with TC firmware... All Ok. Sorry.

About osd... any video on-board?
And, is there some info (basic abc...) about minim osd with naze and harakiri sw, yet?

Regards, Bovi

[Crashpilot1000]

@Bovi: Well the minimOSD with its' original FW has just seen a benchtest that is described here: viewtopic.php?f=23&t=3524&start=140#p38753
But you can always put that kaventos mwii FW on minimosd. That requires 4 cables of wiring in contrast to the "bechtest".
I would go with the kaventos FW for now but you can also try out the minimosd/mavlink stuff but mind the baudratesetting.

[mr.sneezy]

Sorry, all my fault. It must be the heat outhere . I am jumping from one to another naze with TC firmware... All Ok. Sorry.

Hi Bovi, a week or two back you reported an issue with PH or RTL not working. Did you get success since then ?
I had a similar issue with SG2.3 on first attempt but have been working very long hours and not been able to try again since.
If you had success it would be helpful to know in advance of my next outing, even though the problem is probably something I'm doing incorrectly.
Thanks,
Martin

[Truglodite]

Hi Rob, Brian and I have done some testing on SG2.2 and 2.3, and both of our OSD VSI's were not working properly. Everything else went great, especially PH!!! We're both using modified KVOSD, and haven't changed or updated it in a little over a month; the VSI used to work with Harakiri and Baseflight. Everything else displays properly on the OSD, but the VSI appears to be following my throttle position... not 100% sure but that is what it looked like to me. So I think there may have been a change in your new code that is mixing up the MWii serial stream (too newb to know exactly where). I figure I could get it working on the KVOSD end, but then I also figured you wouldn't intentionally change the serial stream without informing folks. I will look in to it and see if I can find a fix, but you might also want to look in to it yourself... it could take me a year to get that done.

...brief SG2.3 flight report...
PH was awesome with my new external compass. It held <3' easily with a choppy 8mph wind. It did not like to change position while in PH... kept fighting its way back to the initialization point. I think that is to be expected with MWii at this point, but I'm sure I'm not the only one striving for AC3 like position movement. The new PID felt OK, but I still had to fight the elevator to keep it moving when I needed slower speeds in acro (wants to pitch up hard below 5mph). This is similar to older Harakiri releases, but I have not put in the time to tune that behavior out. I will put in an honest effort to that end this week, and follow up with an SG2.3 highlight video for you to enjoy/use for promoting your code (BTW, I know my videos are low Q, but if you want to use any of them to show off your code, they are all yours).

Excellent work Rob!!!!

Kev

[Crashpilot1000]

@ Truglodite: Thanks for your test feedback!!

Well the version you tested could have a PH problem not finding/holding absolute position, that is fixed in 2.4. I will not integrate the moving PH Point with sticks in the arducopter way because it is too dangerous. It puts the user out of control and if the GPS screws up you will most probably wreck the copter. Read in their forums they must earn a fortune with their put-the-user-out-of-control-bugs by selling new parts. So my versions will always be "oversteerable" or turn GPS sh** off if something smells fishy. Even having some kind of deadband between gpsmoving and oversteering is dangerous, because it is most likely to loose gps near ground (multipathing etc)...But the code is opensource and much easier to understand than the bigger copter projects - so feel free to implement it.
VSI means vertical speed indicator, right? Ok, It is not transmitted at all with mwii 2.1 protocol ... thank you for the hint, the comment says: "added since r1172"!!
You can simply transmit it by changing this (serial.c ca. line 300)

Code: Select all

    case MSP_ALTITUDE:
        headSerialReply(4);
        if (feature(FEATURE_PASS))
            serialize32(0);
        else
            serialize32((int32_t)EstAlt);
        break;

to this

Code: Select all

    
    case MSP_ALTITUDE:
        headSerialReply(6);
        if (feature(FEATURE_PASS))
        {
            serialize32(0);
            serialize16(0);
        }
        else
        {
            serialize32((int32_t)EstAlt);
            serialize16((int16_t)vario);
        }
        break;

Cheers
Rob

[subaru4wd]

Hey Rob. You can see the VSI going crazy on my OSD in this video. In the beginning, it doesnt take long for the VSI to go from 0, to 10, to 20... up to 50 feet and then back to 0 again.

I am not one for coding, so I hope this is something you can fix in a future release.

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

[Crashpilot1000]

Thanks for the vid with the hypnotic music!!! I see the altitude is toggling around. That is clearly the sunshine on the sensor (it is worse when the sun shines in from the side). In the end of the video you can see that the hightreport is ok in the treeshadows again. My setup also suffers from sunlight on baro problem. Another thing is the heating up of the baro by surrounding chips and the foam cover. I proofed that and published the results in this thread: http://diydrones.com/profiles/blogs/bar ... 2#comments (look on page 2). That is def. a problem of the small pcb size. Some FC have the baro on the ground - facing - side of the pcb, that seems to be a good idea. I will have to redesign the case of the naze and get rid of that orig. TC case. Interestingly the BMP085 can cope better with the situation thermal wise.
Greets Rob

[subaru4wd]

I am flying a Flip32+ from witespy, the baro is mounted to the underside of the board. The board is mounted to the frame using vibration isolation foam, so the baro is completely covered.

I was not having baro issues like this with SG2.1. Im tempted to go back to SG2.1 to see if the issue goes away.

One thing that strikes me as really odd, is the fact the arrows for the VSI will point down, however the # will continue to rise?? I assume if it were an issue with baro readings, the arrows will follow the numbers as they rise and fall. However, they both have a mind of their own.

[Crashpilot1000]

I will check that but I am clueless at the moment whats causing that issue. I will have to see what I changed in the ms driver from sg2.1 to 2.3. The vertical speed indicator must be a function of the osd soft that is miscalculated on the crazy altitude.

[Truglodite]

Rob, subaru is having the exact same problem I mentioned. Like I said, the VSI works properly with the latest Baseflight, and older Harakiri (pre SG2.2). With SG2.2+, the altitude is displayed properly, and of course alt hold works awesome, but the VSI appears to follow throttle position. Note our OSD's display the altitude just to the right of the VSI arrows (not CR value, just the arrows for that). Will those changes to serial.c you mentioned earlier fix it? I haven't tested yet...

[edit: Actually reviewing my video, the VSI guage is not following throttle position... I have no idea what it might be following.]

[subaru4wd]

I was going to say, Kevin... my VSI did not seem to follow my throttle position at all.

[Crashpilot1000]

@Turglodite: Thank you very much for your info! I have not seen a degrade in althold, and that would be suspected. So I think it's hopefully just a display problem. The variometerdata are currently not transmitted (as far as I see) in the current code so I will have to look at the kventos code as well. Currently I assigned myself to a different task. I am breaking up the whole IMU core of multiwii, transforming everything (sensor/board orientation) to standard NED nomenclature, putting the calculation to rad/sec (Done), accelerations relative to 1G and eliminating Euler angles where possible. I want to separate that acc LPF stuff on gyro/acc to get a good acro and good earthframe accelerations. Currently the mma gives better results than MPU accelerometer. So TC seems to be right putting 2 ACC on his hardware - from my current point of view. I also want to implement some of BRMs work. But the main problem is: I just understand a third (at best) of that stuff. So I will check back to your problem when I am frustrated with my task - and that can't take long.......

[subaru4wd]

I have had one hell of a time trying to get Auto-Level to "level". This has been an ongoing problem since SG2.1. Tried SG2.3 and now I have SG2.4 installed, but no matter what the quad always wants to pitch forward and to the right when I engage Auto-Level. I am doing a ACC calibration on a level surface, but always it wants to pitch foward/right.

I have spent the day doing ACC calibrations on non-level surfaces (positioning the Quad so its pitched Rear/Left) and have gotten it to perform a little better, but this is kind of rediculous. Why is it the "level" surface I use, is not "level" while flying?

[Crashpilot1000]

Well, why don't you trim your copter like every multiwii (stickcommand at the end of TC manual)??? Stay away from feature "INFLIGHT_ACC_CAL" because it doesn't changes the trim(that would be fine) but re calibrates acc in the air

[mr.sneezy]

Hi all and in particular Rob.
I got a chance to fly my quad again last night for a while, and it was fairly calm evening.
I tried AH and PH again on SG2.3 and with all default PIDs. This time it was very solid on both (I must have done something wrong before). I tried AH first and vertical drift seemed minimal, maybe 2 meters (at 15 meters alt). Then I tried PH. Worked great, drift seemed less than 2m maybe even 1m. Altitude seemed more solid too than AH alone. I could set the radio down just leave it hanging in the air.

Normal flight with Horizon and Angle flight modes on the default PIDs seem to be fine for my quad, maybe a little soft but I found nothing nasty going on when doing slow or fast flight.

All up the performance is now much better with the new sensor set, so the move to the GY-86 module seems to have paid off (if it's flies this well all the time).

Rob, given that I fly in wind quite often, what are the PID or CLI parameters to change to get it to PH and RTH into the wind harder ?
(just looking for help on the parameter names, not the actual values of course)

Thanks,
Martin

[subaru4wd]

Well, why don't you trim your copter like every multiwii (stickcommand at the end of TC manual)??? Stay away from feature "INFLIGHT_ACC_CAL" because it doesn't changes the trim(that would be fine) but re calibrates acc in the air

I would have assumed that a ACC Calibration performed on a level surface would record the level surface. Since it does not, i assumed there is a problem.

I will try the ACC Trim feature and hope for the best. I just found Revision 2 of the Naze32 manual. This entire time I was reading Revision 1, which is poorly written and did not have the stick functions.

[subaru4wd]

Okay, the ACC Trim stick command tells me to Throttle UP (full throttle) and use stick #2 to adjust the ACC.

So I hovered, verified the quad drifts to the right... so I land, disarm, throttle to full and push the right stick to the Left. Then Arm and try again, and still it drifts to the Right. I did this several times, but still it drifts to the right... so either im doing something wrong (how hard can it be to move sticks???) or shit isn't working the way its documented (no fucking suprise there!)

Oh well, im just going to go back to calibrating on an unlevel surface until I get it spot on.

[subaru4wd]

Got to take the quad out yesterday for a few good flights. Its always a good day when everything comes home in one piece.

With SG2.4 I noticed much better VSI. Its still not "rock-solid" but at least it no longer jumps from 20 to 50 to 70 and back like before.

I tried return to home and the quad did not come anywhere near home. Also, my auto-level kept on forgetting where "level" was (hope thats cause of my horrible vibration issue). So I just gave up and put it in Acro to see how long I could fly on a fully charged 5000mah 3s.

Video:
http://www.youtube.com/watch?v=doc2N2Y4_nY

[Truglodite]

Rob good to hear you are digging in to the more critical parts of the code; no worries on the VSI, I obviously need to do some studies on that subject. I will do my part and see if I can get it fixed on the OSD. While you're working hard standardizing the internals of the code, I figured you might enjoy having some videos to watch during your breaks. Here are highlights from a month of working with Harakiri, including a good long PH in 6-8mph variable winds (starting @9:30):



Unfortunately I ran out of time and energy to setup for an RTH test, but I did manage to accidentally takeoff in PH mode. Not realizing it was in PH, I flew the crap out of it... LOL. Went over 30mph and scraped the ground with it. PH didn't seem to exhibit any of the usual bad habits for about 3min of my typical piloting, other than feeling like stab mode not acro, which is what prompted me to pause and look at my OSD flight mode to realize I left the PH switch on (just finished flying my glider that uses that switch for butterfly mode). So that bodes well for your method of giving pilot inputs priority over GPS/compass/baro... I like that A LOT! The video shows PH still does it's job when I'm taking a nap at the wheel. The fast PH footage is not included in this video since it happened in August... for the next video.

Subaru, man, sounds like you are having a heck of a time with those ACC calibrations! I haven't had any problems putting my frame on my level countertop and giving it the ACC cal stick command. I know you're not new to this stuff so you probably already have the usual items covered. Is it possible there is some TX mix that was accidentally turned on or something weird like that? Good to hear the VSI is improving, but I'm curious why with no changes made on that end.

Cheers,
Kev

[Crashpilot1000]

@Subaru@Truglodite : Thank you very much for your feedback and the videos! I checked the Acc stick trim stuff with SG2.4 and it works. The 2.4 seems to be more affected by vibration somehow because I changed the sensor calculation for earth gravity. I wonder why but it seems like. Maybe you have to reduce accz_vel_cf (default= 0.985 ) a little perhaps 0.980 or 0.975? That will also affect the final altitude calculation so that it relies more on baro. But there is also a factor to finetune that. "accz_alt_cf" (Default 0.940) that can be reduced as well. But "accz_vel_cf" is more important for althold. I changed the acc1G stuff because this mwii bitshiftstuff and different sensors with different calibrations are a mess. If you change anything in the code you will be knocked out by some other part. So the internal procedure for acc calibration is now like this:
- Put copter flat (that is not necessary for gravity but for "level" calibration)
- press acc calib. Now the acc sensor offsets are gathered and it's completely irrelevant what "scaling"/numbers it reports. Because after that the total vectorlength is calculated and that must represent earth gravity of 9.81 m/(s*s) because that is all we measure on earth with a non moving 3 axis acc - no matter in what position it is relative to earth. So the offsets for that sensor and the number it will report at 1G are stored in eeprom (that is with mpu 6050 normally 512 on accz in the gui, like in the datasheet scaled with the multiwii shi(f)t. But you might see some other value here now like 508 or so. That is based on 1000 readings of the acc at your roomtemperature and gravity)
- Now you have to repower the fc so the "new" acc1G is taken into account (SG2.4 doesn't reset itself after calibration)
So that's what has changed internally. I think it's a progress because the code will "eat" any acc at any scaling when calibration is done but the lowpassfilters and ins factors might need some tuning. So my next step is to put all readings to unified units rad/s and "G" (that is done in testcode and the mwii IMU isn't working anymore - like expected).

[subaru4wd]

So I was laying in bed thinking about this stupid ACC Trim feature, and why wouldn't it work for me??

Then I realize I was trying with my Transmitter in Rate mode, at 60% rates for AIL/ELE... D'OH!

[Crashpilot1000]

@Subaru: Oh, that error was hard to find in the code . Thank you for your feedback! Still biting my teeth with the imu sh** and fiddeling around with sensors. Perhaps I should stop that.

[subaru4wd]

@Subaru: Oh, that error was hard to find in the code . Thank you for your feedback! Still biting my teeth with the imu sh** and fiddeling around with sensors. Perhaps I should stop that.

Keep up the good work Rob. I did verify last night that the ACC Trim stick function does indeed work But it doesn't if rates are at 60%. Silly me

[alu]

Hi,
I am very interested in running/modifying Harakiri and I have a question regarding the different versions of the Naze board:
Does it matter which revision I have?
What about revision5? Is it supported, yet (+SPI flash?)

[Crashpilot1000]

@alu: Thank you very much for your information. I didn't know that and just heard rumors. From recent Openpilot/Taulabs activities of certain people I guess it will be basically a clone of that hardware with slight modifications. Well I am quiet happy with the current hardware and see no reason to hop on that train. I think there is a lot of unused potential in the current hardware. Only the eeprom space will become an issue. It might be reasonable to ditch some drivers for outdated or mostly unused stuff like: (< Kill priority >)
drv_ledring.c (<HIGH>)
drv_l3g4200d.c (<MED>)
drv_mma845x.c (<HIGH> But maybe useful in combination??)
drv_mpu3050.c (<MED>)
drv_adxl345.c (<MED>)
inflightcalibration in its' current mwii-state. (<HIGH>)
removing that fy90q stuff just for cleaning up - will not save bytes.

Ditching unused stuff makes it easier to focus development.

Cheers
Rob

[Crashpilot1000]

Hi, short info: Uploded new version with improved acc/gyro calibration and usage for MPU6050. Of course handle with care. I see a more accurate flying, and better althold. I also uploded it on github but somehow the obj folder with the hex didn't make it.
Direct link to the file: http://fpv-treff.de/download/file.php?id=6257

Altered/Improved mwii core parts. Hex included. Both Pid controllers tested, Althold tested, PH tested. Not tested: Sonar (unchanged code), RTL (unchanged code). The rest of the code is unchanged. The improved core leads more precise action. During acc calibration you will see the gui going bersek displaying values that tilt out at 1000 with original gui - that is normal due to the better calibration. After calibration the naze will reset itself and everything will be back to normal. Accz is normalized to 512 for the sake of mwii...
feature ppm is preset in that hexfile.
Here the changelog:
Naze32 Harakiri10 Summer Games2.5
=================================
- Experimental IMU Changes. Better MPU Gyro usage. All acc scaled to "512" for 1G
- Precision improved ACC/Gyro calibration.
- MPU6050 "single shot" readout like suggested by Sebbi
- Changed MPU Acc setting from 8G to 4G, increasing resolution without observing saturation effect (right now...).
- Experimental IMU Change for GPS
- gyro_cmpf_factor changed to 1000 (from 400)
- Added vario data transmission within MSP_ALTITUDE

Check out the readme as well in the zip. (https://github.com/Crashpilot1000/Summe ... kiriREADME)

Cheers
Kraut Rob

P.s.: The variometerdata are transferred as well in cm/s. Hopefully the unit is right for KV OSD and it doesn't need m/s...... didn't check that (no osd currently attached) and it comes to my mind at this very moment.... damn....

[IceWind]

I was checking on the code and can't find it, can you confirm if the CAMTRIG feature is present or not?
In the Multiwii I used it for a buzzer. I know the Naze32 has dedicated pins for it but the one I have has a servo plug so it's
much more simple to plug it to a motor pin output for example.

[Crashpilot1000]

Thanks for the info! Camtrig has only a dead end variable in the code (even in actual original TC trunk). So yes, there is NO CODE behind camtrig. Perhaps using the buzzer connectors on naze will help you? I have no buzzer attached so I can't help you on that.

[IceWind]

Not quite the buzzer I have must be connected to a PWM signal to work and I was trying to avoid taking it apart.
I'll figure something out.

[subaru4wd]

Hey Rob. I am reading alot about the "Horizon mode bug" in MW2.2
viewtopic.php?f=17&t=3806
Im curious if Harakiri suffers from the same "bug".

thanks.

[Crashpilot1000]

I guess not, but I don't fly horizon. You will have to check for yourself. Gyroscales are correct within the normal mwii madness.

[jksuperstar12]

Not quite the buzzer I have must be connected to a PWM signal to work and I was trying to avoid taking it apart.
I'll figure something out.

I have a similar Buzzer (the "Discovery" buzzer). If you can short the signal pin to the + pin of the buzzer, you can just plug it into the Naze's buzzer port, making sure the -/GND side of the 3 pin connector is aligned correctly (so the "signal" port of the servo connector is not actually plugged in, but will be enabled since it is shorted to +). One the Naze schematic, the + is like a combined V+ and Signal, so it works as it should.

I peeled up the shrink wrap on my buzzer, and just added extra solder to short the two pins on the buzzers board.

[Crashpilot1000]

BUG NOTICE SUMMERGAMES 2.5:
SONAR ON PWM56 IS NOT INITIALIZED . It is fixed now but also reworked the sonar part a little and still do not know exactly why it was not initialized. Will release the repaired version when that questionmark over my head is gone.
Cheers
Kraut Rob

[subaru4wd]

Hey Rob. With standard MultiWii boards we're able to send RSSI from our receiver for OSD, etc. Is there any way we can achieve this in Harakiri as well?

[Crashpilot1000]

Well, the problem is to get the RSSI into the Naze. The outputting protocol is not the problem. Reading out the Frsky PWM RSSI could be possible. Perhaps it's a better way to feed RSSI directly into the OSD (like I did with minimosd in my apm days). The naze is still a "funfly" with limited pins and eeprom.

[subaru4wd]

Yes I agree, the best way is to directly feed it to the OSD board. Keeping it simple. I was just curious before I soldered to my minimOSD)

[Crashpilot1000]

Short notice: SonarBug fixed: http://fpv-treff.de/viewtopic.php?f=18& ... 967#p43967
You will only need that hex, if you have a Sonar on pwm56.

Short notice on horizon mode: It is tested by "Hydroculture" here http://fpv-treff.de/viewtopic.php?f=18& ... 000#p43934 and reported back to work like a charm. Test was done with the default PID controller on summergames 2.5.

Cheers
Rob

[jhoexp]

Hello fellow harakirians!
I have been testing summer games 2.5 for quite a while, and everything is working good....except gps hold. It's almost there, but still start "toilet bowling" after a few seconds of good holding. That suggest me maybe there is someting magetometer relater.

My test platform is a very large quad with reverse mounted 17" props, not quite the average multirotor,but usually very friendly with any controller. This time seems I can't find a way to make this thing hold decently.

How is your position hold? any suggestion to improve or to track down what is this behavior related to?
Thanks!

[z01z]

Rob,

Is everything OK with accel calibration? I've two boards with the SonarBux fix fw, and they behave the same. The Z axis shows 511 but on the X or Y the max value I get is ~43x. Is this how it should work?

In the BaseFlight GUI (2.3.2.0) the accelerometer graph shows the change but the numbers doesn't follow, for negative pitch and roll (only 1/10th of the value is shown).
I've also noticed that sometimes the GUI prints the mag calibration performed text just after the OK button is pressed on the pop-up describing the procedure, while the board is still doing the calibration.

Zoltan

[Crashpilot1000]

@jhoexp: Thank you very much for your feedback.
Well basically a circeling is a faulty working PID controller in the 2 dimensional space. In the case of the GPS it is most likely the Magnetometer. You can test your Mag by throttling up your quad and watch if the compass "needle" moves. In case of your monsterquad it seems very dangerous. You can also try to tune your pids down. I also included a "position bathtub" around the current position, so that the walk of the GPS should have less authority in that defined radius (gps_ph_abstub = 100 cm = 2m diameter). So it will give a non linear response in that area like shown here http://fpv-treff.de/download/file.php?id=5782&mode=view. You can increase the value or turn that off with gps_ph_abstub = 0. Maybe thats something to try out.

@z01z: I have not seen this with mpu6050. I don't know what the closed source gui does.

Cheers
Rob