Harakiri aka multiwii port to stm32

Crashpilot1000 · Post by **Crashpilot1000** » Mon Jun 17, 2013 6:06 pm

Thats strange. If your mtk3329 wasn't branded by Globaltop, the flash would not have been possible if i am informed right.
Your MTK should show a sign of life in nmea and 38400 Baud. If not flash back to the original FW.

mr.sneezy · Post by **mr.sneezy** » Tue Jun 18, 2013 8:00 am

Crashpilot1000 wrote:Thats strange. If your mtk3329 wasn't branded by Globaltop, the flash would not have been possible if i am informed right.
Your MTK should show a sign of life in nmea and 38400 Baud. If not flash back to the original FW.

Hi Rob. There is nothing indicating Globaltop on my module, it was bought from Spark Fun in the USA a couple of years ago. The other one I have here belonging to a friend is from Hobbyking, it's unbranded AFAIK, so probably not from Globaltop either.

Is Globaltop a chipset builder that other makers use, or is it an module end supplier ?

I had no idea from the info I found on forums that only Globaltop units could run the 3Drobotics firmware.
Bugger...

mr.sneezy · Post by **mr.sneezy** » Tue Jun 18, 2013 9:50 am

More on GPS...
Reverted both MTK 3329's to a FW that reports being AXN_1.50 0320 in the MTK miniGPS app.
Both now work fine in NMEA mode on Harakiri. So looks like they just won't run the firmware I wanted to use.

One thing of note.
Both units came out of the firmware reflash at 38400baud (as seen on miniGPS), but after I tried to use both on the FC board using gps_type = 2 (and 3 I think) the GPS modules both then ran at 57600baud. I found this via miniGPS, when neither would go with NMEA gps_type = 0 & gps_baud = 38400 after trying binary mode.
So this shows that Harakiri and the FC are resetting the GPS baud rate when attempting to set binary mode on them.
Not a great problem, as long as you know this...

PS. I did try using RealTerm to shift both into Binary before I did the above down grade reflash. Tried sending $PGCMD,16,0,0,0,0,0*6A, got $PGACK,16,1*68 in return, then back to endless $PGACK,003,-1*71. I note that somebody called LegendLength on DIYDRONES.COM got the same thing.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Jun 18, 2013 10:47 am

Yes that 57k stuff is part of my Mtk Autoconfiguration.

mr.sneezy · Post by **mr.sneezy** » Tue Jun 18, 2013 11:43 am

Crashpilot1000 wrote:Yes that 57k stuff is part of my Mtk Autoconfiguration.

Ah I see. I've just set my board to 57600 and left it at that. Now that I KNOW the MTK won't run in binary mode I'll fix the dead battery on my uBlox and move on...

Crashpilot1000 · Post by **Crashpilot1000** » Tue Jun 18, 2013 2:11 pm

Hi, mr.sneezy!

I see you are located in Australia. I read in the diydrones forum that SBAS in Australia can be disturbed by Japanese SBAS Sats. So you could have problems with that. I don't know how intelligent ublox is, but mtk seems to be affected. Per default i enable that stuff, so if you find big displacements it might be advisable to set up your own ublox config with ucenter. Set pedestrian mode etc perhaps this is helping you http://www.multi-rotor.co.uk/index.php?topic=1177.0 . gps_type = 4 will use your own ublox config.

Cheers Kraut Rob

EDIT:
I don't know what ublox model you have nor i am not familiar with all their products but you should go for an ublox 6 with eeprom. The battery stores just the sats, so it starts faster but the eeprom stores the configuration. So even with a dead battery the ublox will work but will need much longer to get the first fix after powerup.

EDIT: EDIT:

This here is also a great tutorial:
http://code.google.com/p/ardupirates/wi ... PSTutorial
I do not agree in all points to it (like the cheesy 38K Baud, i also believed in [arduino can better cope with that when loaded with other stuff], also gps altitude is completely irrelevant, everybody with 2 braincells will use barometer for this, since current gps has +-10m jumps no matter in what mode) but basically it's very good to see how to use ucenter. It's very easy once you get the idea.

EDIT: EDIT: EDIT:
You aked something about mtk and globaltop branding. Yes, the 1.6 and 1.9 FW are branded by Globaltop. I think EosBandi reported once, that some Hobbyking have a different Companyname in their FW so the updater will tell you: No Go, when trying to flash a globaltop branded FW. I don't think that there are "washed" versions of 1.9 around somewhere. Even if somebody could crack that fw or the updater to make it universal, it won't be worth the effort. Wasting time on watching your toes move is more productive than that.

felixrising · Post by **felixrising** » Wed Jun 19, 2013 5:21 am

Hi Rob!

That's some very interesting information regarding Japanese SBAS Sats possibly disturbing Australia SBAS... I also live in Australia. I've been having trouble with number of satellites picked up. Is this a likely symptom of SBAS disturbance? Generally I find I only get half of the sats my phone can pickup (6-7 vs 11-13). I'm on a 2.4GHz RC and 5.8GHz A/V.

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jun 19, 2013 5:39 am

No, the number of sats in view is not affected by that. What i gathered from that diydrones froum (damn, where is that link) they are not jamming in any way but mtk would also accept them for navigation in parts of Australia that are covered by them. I am pretty shure it was an MTK only issue, if my memory doesn't fail me.
When your satcount is always low, it's probably disturbance from your flightcontrol or noise on the power/datalines.

