Harakiri aka multiwii port to stm32

frog32 · Post by **frog32** » Wed Feb 12, 2014 10:32 pm

@Crashpilot1000: You should take a look at this documentation http://git-scm.com/documentation. git seems hard but it can be a blessing when it comes to tracking changes, finding bugs which weren't there some versions ago and letting others contribute. if you have any problems or questions you could always ask.

mj666 · Post by **mj666** » Thu Feb 13, 2014 2:16 am

I have finalized my code for the SRFxx sonar sensors an published this at the FPV-Treff Forum. Here is some Information also can be found inside of the code:

Code: Select all

    // Devantech Ltd. SRF02, SRF235, SRF08, SRF10:
    // Operation Voltage is 5V (NAZE I2C is 3.3 Volt, SRF rangers do not have pull up resistors and outputs are
    // open drain so there is no risk kill something only signals may be critical so keep wires short as possible.
    // Type; Range; Cycletime; Angle; Comment
    // SRF02; 16 to 600cm; 65ms; 55 degree; automatic calibration, minimum rage can be read from sensor (not implemented)
    // SRF235; 10 - 1200cm; 10ms; 15 degree; angle is may be to small for the use case
    // SRF08; 3 - 600cm; 65ms; 55 degree; range, gain an cycletime can be adjusted, multiple echos are measured (both not implemented)
    // SRF10; 6 - 600cm; 65ms; 72 degree; range, gain an cycletime can be adjusted (not implemented)
    // be sure to adjust settings accordingly, no additional test are done.
    // more details at: http://www.robot-electronics.co.uk/index.html

Some feedback to the questions in my last post would be appreciated. Waiting for the flight test at the weekend.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Feb 13, 2014 7:08 pm

@Hinkel. Thanks for checking that! I had a chance to check that today between the rain and yaw is a little slow, so I changed the default YAW speed line to: (2 * "(int32_t)cfg.yawRate + 42" (was +30 before). +60 is very nice on my copter but I will leave it at a lower default rate so it can be increased with the gui. The acro default "I" was and is too low that leads to loosing the angle, increasing it should do the trick. BTW JIhlein released a new version that includes a hexfile! I still have to make my way through the CLI to get it running.
@frog32: Thanks!
@mj666: Thank you very much for doing that driver, haven't been visiting fpvt for months now. 2.5 is latest version the rest is just preparation for 2.6. I will look at your driver!
@rest: In opposite to TC this is private and unpaid stuff and I don't have the nerves and skill to do any better. So I apologize for putting code on display that might be useful. I have a little greetingscard attached for the people that want to tell me what I have to do in my freetime.

Cheers
Rob

LVNeptune · Post by **LVNeptune** » Thu Feb 13, 2014 7:16 pm

Those fucks you are giving, how can I obtain one

mj666 · Post by **mj666** » Thu Feb 13, 2014 9:33 pm

This means it's more save to backport my driver fro now to SG2.5 for save flying?

Crashpilot1000 · Post by **Crashpilot1000** » Fri Feb 14, 2014 4:28 pm

Neptune: You can pick one up in the meadow!
@mj666: Not sure. 2.5 is save if the normal controller is used (like default). BTW: Maybe I2C sonars could live in the sensors autodetection but skipped with feature pass enabled. Anyway, I will have to add the disconnect detection for I2C sonars. Otherwise a failure in flight is a sky rocket desaster, if you are not quick on the althold-off switch... I experienced it once with a loose cable on my PWM maxbotix...
Cheers Rob.

mj666 · Post by **mj666** » Sat Feb 15, 2014 10:42 pm

The weather is not good for flying this days so I have continued to work on the code to also add support for the Maxbotix I2CXL series of sonar sensors. I also have moved all sonar sensor hardware specific code out of sensor.c. The coding is already complete. I ordered an MB1242 sensor and waiting for the delivery. I will published the updated code after testing the new sensor.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Feb 22, 2014 2:39 pm

Short notice about current progress. Mj666 Sonar drivers have been implemented (thanks for your extensive work on that subject) practical usability of MBTX I2C devices pending. @Aadamson: Found mag sign failure (and some other things) in my MARG adaption - will give it another shot - currently redoing the mwii core once again.... hopefully some working code in the next 4 hours ... let's see if that works like expected I would be very happy to kiss the mwii core goodbye on stm basis.

EDIT: Just read the sonar discussion on the other thread (-> see attached picture)

subaru4wd · Post by **subaru4wd** » Wed Mar 05, 2014 11:50 pm

I was shopping at Witespy's website and noticed he released a new version of the Flip32+ board. A v2.1_rev5 ( http://witespyquad.gostorego.com/flight ... 2-249.html ) which I assume follows along with the changes made in the Naze32 rev5 boards. If so, would this mean that Harakiri would not be compatible with this new Flip32+, like it is not currently compatible with the Naze32 rev.5? Or, has that been fixed and am I just behind on the times?

I have a buddy who just picked up a Naze32 rev5 and I wanted to get him setup on Harakiri, but I remember people saying it wouldn't work.

timecop · Post by **timecop** » Thu Mar 06, 2014 12:37 am

Except it doesn't. But at least he reverted the idiotic 5V/GND/SIG crap on inputs and outputs.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Mar 06, 2014 5:51 am

Hi Subaru. Those witespyquad boards are Nz4 compatible as far as I know. Currently working on a version

. I bought a flyduino mw32 (version 2) too early to say something definitive (until sitting on a copter and flown) but witespyboard looks better designed than that (seen on the picture of your link).

theailer · Post by **theailer** » Thu Mar 06, 2014 7:29 am

I've always used a naze r5 for harakiri. No problems here

JaNpIrAtE · Post by **JaNpIrAtE** » Thu Mar 06, 2014 6:47 pm

can i get the link to download SG2.6 ?

thanks

Crashpilot1000 · Post by **Crashpilot1000** » Fri Mar 07, 2014 10:23 am

Stand by dude. I cleaned the repo a little and wanted to upload a new version yesterday but during testing I crashed my copter (own stupidity) into the tree. So fix copter, test code, upload ....

subaru4wd · Post by **subaru4wd** » Fri Mar 07, 2014 5:35 pm

Crashpilot1000 wrote:Stand by dude. I cleaned the repo a little and wanted to upload a new version yesterday but during testing I crashed my copter (own stupidity) into the tree. So fix copter, test code, upload ....

Damn those trees! They get me all the time too.

Im starting to get better at hitting them though

http://www.youtube.com/watch?v=2rr7aQIPXwE

mj666 · Post by **mj666** » Sat Mar 08, 2014 10:31 pm

I have finished my test for the Maxbotix I2CXL sensor. Its working now quite well. Since the Maxbotix sensor only support 100kHz I2C speed I have to implement dynamic clock switching. The modified code and the related HEX file is published in the FPV Treff forum.

leocopter · Post by **leocopter** » Mon Mar 24, 2014 9:36 pm

Crashpilot1000 wrote:Hi Subaru. Those witespyquad boards are Nz4 compatible as far as I know. Currently working on a version . I bought a flyduino mw32 (version 2) too early to say something definitive (until sitting on a copter and flown) but witespyboard looks better designed than that (seen on the picture of your link).

Hi,
the latest witespy Flip32 and Flip32+ boards are compatible with Naze32 Rev 5. They are 'plug and play' with Baseflight. I have AcroNaze32 and Naze32 rev 5 boards and can't see the difference performance wise. The Flip32 boards have proper break out headers for serial port and I2C.

leocopter · Post by **leocopter** » Mon Mar 24, 2014 9:43 pm

timecop wrote:Except it doesn't. But at least he reverted the idiotic 5V/GND/SIG crap on inputs and outputs.

You're right about that ! The mixed up 5V/GND/Sig header was an invitation to fry your board ... NOT the 'design of the year' ... The newer boards are 'back to normal'.

leocopter · Post by **leocopter** » Sun Mar 30, 2014 11:47 pm

I finally took the plunge and flashed a Flip32 and a Flip32 + with Harakiri (Thanks Subaru4wd). Each set up took less than 10 minutes. I am using MultiWinGui 2.2 for settings and CLI to activate features (stop the Mavlink 'garbage' in the CLI with the ### command). Both boards work very well. I did a short comparison between the Naze32 + Baseflight and the Flip boards with Harakiri on the same micro test bed. They all perform very well (see picts).

hinkel · Post by **hinkel** » Mon Mar 31, 2014 2:14 pm

Hi just a proposition for an old problem http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=63126#p63126

1SQ · Post by **1SQ** » Mon Mar 31, 2014 4:45 pm

i Just received my Naze 32 red version, can someone pls direct me to the harakiri firmware to upload to my board.
The board is currently loaded with base flight.

Crashpilot1000 · Post by **Crashpilot1000** » Mon Mar 31, 2014 5:08 pm

Hi, Hinkel!

Actually users will die one death when switching modes with zero throttle. I once had programmed a solution (for mwii version) with softexit. You quit Baromode by flipping the switch but the copter would stay in baromode until you reach (or surpass) the actual motor - throttle with the throttlestick. It is very smooth and comfortable but users freaked out (readme.txt or the german fulltext by that time was not read by anyone....) that the copter stayed airborne though the switch was off (that particular user did his first flight ever and struggled with RC controls in general -> steered it into the house wall with althold still engaged). That's mainly why that option disappeared/didn't make it into the 32Bit version. Baro switch off = Baromode off no matter what, I see your point but I will keep that logic. I think "rc_motor" could be also an option to look into in this regard.
The main reason for rc_motor is, that the PID control is still active (and motors running) when throttle is minimal. That is turned off by default because it is risky when standing on the ground and some building up "I" flips the copter on the ground. That is also why mwii has no PID regulation on the ground. But this is unproblematic on quick lift offs and copters with no high landing gear and good for acro, since there is always PID support even with idle gas.
rc_motor = 0 (default) // [0-2] Behaviour when thr < rc_minchk: 0= minthrottle no regulation, 1= minthrottle&regulation, 2= Motorstop
So your proposal would loosely speaking resemble rc_motor = 1.

Edit:
@1SQ: There is currently no hex version for N5 in the download. I can attach here the compiled Version of "TestCode3".
Cheers Rob

hinkel · Post by **hinkel** » Mon Mar 31, 2014 6:01 pm

Hi Crashpilot !

Yes, I have also rc_motor = 1 enabled and it is just fine. Sorry I am an old man with some Alzheimer and you are certainly right
to not implement this if it is so Problematic for other users. So I keep it for me !

Gruss

Mr-Fiero · Post by **Mr-Fiero** » Sat Apr 05, 2014 3:41 am

>To Crashpilot1000
I want to first say Thank You very much for your work on Harakiri. I have tried MANY boards and firmwares but I think that your work has been a better working solution for all GPS, and even flight performance.

The latest TestCode4 flies very well. I did notice that TestCode3 loitered pretty good, but for some reason I cannot get TestCode4 to loiter. As soon as I start to loiter, it wants to go to the right quickly.

I have really tried not to ask, and have searched the source code, and git readme, as well as searching the internet and cannot find an accurate answer. Can you just let me know please as this is my only hangup. at one point i had 13 set for mag_dec and it was my best hover. This is why I am really questioning my setting.

(dddmm) ?

My declination is
Magnetic declination: 13° 38' EAST
Declination is POSITIVE

so would i do this? ignoring the leading zero?
set mag_dec = 1338

Anyways, thanks for any tips, and keep up the good work!

Take care.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Apr 05, 2014 7:37 am

@Mr-Fiero:
Thank you very much for your friendly feedback!
First of all I want to write something about the mag declination, because that also applies to baseflight and may help other users reading this.
Your example:
Magnetic declination: 13° 38' EAST -> Means 13 degree and 38 minutes.
Declination is POSITIVE -> Is the sign of the cli value.
The cli value is expected with the degree "in the hundreds" for the later conversion so minutes must be a two-number-value. Leading zeroes of the final cli value can be omitted.
So, yes "1338" is the correct input. If your declination would be
Magnetic declination: 3° 8' EAST
The cli input would be "308".
To answer your question why your copter wants to go right in PH - I don't know for sure right now but the best guess is, if it's not a wrong mag calibration, that it is associated to my spikefilter and your GPS doing some nasty spikes with the ublox. But even that should only do some short term jittering in flight.
Can you tell me something about your LAT/LON coordinates you are flying at? (Note: I wouldn't disclose actual LAT/LON coords here - just for personal safety).
Are you flying over LAT = 0 or LON = 0 (Equator / Prime Meridian)? Or over 180th meridian (east Sibiria)?
What are the signs of your LAT/LON values?
Cheers
Rob

strips · Post by **strips** » Sat Apr 05, 2014 9:18 am

Crashpilot1000 wrote:Your example:
Magnetic declination: 13° 38' EAST -> Means 13 degree and 38 minutes.

So, yes "1338" is the correct input. If your declination would be

Hi, I'm thinking of trying Harakiri now I got Baseflight working good.

I thought you had to convert degree and minutes to decimal? Just as well I still haven't tested GPS-HOLD :-)

Crashpilot1000 · Post by **Crashpilot1000** » Sat Apr 05, 2014 10:32 am

You have to convert in multiwii but not in Baseflight or Harakiri. It boils down to a difference of 2 lines of code but mwii tries to spare every single byte so that must be the reason why it is missing there (Edit: and the user has to use his/her calculator).

Mr-Fiero · Post by **Mr-Fiero** » Sat Apr 05, 2014 9:19 pm

Thank You!
Very Clear and thats what I thought it would be. the leading zero does not matter but the "mm" would need a zero to be read properly as both digits are needed before "ddd" would be correctly read. so to be clear for others as well, its "dddmm" (degrees degrees degrees minutes minutes)

I was wondering about the spike filter possibly causing differences. I am running a Ublox7C at 10HZ with "stationary" model. I let it setup first for 5 minutes and had 12 sats so I think it was doing OK. however I was testing on a light breeze with clouds and no real skyview so my GPS might of been drifting a bit. Its really windy where I am but I am waiting for my next chance to get out and test more with newer code. I might test the pedestrian model to see if its different in the Ublox.

Now that I know the mag_dec was correct, I can look into other reasons. I had to rule that out first.
I try to run with your default settings on a test machine on a X600 frame, 1000kv motors, 11x5 CF props.

Thanks again for the tip, and take care!

Crashpilot1000 · Post by **Crashpilot1000** » Sun Apr 06, 2014 2:13 pm

Hi Mr-Fiero!
TY for the LAT/LON PM. Try pedestrian, I didn't check with stationary but I guess the speed representation in stationary may be not so good....
However, if Testcode3 was running fine and Testcode4 not and your magcalibration is done correctly it must be somehow the spikefilter since that is the major change there. Still wondering how it can trouble stuff since it's not altering the gps values it is mainly just sorting the last 4 GPS values (in an array of 5 values).
If the gps fix is lost the spikefilter is cleared and values are just taken if it is not in runup phase and if the current GPS value is more than 6m away from the spikefilter result. Hmm...

Mr-Fiero · Post by **Mr-Fiero** » Sun Apr 06, 2014 9:25 pm

OK, my weather is really poor right now but here it an update regarless. It is windy and raining, and a touch of snow, but I flew with putting a piece of tape to cover my FLIP32+ FC ,could not wait anymore

I changed to 5hz update on the ublox with pedestrian as you suggested. The only reason why originally I was in stationary is because the GPS reported more accurate position over time, but I now feel that the updates are not fast enough (or averaged/massaged) to use that mode in flight. It was just a test, and now I know.

I had to change the GPS position pid a bit higher but wow did it loiter well against the wind. wind here right now is 10km/h to 40km/h and it handled it very well! Maybe next test I might lower the GPS position expo as well and see how it handles the wind. Its windy allot in my location and thats why I play with that condition more.

One think I did notice is that while in PH mode, if you try to adjust the altitude it does nothing. you actually have to exit PH mode, adjust, and then re-enter PH and then it holds to the corrected altitude. Even the position seemed to work this way. If you adjust while in PH with the sticks, settle it while holding with the sticks, and then let go to center sticks, it seems like it wants to return to previous position. Could this be because of the spike filters maybe not allowing new position as the GPS would appear to be a spike? Again, my work around was to exit PH, move to new position and then re-enable and it would hold at new position very well even against the un-predictable wind.

I had to stop testing at this point as the winds have bursts of 40km/h plus and its really raining... LOL I want to further test the PH and how it handles small position corrections while in that mode. I will post my updates as soon as I can.

I was very happy with my flights today, and I am glad to find such a good solution (Harakiri) for STM32F3 boards!

strips · Post by **strips** » Mon Apr 07, 2014 3:48 pm

I just tried TestCode3.

Got it flashed and connected to CLI. I'm not able to connect Baseflight configurator. I downloaded BaseflightGUI2 but how do I start it?

Do you have a recommended gui for Windows? I like the gui for viewing RC controls and setting flight modes.

Mr-Fiero · Post by **Mr-Fiero** » Mon Apr 07, 2014 4:40 pm

strips > I just wanted to chime in to help on the issue you have with your GUI as at one time I had the same frustration.

Your probably missing the .exe in your gui
this location has the exe included in the zip, I checked the download today before I wrote this message.

http://www.klick-punkte.info/download/B ... tGUI23.zip

FYI, I try NOT to use GUI on firmwares that are undergoing dynamic changes as internal commands, can be changed, added, deleted, and the GUI may not reflect this until it is updated as well. Welcome to BETA! BaseflightGUI23 does work well so far, but I didnt check what what missing from the newer source code.

Also, in the field I find this program very effective. Not 100 percent Harakiri but nice for PID settings. also allows easy access to the CLI for quick changes over bluetooth or whatever. https://play.google.com/store/apps/deta ... o.multiwii

the CLI is actually VERY nice in Harakiri.

strips · Post by **strips** » Mon Apr 07, 2014 4:53 pm

Mr-Fiero wrote:strips > I just wanted to chime in to help on the issue you have with your GUI as at one time I had the same frustration.

Your probably missing the .exe in your gui
this location has the exe included in the zip, I checked the download today before I wrote this message.

http://www.klick-punkte.info/download/B ... tGUI23.zip

FYI, I try NOT to use GUI on firmwares that are undergoing dynamic changes as internal commands, can be changed, added, deleted, and the GUI may not reflect this until it is updated as well. Welcome to BETA! BaseflightGUI23 does work well so far, but I didnt check what what missing from the newer source code.

Also, in the field I find this program very effective. Not 100 percent Harakiri but nice for PID settings. also allows easy access to the CLI for quick changes over bluetooth or whatever. https://play.google.com/store/apps/deta ... o.multiwii

the CLI is actually VERY nice in Harakiri.

Thanks. I'll give it a new go tonight :-)

Crashpilot1000 · Post by **Crashpilot1000** » Mon Apr 07, 2014 5:17 pm

@Mr-Fiero: Thanks for the testreport. I am currently re-arranging the whole GPS / automization stuff because all the parts work but not unproblematic together.
I hope to have a better version soon. EDIT: BTW you wrote something about the gps_expo (default 20 %). Just to mention it to prevent misunderstandings. "gps_expo" is nothing you will feel on the sticks. I came up with this as an substitute for the original multiwii slewrate. It's function is to smooth the final GPS output because the gps produces some tremor on it's "virtual gpssticks". If you don't see your copter tremoring in GPS mode 20% is fine. When you increase it you might get too much unlinearity and that will be very contraproductive. So the smaller the value the better.
@strips: I am using the normal multiwii 2.1 gui and this nice terminal https://sites.google.com/site/terminalbpp/.

Mr-Fiero · Post by **Mr-Fiero** » Mon Apr 07, 2014 9:50 pm

I was only adjusting the gps_expo because in one of my tests in the wind, after a long loiter, and with a burst of wind, it tried to correct, was a touch slow, and then over-reacted , then same thing again, and then going back and forth. (1Meter) It was not bad, but I just thought that maybe the gps_expo was too high and possibly too delayed amplifying the corrections. My GPS delay is low as it is set to 600ms as I use Ublox protocol only at 115200 baud. I also tried to set the gps pos PID higher and it didnt seem to help as I duplicated the issue with a higher P setting.

I understand its not normal for adjusting loiter in windy days, but if it works in a worse case situation, it will probably always work.

I only lowered it to 15 instead of 20 so I will see if it makes any changes.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Apr 08, 2014 3:06 pm

Absolutely! I see you really looked into it!
The PH "flyback" on stick release you mentioned is something I don't know how to solve without loosing safety. Currently the accelerometerdata are just used for speedfeedback and not for positionfeedback on LAT/LON - that is completely left to the GPS. I tried that and calculating target GPS values based on different proceedings but in the end I found that too unreliable resulting in safety problems. "flying GPS" coordinates (stickmovement adjusts LAT/LON) is smooth until a problem occurs so it's dangerous IMO, so I stick to the override method: Nick/Roll always oversteer/disable GPS wishes, when released copter will do relative brake and wait for a gps position to catch up (gps lag) and take that (though it might be in a radius of 2m with the underlying gps accuracy). So if something goes wrong you always have the copter on your sticks without loosing control authority.

strips · Post by **strips** » Tue Apr 08, 2014 8:39 pm

Sweet! I got it almost in the air

Rookie mistake and forgot to charge the battery. At least I can verify the battery alarm is working.

Thanks Mr-Fiero for the BaseflightGUI23.

For terminal Putty is doing a great job.

I did not get any GPS lock while inside. I did get lock inside the other days but now it's raining!

Should I lower my GPS delay as I'm only using ublox protocol and 115200?

strips · Post by **strips** » Tue Apr 08, 2014 8:55 pm

I have another problem I never got right in Baseflight either.

How to get telemetry to my Taranis with a D8R-XP reciever. I have connected telemetry TX on Naze32 to RX on the reciever, ground to ground. In CLI I have enabled tele_prot = 1 and saved.

When I arm I get nothing in the telemety views. Only RSSI which comes directly from reciever.

I think I need to verify telemetry out on the Naze32. Is it possible to connect the telemetry port to an FTDI adapter and look at the output in terminal?

strips · Post by **strips** » Tue Apr 08, 2014 10:06 pm

Just did a stupid test but couldn't wait

I went out in the dark under a streetlight, very light rain and a little too much wind.

I did not get the locked feeling in angle with default PIDs as Baseflight but fairly ok.

Alt hold freaked me out before I remembered how it works in Harakiri

Mostly it kept height within 1m. I was only flying 2m off ground in the dark.

PH I had to abort. Too windy and not enough space as it drifted at least 2m towards a car. I had five blinks and that would give me 10 sats? But I only waited 1 minute.

CoolD · Post by **CoolD** » Tue Apr 08, 2014 10:22 pm

1SQ wrote:i Just received my Naze 32 red version, can someone pls direct me to the harakiri firmware to upload to my board.
The board is currently loaded with base flight.

Did you figure out where to start ? I'm looking to try out harakiri as well but have no clue where to find the firmware

ok after looking a little further here's the code
https://github.com/slashphotos/

and here is how to compile the code
http://www.rcgroups.com/forums/showthread.php?t=1695379

good luck

Mr-Fiero · Post by **Mr-Fiero** » Wed Apr 09, 2014 12:36 am

FYI Compiling in Linux is easy as all you need is the gcc-arm-none-eabi toolchain. Windows is so complicated for just a compile.

I cant remember but I think this would work for toolchain as well in linux
sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install gcc-arm-linux-gnueabi

then "git clone" the repo
and enter and run "make"

Mr-Fiero · Post by **Mr-Fiero** » Wed Apr 09, 2014 1:06 am

strips wrote:Sweet! I got it almost in the air Rookie mistake and forgot to charge the battery. At least I can verify the battery alarm is working.

Thanks Mr-Fiero for the BaseflightGUI23.

For terminal Putty is doing a great job.

I did not get any GPS lock while inside. I did get lock inside the other days but now it's raining!

Should I lower my GPS delay as I'm only using ublox protocol and 115200?

Ublox has lower delay, so I did lower mine to 600ms. (suggested elsewhere is 500ms for Ublox) make sure the model is set to pedestrian as this seems to be the best setting.

I also ran baud at 115200 because the stm32 does not have issues with higher bauds like the atmega's did. If your doing GPS functions, make sure your GPS is performing well, and with ucenter you can see it with the deviation map. Otherwise with Harakiri it will try to follow your GPS only as well as it performs.

Crashpilot has VERY good default values in his firmware, so you should be able to get up in the air rather well. Hope it goes well for you.

Mr-Fiero · Post by **Mr-Fiero** » Wed Apr 09, 2014 1:12 am

CoolD wrote:
1SQ wrote:i Just received my Naze 32 red version, can someone pls direct me to the harakiri firmware to upload to my board.
The board is currently loaded with base flight.

Did you figure out where to start ? I'm looking to try out harakiri as well but have no clue where to find the firmware

ok after looking a little further here's the code
https://github.com/slashphotos/

and here is how to compile the code
http://www.rcgroups.com/forums/showthread.php?t=1695379

good luck

I dont know if this helps, but earlier in this forum there was a working compile as a zip....look here. I did run this code once and it worked fine, but I compile usually anyways.
viewtopic.php?f=23&t=3524&start=570

strips · Post by **strips** » Thu Apr 10, 2014 8:27 am

Mr-Fiero wrote:
strips wrote:Sweet! I got it almost in the air Rookie mistake and forgot to charge the battery. At least I can verify the battery alarm is working.

Thanks Mr-Fiero for the BaseflightGUI23.

For terminal Putty is doing a great job.

I did not get any GPS lock while inside. I did get lock inside the other days but now it's raining!

Should I lower my GPS delay as I'm only using ublox protocol and 115200?

Ublox has lower delay, so I did lower mine to 600ms. (suggested elsewhere is 500ms for Ublox) make sure the model is set to pedestrian as this seems to be the best setting.

I also ran baud at 115200 because the stm32 does not have issues with higher bauds like the atmega's did. If your doing GPS functions, make sure your GPS is performing well, and with ucenter you can see it with the deviation map. Otherwise with Harakiri it will try to follow your GPS only as well as it performs.

Crashpilot has VERY good default values in his firmware, so you should be able to get up in the air rather well. Hope it goes well for you.

I will set pedestrian. I think I set airborne 4g but as I think about it its not moving much in PH :-)

I would think airborne might be better for tracking position when flying FPV and not PH.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Apr 10, 2014 5:02 pm

Hi sorry for not commenting here yesterday.
The Github repo is here https://github.com/Crashpilot1000?tab=repositories and used just like a page to publish sourcecode without versioning. Private non profit project.
The ublox chart showing the different modes in comparison is shown in drv_gps.c.

Code: Select all

Ublox dynModel     Velocity m/s    Vertical Velocity m/s    Altitude m    Position Deviation
PORTABLE    = 0         310                50                 12000          Medium
STATIONARY  = 2          10                 6                  9000          Small
PEDESTRIAN  = 3          30                20                  9000          Small
AUTOMOTIVE  = 4          84                15                  6000          Medium
SEA         = 5          25                 5                   500          Medium
AIRBORNE_1G = 6         100               100                 50000          Large
AIRBORNE_2G = 7         250               100                 50000          Large
AIRBORNE_4G = 8         500               100                 50000          Large

So choose what you want but I would go for pedestrian. You will have to use gps_type = 4 ("GPS_UBLOX_DUMB") to avoid the code from altering your ucenter configuration (don't forget to ensure the correct baudrate settings ("gps_baudrate = X") as well since no autoconfiguration is active).
Cheers
Rob

subaru4wd · Post by **subaru4wd** » Thu Apr 10, 2014 6:00 pm

Rob, i have tried changing GPS_Type to 4 but i always get an error saying the max value is 3???

Crashpilot1000 · Post by **Crashpilot1000** » Thu Apr 10, 2014 7:45 pm

Why is it working here?

subaru4wd · Post by **subaru4wd** » Thu Apr 10, 2014 7:48 pm

Not sure. I am still on summergames 2.5, maybe thats it?

I recently switched to BaseFlight to get a OSD Switch. It too doesn't allow GPS_Type=4.

I have a new rig on the bench right now, i will flash SummerGames 2.5 & try to get it to take type=4, or is there some newer code I should be using?

strips · Post by **strips** » Thu Apr 10, 2014 8:54 pm

Crashpilot1000 wrote:So choose what you want but I would go for pedestrian. You will have to use gps_type = 4 ("GPS_UBLOX_DUMB") to avoid the code from altering your ucenter configuration (don't forget to ensure the correct baudrate settings ("gps_baudrate = X") as well since no autoconfiguration is active).
Cheers
Rob

Thanks

I had set it to the slowest Airborne 1g. Not 4g. Anyways I will try pedestrian.

So choosing gps_type = 1 will reconfigure the GPS? Do you know to what settings?

strips · Post by **strips** » Thu Apr 10, 2014 9:00 pm

subaru4wd wrote:Not sure. I am still on summergames 2.5, maybe thats it?

I recently switched to BaseFlight to get a OSD Switch. It too doesn't allow GPS_Type=4.

I have a new rig on the bench right now, i will flash SummerGames 2.5 & try to get it to take type=4, or is there some newer code I should be using?

TestCode3 in the following post is pre2.6 viewtopic.php?p=48650#p48650

Haven't tested gps type 4 myself yet.