EDIT: Look here: http://www.diydrones.com/forum/topics/a ... %3A1203198
and above that post, really interesting!

felixrising · Post by **felixrising** » Wed Jun 19, 2013 6:06 am

Thanks! I thought I had some noisy power/FC thing going on, I can cause my phone sat count to drop just by placing the phone next to the FC (motors disarmed). It's a bit annoying, I know I can can get a nice high sat count with the same ESC BEC (BS 12A) but Crius AIO Pro FC with similar spacing. I probably need to put in a ground plane to reduce noise.

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jun 19, 2013 6:20 am

Yes, a Groundplate for a GPS on a Copter is a MUST HAVE. You might buy something special or build it on your own with aluminium foil/plate or copper. I think the stm is a real disturbing pig in this regard compared to slow arduino.
Here you might find some inspiration:
http://diydrones.com/forum/topics/arduc ... t%3A868946
http://autoquad.org/wiki/wiki/autoquad- ... oundplane/
http://autoquad.org/software-downloads/?did=1
http://diydrones.com/forum/topics/how-to-gps-shield

If you have no skills you will end up with a working setup that might look like mine: http://fpv-treff.de/download/file.php?id=5262&mode=view

Cheers
Rob

felixrising · Post by **felixrising** » Wed Jun 19, 2013 6:49 am

Thanks for the tips Rob! I'll get my ghetto ground plane assembled tonight. More and more my RC hobby is turning into Arts and Crafts

BTW, would it be a better default to not write changes to GPS automatically? i.e. why write changes to a GPS that is potentially pre-configured and overwrite those changes.. it seems that if a GPS needs automatic config changes the user should explicitly define this to happen... yes, I'm being lazy. But I'm sure I will overlook this each time and need to manually reconfigure the GPS to disable SBAS after every firmware flash... :j

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jun 19, 2013 7:09 am

Well i see no problem there. You can choose two options on "harakiri" for ublox. gps_type = 1 Puts in the predefined "multiwii block" currently i am about to change it a little to take advantage of ublox concerning my ins part. That predefined "block" will be forgotten by ublox because it is not stored in its' eeprom it's just for the session. On the other hand you can put in your own config with ucenter and store it "permanently" in you ublox eeprom. In that case use gps_type = 4. So my code will not try to configure ublox on it's own. It just takes the data. Be sure to select coressponding baudrates concerning your own ublox config and naze. I would recomment 115K. So: "set gps_baudrate = 115200" (that is default anyway).
To sum it up. You can be lazy as hell but once you got a good ublox configuration figured out for your place, you can flash naze FW without loosing that.
Cheers
Rob

mr.sneezy · Post by **mr.sneezy** » Wed Jun 19, 2013 1:46 pm

Hi Rob and felixrising.
Rob I have a Hobbyking uBlox NEO-6M, and it has an EEPROM. Tonight I 'fixed' the charge limiting resistor for the super cap used as backup power. Fitted a 100ohm in place of the original 1kohm. The XH141H datasheets shows 100ohm is OK, perhaps less too. It now charges up much faster, maybe 30 minutes or so to 3.3V. The cell is supposed to be 70,000uF, which gives about 0.015mA capacity. The NEO-6M datasheet shows the backup input uses 22uA. That's 28 discharge days if my math is right, giving an actual useful voltage for perhaps half of that. Much more than the 15-30 minutes I have been getting before a GPS hot start fails...

That SBAS is interesting info, I'll read it all over a coffee tomorrow morning. It might be why it takes ages for initial GPS lock here. However my car GPS and my Samsung phone have no trouble.
Could this SBAS Disable be controlled with a setting in the CLI ?

When I first got the uBlox and the MTK I tested both for interference. I noted that the biggest GPS issue on my Quad was the RF power from the FrSky telemetry transmissions from the 'receiver' antennas. I had to move the GPS out onto one arm of the quad to reduce that. u-center was choice for that sort of testing. I had the GPS connected via a USB-TTL cable so I could shut down the FC and RX.

I've ordered the so called 10DOF sensor board from Ebay. When I get it the FC will be modified so I can run that board remoted from the MCU and PSU. I think like DJI do. The sensor board can then be in it's own soft mounted box if need be.

Regards the ground planes. Could the effect of adding a ground plane be actually more about creating an RF shield from the FC and RX's emissions below it ?
The reason I wonder is because a patch antenna has a ground plane on the bottom of the substrate by design (or so I thought), so adding another at a rubbery distance below that seems odd.
Might have to do this testing myself. Could use my phone perhaps, it has a GPS module too.

mr.sneezy · Post by **mr.sneezy** » Wed Jun 19, 2013 1:59 pm

I see that BaseFlightGUI has been updated again in the last day, Carsten has been busy.
A couple of questions and feedback to Carsten.

In the two pictures attached.
One shows the Realtime Data tab, and in it I circled the sensor detection indicators.
On my PC they have never gone Green like in MultiWiiGUI or other GUI's, they stay a darker shade of grey like you can see. Are they supposed to be Green if the FC reports a detected sensor ?

In the other picture of the PassGPS.
The text field for FIX is half cut off, so I can't see all the text report. Also GPS rate seems to stay 0 hz.
Not sure if you have actually fully coded all that stuff, if not then ignore the feedback.

Thanks,
martin
PS. Tool tips still don't work for me either, in German or English

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jun 19, 2013 5:34 pm

Hi, i am using 2 Alu - groundplates. One to shield my onboard mag and one to shield the GPS. Well the GPS signal is weak and easily disturbed by anything, the russian GLONASS system is better. Navilock NL-662ETTL can do both GPS and GLONASS, I think it will replace our current Lea 6 shit very soon.
Yes, i was tired of plugging around my gps for ucenter so i programmed a little passgps function for cli. The last Hex has that but currently i improved that with an cli menue that will be in the next source/hexfile. So you can update your ublox with ucenter without an extra ftdi or unplugging your GPS.
If you just want to see some Info you can also use Carstens gui for that.

cGiesen · Post by **cGiesen** » Wed Jun 19, 2013 9:47 pm

@ mr.sneezy
You are right the Hz is not coded. I forgot it (
Here is an actual screen.
Here you can the result with running Naze32

Here you can see the same without the Naze32

cGiesen · Post by **cGiesen** » Wed Jun 19, 2013 9:48 pm

@ mr.sneezy
You are right the Hz is not coded. I forgot it (
Here is an actual screen.
Here you can the result with running Naze32

Here you can see the same without the Naze32

mr.sneezy · Post by **mr.sneezy** » Thu Jun 20, 2013 1:53 pm

cGiesen wrote:@ mr.sneezy
You are right the Hz is not coded. I forgot it (
Here is an actual screen.
Here you can the result with running Naze32

Here you can see the same without the Naze32

Hi Carsten, I see you also have trouble with generating a double copy post

Something to do with how slow the forum updates at certain times of the day I think.

Hey I don't follow what you mean by 'with' and 'without' Naze32 in the post with images above. Could you re-phase that info (sorry if I'm just dumb).
Martin

Edit: I think I just got it. You mean the top one has power to the Naze32 board, and the bottom is with no board power (direct to GPS), showing the desensitisation from it ?

mr.sneezy · Post by **mr.sneezy** » Sat Jun 22, 2013 7:12 am

Hi Carsten,

Can you tell us in a few words how the passGPS tab in the app is used?

I tried the latest version today. I see lots of new data value labels, but not much real data, just sat count and lat/lon I think. No signal bars yet or other data like your screen images.

Regards,
Martin

cGiesen · Post by **cGiesen** » Sat Jun 22, 2013 8:30 am

PassGPS is, liek the name say, an one to one connection to GPS. The same, like using FTDI or GPS direct to GPS.

My GUI only support UBlox!!!

As you see in the header of the groupeboxes there a 4 message types from GPS I show:
NAV_POSLLH
here you get, if you have an fix, the position data

NAV_SOL
some statistics, like number of sats and fix status. Have a look in the datasheet for more info

NAV_VELNED
some info about speed in the different directions

NAV_SVINFO
signal strange

When you do not see data in every group, then there a no data!
The new HARAKIRI give you an small menu to enter PASSSGPS.
Perhaps that helps

By the way. For 'normal' users, the information are not important. Only Signal Strengh.
The other data is for developer to have raw informations.
I found no way, to have the same with U-Center...

felixrising · Post by **felixrising** » Sun Jun 23, 2013 3:13 pm

Hi Rob,

I've finally added a sonar to one of my small quads, playing around with it is fun, holds nicely, I tuned the sonar into the hold equation much more with a snr_cf of 0.90... flying inside, it's cool watching it step up onto the couch, down to the floor, up onto a table, etc.. one thing I got a surprise with though was there didn't seem to be any altitude adjustment with throttle. I could actually reduce throttle to almost zero with no loss of height. Is this something I need to tune through a set parameter? This took me by surprise after playing with multiwii that lets you adjust height by moving throttle out of a deadband.. (I could be thinking of NHAdrian's advanced features code - which has PID controlled vario speed during altitude adjustment).

I tried out the experimental PID loop with pidcontroller = 3.. it seemed different to the baseflight implementation that TC did using alex.k's PID redesign.. especially it seemed that level P value influences stick sensitivity, and also the scaling on some of the PID values seems different to TCs and those posted in the PID/wrong/right thread by alex.k.

btw.. did you end up getting the i2c based sonar driver working/ported from mw 2.2+?

Anyway, keep up the good work!

Crashpilot1000 · Post by **Crashpilot1000** » Sun Jun 23, 2013 5:09 pm

@Felix: Thanks for checking that out! Actually that sonarstuff works. I think the approach might differ because it's completely self developed. But it's opensource feel free to implement other solutions/controllers etc. The big advantage is, that it will not do jumps over trees etc I don't know what other sonarcodes do (rabbit, mwii, arducopter etc). It looks for a "first contact" szenario and generates an offset to barohight. Once a solid sonar contact is established, it will take sonarchanges into account. When sonarcontact is lost, the current baroalt is taken again. Example: You fly over a tree at 25m hight, the sonar might signalize a steady contact and will keep steady over that tree (no "jump"). "Leavin the tree" is also no problem, it is switched back to barohight. Even with your higher cf factor of 0.9 it's no problem to change the hight. Perhaps the variobrake ("alt I" parameter is abused for that) is too high for your setup? Maybe you also triggered Autoland? Dunno. Sonar is done. I didn't spent time looking at I2C sonar right now, mainly because i don't have one. There are also maxbotix i2c variants available. But stressing I2C is not the best idea, you might need a LLC to convert 5V levels to 3,3V I2C levels - otherwise you risk, killing off your FC. Don't know what I2C levels those sonars work on.
Well the main pid controllers differ so don't expect to exchange pids between mwii/bf/harakiri.
Currently i am really ANGRY WITH THE WEATHER here.....
Cheers
Kraut Rob

felixrising · Post by **felixrising** » Mon Jun 24, 2013 8:13 am

@CP1000, I'll check the I value and report how that goes... honestly, I did almost no PID changes

I shouldn't be so lazy!

I would say move to Australia where the weather is great, and normally it is, except right now it's winter and it's coldest average temps in 20 years.. still, here's a pic from yesterday.. I think I found a new place to fly around here

: new spot for FPV/flying

NB: ignore the weirdos in cycling gear..

mr.sneezy · Post by **mr.sneezy** » Mon Jun 24, 2013 2:23 pm

felixrising wrote:I would say move to Australia where the weather is great, and normally it is, except right now it's winter and it's coldest average temps in 20 years.. still, here's a pic from yesterday.. I think I found a new place to fly around here
NB: ignore the weirdos in cycling gear..

That looks a bit like city of Adelaide in the background, but too sunny for the weather we had for the last few days...

mr.sneezy · Post by **mr.sneezy** » Mon Jun 24, 2013 2:34 pm

cGiesen wrote:PassGPS is, liek the name say, an one to one connection to GPS. The same, like using FTDI or GPS direct to GPS.

My GUI only support UBlox!!!

When you do not see data in every group, then there a no data!
The new HARAKIRI give you an small menu to enter PASSSGPS.
Perhaps that helps

By the way. For 'normal' users, the information are not important. Only Signal Strengh.
The other data is for developer to have raw informations.
I found no way, to have the same with U-Center...

Hmm.
OK, so I need to update Harakiri again to be able to use this new screen properly then yes ?

I am still running Harakiri10Beta4. If that's no good then which version is correct to use passGPS ?
I don't think of myself as an ordinary used BTW, I tend to be able to discover all the bugs somehow.

I do have a uBlox NEO-6M fitted at the moment (fixed the battery issue I hope, a Super Cap actually).
This below is what I see when the uBlox GPS has a lock.

Regards,
Martin

cGiesen · Post by **cGiesen** » Mon Jun 24, 2013 2:59 pm

I think, 10beta4 is to old.
Try to use the version from last evening.
It#s really a good version. For me it works fine

Gaijin · Post by **Gaijin** » Thu Jun 27, 2013 1:01 pm

Just updated to the last harakiri, excellent work, the new pid routines are really precise and at last my sonar actually works.
One small fly on the ointment though, whenever I engage the magnetometer the copter starts to yaw (left for example) if I apply corrective input then it starts to rotate in the other direction.

I've calibrated both with and without the motors rotating to allow for local offset but no difference, which term should I adjust to compensate?

I assume GPS functions won't work correctly without a functional mag, harakiri 10b was fine in this regard and rock solid

Crashpilot1000 · Post by **Crashpilot1000** » Thu Jun 27, 2013 3:21 pm

Hi!

@Felix: Well, your winter is better than our summer...

@Gaijin: Thank you very much for your reply! Actually the Mag part is changed. The Magnetometer is read out at about 70Hz now (was 10Hz before). So with the same complement factor (between mag and gyro) the mag becomes more weight in the equation and distrurbances as well. So you will see mag problems much fast now than before.... I didn't make that parameter accessible in cli yet (will come). So you are currently not able to change that. A crisp and correct response of the magnetometer is very important for the acc/gps part, otherwise you will see endless circeling - and that is not a special feature....

.

Cheers
Kraut Rob

EDIT: BTW: The German forum has rearranged itself so the "Harakiri thread" has moved here: http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20576

Crashpilot1000 · Post by **Crashpilot1000** » Fri Jun 28, 2013 10:46 pm

Hi, short notice: I had the chance (while not raining) to give the MTK a spin (using binary mode 1.9). OMG was that awful. I hadn't had the chance to do tuning but it's nogo with my current parameterset for gps/acc stuff with MTK. There seems to be a "benefit" of using my alternative speed calculation model (set gps_ins_mdl = 2 // "1" is default - best for ublox right now) but my testing period was to brief to make any more concise statement. So you may keep away from MTK with "harakiri" or expect a serious parameter job. One small but very annoying bug found. It's stupid of course (intelligent bugs are rare).
When trying to set "alt_hold_throttle_neutral" to a different value than the predefined "50" to a greater value it will be a nogo. Because i defined the range up to 20 for the cli. So you will be stuck with 20 and can not even get back the predefined 50 once you saved the values. Only reflashing the hex will solve that. Sorry for that, will be fixed in next hexfile.
For the "self compilers" just find that line in cli.c:
{ "alt_hold_throttle_neutral", VAR_UINT8, &cfg.alt_hold_throttle_neutral, 1, 20, 1 },
and replace it (for example) with that
{ "alt_hold_throttle_neutral", VAR_UINT8, &cfg.alt_hold_throttle_neutral, 1, 100, 1 },
That will increase your range to a possible value of "100".

Cheers
Kraut Rob

mr.sneezy · Post by **mr.sneezy** » Sun Jun 30, 2013 11:05 am

Crashpilot1000 wrote:Hi, short notice: I had the chance (while not raining) to give the MTK a spin (using binary mode 1.9).

LOL. Another nail in my MTK's silicon coffin

Truglodite · Post by **Truglodite** » Sat Jul 06, 2013 9:49 pm

Hi all, I test flew the latest Harakiri last night and had a great time. It was my first time out with Harakiri, and with default PIDs. So alt hold stayed locked well, but would not move with throttle (ie no vario control... probably some parameter I missed). GPS hold wandered all over the place with 8sats & a uBlox. Acro and stab felt more smoother/more predictable for FPV than Baseflight, yet still very flippable... probably the difference in looptime and gains? All pretty much expected for maiden, but think I ran in to a problem with KV-OSD that may require compiling to fix.

I was running the latest Baseflight on my quad with KV-OSD, and everything worked fine. I loaded up Harakiri and ever since my OSD is stuck on "DISARMED". All the other data is working fine (GPS coords, 3dfix, alt, voltage...), but all data that requires an ARMED state won't work (speed, home arrow, timer, ... kind of important stuff). When I was setting up Baseflight I had to turn off BOXNAMES for the flight modes to display right. I tried with/without boxnames and it didn't help with Harakiri. I spent a couple hours googling the problem, and found references from TC that baseflight sends the ARMED state with "new MW serial 32". KV-OSD was apparently rewritten to work with the new MW serial, and like I said it worked fine with baseflight (I assume it communicated via MWS-32). Was this changed in Harakiri, and if so, exactly where is the ARMED state... 16, 128, ...?

I'm still wet behind the ears with MWii, so I may just be barking up the wrong tree. Regardless, any clues what I should do to get ARMED through to my OSD with Harakiri will be greatly appreciated. FWIW, I have the toolchain setup and working well with repos, but I am having some problems compiling the latest Harakiri source. I did manage to compile the slashphoto's repo, but I don't think that's current. Since I can't import the latest Harakiri from SVN (like baseflight), I copied the baseflight project, and pasted in the Harakiri code... probably not right because it doesn't compile. Any hints or links to reading on this subject would also be very helpful.

Thanks,
Kevin

Crashpilot1000 · Post by **Crashpilot1000** » Sun Jul 07, 2013 9:29 am

Hi, Truglodite!

Thank you for your feedback! The Althold waits for you to reach stickcenter before it will accept hightchanges. Putting the throttlestick in the lowest position will do an autoland (in Baromode). If you can't wait for the copter to disarm you will have to get out of Baromode to disarm. There are also many parameters you can play with. Look in config.c for detailed description of every parameter. The GPS stuff is very magnetometer dependend. There are also a lot of parameters that can be tuned. Maybe you check out my latest version from today as well. The Github and Googlecodestuff is way outdated. Go for the latest zip it has the complete file structure.
KV OSD: You have to re-activate "#define USE_BOXNAMES" in config.h of your osd FW.
Currently i am working on a naze - mavlink port for minimosd. It is currently in it's early stages but working. That code is not included in the latest zip, because my mavlink implementation is pre alpha

.

EDIT: Here is the link to "Harakiri Summergames": http://fpv-treff.de/download/file.php?id=5628

Cheers
Kraut Rob

Truglodite · Post by **Truglodite** » Tue Jul 09, 2013 12:51 am

Rob, now my OSD works!!! :-)

Just for the sake of clarity, even if you compile KV-OSD with that define, it won't work unless you switch Boxnames on in the GUI too. It's just that the GUI switch doesn't work without that define.

BTW, THANK YOU for developing Harakiri! Flight test reports are the least I can do to help. Harakiri Summergames is loaded on my rig and ready to go. Yesterday I bottomed out hard after flipping; so I can't resume testing until more props arrive.

You might be happy to hear that my FPV copter is sort of unique: custom wound 25gm motors, 7x5 props, 12A esc's, 3s2200, of course Naze32 w/baro, and a 10.75" span h-frame. That should add to the variety of test vehicles.

You mention compass interference, and coming from AC3 testing I'm well aware of what that means. I've seen a few folks mention doing something like AC compassmot on Harakiri. That would be cool. I shall research what's required to install an external compass... any help on this will be rewarded with testing.

Regarding alt hold, I have tried "sweeping the throttle" to engage the 'vario', but it felt a bit vague compared to my AC3 rig... drifty is a good description. I don't think I'm out of the deadzone when it happens... I'm very familiar with the required stick controls from AC3. I figure my vibes are OK; I have isolation mounting, and when I don't play with vario she stays locked as a rock.

Kev

bovi · Post by **bovi** » Tue Jul 09, 2013 5:08 pm

Hi,

A couple of days ago I decided to try a harakiri firmware.
Package works really well

.

Nice work, thanks to Rob and Carsten!

Problem with Position Hold
I have to do something wrong or I missed something because I can not make PosHold work properly...
Quad just fly away slowly (and not return) on boath quads with different gps.

My HW & SW:
Harakiri 10 "Summer Games", 07072013, http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20576
BaseflightGUI 2.2.9.0
Quad1, naze32 rev4, gps u-Blox CN-06 V2.0, http://www.rctimer.com/index.php?gOo=goods_details.dwt&goodsid=763
Quad2, naze32 rev4, gps u-Blox LEA-6H, http://www.hobbyking.com/hobbyking/store/__33998__ublox_lea_6h_gps_module_w_built_in_antenna_2_5m_accuracy.html

I have done:
gps setup in Ublox center (apm ublox.txt, binary protocol...), all OK
gps is properly connected, mag seems to be ok
feature gps enabled
gps_type = 1
set gps_baudrate = 115200
set mag_declination = my position

On FC I have 3 or 4 red blinks, if I understand correctly, that means 8 sats (5sats-1blink, 6sats-2blinks...) and means that communication fc-gps is ok.
In GUI (PassGPS) gps data is shown, no errors, everything seems to be ok.

Is there any indication with leds on FC, when PH is enabled?

I tried different settings for PH from default and on, no effect.

Thanks for the help,

Cheers
Bovi

Crashpilot1000 · Post by **Crashpilot1000** » Tue Jul 09, 2013 10:05 pm

"Is there any indication with leds on FC, when PH is enabled?" No, you will see it. Mag needs to be calibrated otherwise gps functions are disabled. That passgps stuff shows a correct physical connection. The normal mwii gui 2.1 shows the actual parsed and understood Lat/Lon coordinates in the lower right corner. Check them first if they just read 0 .....

@Truglodite: Just port the arducopter core INS and DCM stuff and rewrite the mwii main controller completely as well while you are at it. You will end up with a very vibration sensitive thing that is more locked with altholdchanges. Until you did that it might be reasonable to tune some parameters like alt P / I and D for forward flight and like seen in config.c :

accz_vel_cf = 0.985 // Crashpilot: Value for complementary filter accz and barovelocity
accz_alt_cf = 0.940 // Crashpilot: Value for complementary filter accz and altitude
baro_lag = 0.3 // Lag of Baro/Althold stuff in general, makes stop in hightchange snappier
barodownscale = 0.7 // Scale downmovement down (because copter drops faster than rising)

Nobody can expect one parameterset to work on all copters.

Truglodite · Post by **Truglodite** » Wed Jul 10, 2013 12:59 am

No problem Rob, I will work more on my tuning AH parameters. I'm doing this on a 'basher quad', so vibration tolerance is a high priority. Besides, I'm not nearly skilled enough to "port yadda over to yadda" LOL.

Regarding your answer to bovi about 0'd mag calibration, would a 0'd ACC calibration also disable GPS functions?

I had similar behavior in GPS hold, and CLI dump shows numbers in align_mag_*. OTOH, align_acc_* calibration keeps coming out out all 0's. Tx stick command and the GUI button give the same result. The green LED is indicating ACC calibration mode; I highly doubt the board is mounted perfectly level.

The Harakiri ACC calibration routine is "level frame then hit button" correct? (no flipping the frame around on a bench like AC3)

Crashpilot1000 · Post by **Crashpilot1000** » Wed Jul 10, 2013 2:18 am

@Truglodite: Sorry for my impatience but it is only as good or bad as i can make it. I would love to understand all that quaternion and dcm stuff and advanced filtering etc but i am too simple for that.
Yes, the acc calibration is just on plain ground. Do some trimming on the first flight if necessary. Someone in this forum wrote that mpu comes precalibrated from the factory and doesn't need such extended calibration. I haven't dug into that mpu stuff but acc calibration on dji naza is also done on flat ground without putting it on all sides, so that statement SEEMS to be right. Does Arducopter only do it to support older APM1 hardware? But why bother APM2 users as well? I simply don't know, but they will have a good reason for that, probably it will give a slight accuracy advantage for APM2 hardware as well. Playing with the mpu and it's DSP features might help - like shown in that opensource BL Gimbal soft. I think sebbi did some work in that area as well but found it too undocumented and actually stayed away from it - if i remember his post right. But who knows.
Back to the story. Using CLI dump you will actually not see the calibration offsets of the magnetometer. It will just put out the physical orientation of the sensors like godfather TC soldered them on. You should see something like this with "dump":

Code: Select all

...
set align_gyro_x = 0
set align_gyro_y = 0
set align_gyro_z = 0
set align_acc_x = 0
set align_acc_y = 0
set align_acc_z = 0
set align_mag_x = -2
set align_mag_y = -3
set align_mag_z = 1
...

The calibration offsets are actually stored in something called "magZero". The gps stuff will only work if it reads out the variable "mag_calibrated" in EEPROM wich is set after calibration. You will know that it is set when your GUI shows the compass moving when moving the copter, otherwise it will point to zero (north).
If you think you have trouble with that "new" calibration method, you can use the "oldstyle" as well altering these variables:
mag_oldcalib = 0 // 1 = old calibration // 0 = extended calibration (better)
mag_oldctime = 1

so set mag_oldcalib = 1 (and save) and you are done. With mag_oldctime = X you can set the MINUTES for that calibration type. That option is mainly for a friend who built that: http://fpv-treff.de/viewtopic.php?f=53& ... =20#p37047 . He will have a hard time swinging that copter around in one minute....
I never calibrate with usb attached (magnetic disturbance). I calibrate the copter by stickcommand with Lipo in its' correct place and everything electric on - besides the motors of course. That gives the best results. After that i check with the gui, if every axis is exactly 90/180 degree apart. Sometimes I have to redo the calibration. But after 30 calibrations you will have a perfect style of turning that thing and getting it right in the first place

. Flip it around pitch, then roll, then do a complete yaw then a complete jaw on its' back. Then put it vertically and spin it one time around. For the rest of the time do a "Moebius strip" - move while turning around. That looks also silly but works.
The Mag calibration is independent of the declination you put in. So you can change it afterwards without loosing your calibration effort. The magcalibration you are doing is actually gathering some offsets +/- . On startup the mag calibrates itself to the local magfield and produces some gains for each axis. So your calibrationoffsets include that gain, but if you fly in an area with a different strength of the earth mag field your offsets might become invalid. And you will see TBE very soon. At the end of the calibration i store a value as well of what i think resembles to the total strength of the magnetic field of your calibration place. It is currently not used to warn you that your stored calibration was done at an completely different earth mag field strength than your actual -want to fly position. So in doubt just redo the magcalibration in the field.

Cheers
Rob

bovi · Post by **bovi** » Wed Jul 10, 2013 10:50 am

Hi!

@Rob,
Mag is calibrated and holding well, if I turn quad in the air by hand in other direction, goes back smoothly.
I took the advice and do mag calibration again as you're, without usb connecting.

I tried with mwii gui 2.1 and seems to be Ok. Only speed jumping up and down slowly from 0-10...

Still no change and just do not feel that something happens when I turn on PH switch.

Thanks,
Bovi

Truglodite · Post by **Truglodite** » Thu Jul 11, 2013 6:09 pm

Rob, thank you for informing me on the details of Harakiri compass. Note in this video how my home arrow seems stuck pointing "N/W":

Unfortunately I think my particular quad will require an external compass to get PH/RTL working. There is a picture of my frame in that video (4:26); you can see how bad the situation is. I already have an HMC5883L breakout board leftover from another project, but the only info I have found on MWii external compass has to do with 8bit boards & firmware:

http://www.rcgroups.com/forums/showthread.php?t=1874276
viewtopic.php?f=6&t=2700

I am willing to dremel off my old compass etc, but not sure where to start with modifying the code for an external compass. I finally got Harakiri SummerGames to compile BTW; I was copying the source in Eclipse... copying with Win Explorer did the trick. :oops:

**EDIT**
I reviewed the schematics and it doesn't look as simple as I thought. The compass pin 'DRDY' is wired up to the MCU pin 25, and there is no break out for that on my board or my compass module. I am not sure how DRDY is used, or if there is any way around connecting it. Seems most FC's only need SCL/SDA/VCC/GND anyways.

z01z · Post by **z01z** » Fri Jul 12, 2013 11:14 am

Truglodite wrote:I reviewed the schematics and it doesn't look as simple as I thought. The compass pin 'DRDY' is wired up to the MCU pin 25, and there is no break out for that on my board or my compass module. I am not sure how DRDY is used, or if there is any way around connecting it. Seems most FC's only need SCL/SDA/VCC/GND anyways.

That DRDY pin has only been wired on the latest rev of naze PCB (white), previous versions didn't have them - I've a blue PCB and it's not connected. So I think you shouldn't worry about this.
Btw, I have similar plans to use an external compass, cutting the SCL and SDA lines should be enough. This can be done nicely so restoring the original state is also a possibility.

I am willing to dremel off my old compass etc, but not sure where to start with modifying the code for an external compass.

If you connect the external module the same way the original mag IC was connected, I don't think there's any need for code change.

mr.sneezy · Post by **mr.sneezy** » Fri Jul 12, 2013 1:42 pm

Crashpilot1000 wrote: I calibrate the copter by stickcommand with Lipo in its' correct place and everything electric on - besides the motors of course. That gives the best results. After that i check with the gui, if every axis is exactly 90/180 degree apart.

Rob can you explain that a bit more ?
Where in the GUI do you look for the 90/180 degree separation, or do you just yaw 90 degrees at a time on the ground and see the compass positions ?

Cheers,
Martin

Crashpilot1000 · Post by **Crashpilot1000** » Fri Jul 12, 2013 7:29 pm

@mr.sneezy: Yes i turn the copter by hand and look at the gui. A 90 deg trun should be equal to the compassmovement. N/S and W/E should be exactly 180 deg (+-2 deg, sensor accuracy) If your calibration is wrong you will see it directly. Also check for deviation when tilting. I heard of people killing their Mags by putting real magnets onto them for testing the hell of it. I don't know, if thats true but magnetizing a Mag sensor seems to be not the greatest idea....
@Truglodite: Nice Vids! Harakiri PIDS are not the same like BF! Normally you can set at least the P higher. Harakiri does it with floatpoint calculation and uses some delta time as well. I think it is smoother than the original 8Bit port.
@bovi: Don't know whats up with your setup. A PosP of 200 is crazy, that's for sure.
Cheers
Kraut Rob

EDIT: Next Harakiri will have some Mavlink/Missionplaner/MinimOSD support. Mavlink is working quiet well right now but needs some polishing. Actually I am fighting with EEPROM, when that is Done you will be able to record your flight (15Min Limit) and re - do (& Autolaunch) it or load it in missionplanner and edit it as WP list (but limited WP Numbers - may be 20 - or more? - i don't know what i really need for data right now). Thats the plan. There will be restricions (no circle mode or extra fancy stuff right now) but that is the masterplan. I think that is something to look forward to. Meanwhile i revised the PH/INS stuff for that. Testing seems very promising - so stay tuned.... more to come.
Currently I implemented Mavlink/Mwii Autosensing (DONE) so you can fire up MP or Mwii Gui or whatever and it will connect. GCS doesn't understand the Parameterlist right now - only god knows why. Mp shows the parameterlist and you can edit/save/compare it. For MinimOSD I transmit the RC Channels, Voltage, GPS Data, IMU Data and flightstate. MinimOSD expects 57K. So there seem to be 2 Options: Set Harakiri to 57K on USB or compile (Arduino IDE) MinimOSD to use 115K Baud. It should be sufficient to connect MinimOSD only with +/- and TX because my current code sends the data at ca 2 Kb/s without request (that is normally necessary for minimOSD). When i am finished typing codelines i will heat up the soldering iron and attach a real minimOSD to see what it is doing...

brm · Post by **brm** » Sun Jul 14, 2013 8:32 pm

when will you show mavlink support?
the osd is in front of me.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Jul 14, 2013 10:20 pm

brm wrote:when will you show mavlink support?
the osd is in front of me.

NOW! http://fpv-treff.de/download/file.php?id=5781
That is also the new version

.
There is a detailed readme included in plain Denglish.
Mavlink/Mwii autosensing works and some other basic mavlink stuff.
Mavlink is still a lot of work ahead but i think that source might be a reasonable implementation and something to start with.
Pls check out if minimosd shows some data. I didn't check that.

EDIT: Update: I checked with MinimOSD extra 2.2 (" MinimOSD Extra Copter 2.2.hex" from here: https://code.google.com/p/minimosd-extra/downloads/list) and it is working! I just connected the minimosd with its' RX line to the Nazes' TX line (+5V and GND as well). So I just saw "0" values in minimosd because it was kept alive with my Heartbeat Mavlink/mwii - Autodetection. Minimosd wasn't able to send stuff back and lock my autodetection, because its' TX line was not connected. When arming the copter the minimosd came to life - like hoped! The data I saw seemed to be correct (lat/lon/heading/temp/dist to home/alt/vel/vario/horizon). Voltage is also transmitted but not connected on my naze. Because my setup consisted of loose cables, I couldn't do more with it with spinning motors..... Proof of concept is done...working. Hopefully all dimensions are right, i tried hard to get them right in the first place with my apm and GCS/MP for comparison.
BTW: That code is based on Meisters great work here: https://github.com/slashphotos/harakiri ... er-mavlink
Without him I wouldn't have had a clue what to do with mavlink. The arducopter source is rather confusing in that area.

Cheers
Kraut Rob.

brm · Post by **brm** » Mon Jul 15, 2013 8:40 am

thanks!
i hope to do more testing now and during the next week.
have not done anything lately ...
best rob

Gaijin · Post by **Gaijin** » Mon Jul 15, 2013 7:34 pm

Amazing work crashpilot, this project is racing along, did you manage to add a setting for magnetometer refresh speed or sensistivity, mine still tick-tocks left to right when activated

Crashpilot1000 · Post by **Crashpilot1000** » Mon Jul 15, 2013 8:53 pm

Well, I think it is not possible to overcome a problematic hardwaredsign concerning Mag in the first place. I wouln't expect miracles from the arducopter compassmot as well. That's probably why they are selling external mag/gps combos.
With the last version you can adjust the gyro/mag complementf. factor. But I guess it won't help you

.
gyro_cmpfm_factor = 1000 // (10-2000) 200 default for 10Hz. Now 1000 for 70Hz seems ok. Gyro/Magnetometer Complement. Greater Value means more filter on mag/delay

Greetings
Rob

Crashpilot1000 · Post by **Crashpilot1000** » Tue Jul 16, 2013 10:42 pm

Short notice: Updated the last version with a more correct Bearing calculation. That arduinostuff always steered a few deg. off - thats gone now

. It will fly now an exact line to the designated target (currently just Homepos/RTH). See here http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20576 and http://fpv-treff.de/viewtopic.php?f=18& ... 720#p40827 for more details.
Just a small update to make things nicer...
Could be easily implemented in BF as well.

Cheers
Rob

mr.sneezy · Post by **mr.sneezy** » Wed Jul 17, 2013 2:38 pm

Hi all. Thought I'd post you a pic of my latest HW hacking (as it's running Harakiri)
I've fitted an Arduino GY-86 so called 10DOF IMU board to my old FreeFlight board. That went well enough, Harakiri seems to pickup the sensors as it should. The only thing not correct is the Mag orientation, but I'm working on that. From what I read and understand (maybe there's a problem) I should have only needed to reverse the sign of two axis as the chip is backwards, but it's been hard to work out which two are actually the right ones in the CLI...

I'll post a question on the old RCG FF board thread about that.

Martin

Truglodite · Post by **Truglodite** » Thu Jul 18, 2013 8:26 pm

Nice work Martin! Are you the same Martin from the RCG DIY antenna tuner thread?

Great to read about your latest improvements Rob. I'm frustrated that I can't join in on the fun due to my problems with compass interference. I'm close to jumping off that cliff and dremeling off my onboard compass; I looked carefully and cutting traces isn't possible (SCL trace hides under the compass). At least I figured out where to get the 3v3 from... just don't want to slip with the dremel tool and cripple my only SMT32 copter. Maybe it's time to invest in a hotair rework station. 8-)