Harakiri aka multiwii port to stm32

z01z · Post by **z01z** » Tue Sep 03, 2013 8:44 am

Rob,

It's this GUI by Carsten.

Zoltan

Crashpilot1000 · Post by **Crashpilot1000** » Tue Sep 03, 2013 11:58 am

I know.

cGiesen · Post by **cGiesen** » Tue Sep 03, 2013 12:53 pm

z01z wrote: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

The Basflight GUI show exact what is coming via MSP protocol nothing more.
But I stop support for Halakili.
And by the way, it's not closed source. Not every think that is NOT on github is closed source.
And I public the link to the code once.

Truglodite · Post by **Truglodite** » Tue Sep 03, 2013 5:16 pm

Hi Rob, yesterday I finally flew Summer Games 2.5 through a more complete test session. The everything worked perfectly, except when I switched on RTL it just PH'd for almost a minute. PH works as good as my AC3.1dev quad... very locked in even against wind. However it looked as if RTL was waiting for some special condition, instead of just climbing/returning/descending. AFAIK, all of my calibrations are done correctly and all my RTL parameters were default (except RTL min height changed to ~25m). Please advise if there are any pitfalls I may have missed.

On a side note, here is the latest video from my SG2.5 rig for you to enjoy:

Kevin

subaru4wd · Post by **subaru4wd** » Tue Sep 03, 2013 5:32 pm

cGiesen wrote:The Basflight GUI show exact what is coming via MSP protocol nothing more.
But I stop support for Halakili.
And by the way, it's not closed source. Not every think that is NOT on github is closed source.
And I public the link to the code once.

Why drop support for Harakiri??

Also, Rob... since I upgraded to SummerGames 2.5 my acc seems to be greatly improved! My auto-level has never worked so good, and always snaps back to the correct position.

Flight characteristics are superb. I am still having too much fun in Acro, and have not yet tested any GPS functions.

Here is video of me flying with Truglodite yesterday:

Crashpilot1000 · Post by **Crashpilot1000** » Wed Sep 04, 2013 12:49 pm

@Truglodite @subaru4wd: Thank you very much for the videos and feedback! Well after all the code has gone to places I will never be able to visit by myself

. I was very lazy at coding the last week so i did nothing special besides improving the gyro/acc/calibration routines since then (also using that mag - sphere algo I ripped off the original native 32bitpx4mu code - not the arducopterport). I have some reports, that the RTH casemachine stops and tries to loiter forever. Well I haven't looked into that already why the washing program stops without stepping further. It's probably because of the original spaghetti code design that I even worsened and my paranoia of flyaways (reset the gps chain if something seems odd - like dropping sat count, no valid data for 0.5 s etc.).
So whats planned for 2.6?
- find/reproduce/ eliminate that stopping RTH i.e reorganize GPS code (status: not done)
- use better acc/gyro calibr. offsets produced by the "sphere fit least squares" - magic (status: done), maybe introduce some optional temperature compensation for mpu Gyro & ACC (status: looked at code of baseflight plus)
- "copterwerkstatt" send in some code for Graupner SUMH (http://fpv-treff.de/viewtopic.php?f=18& ... 020#p44535) that will be implemented (I am using Frsky so I don't know if it is ok - but looks thought through and ok) (Status: almost done, i see some issues with feature lcd, like Spektrum it uses the gps serial port)
- RSSI readout of some Walkera DEVO mod FW with Deltang RX (don't ask me what that is... Bamfax knows it: http://fpv-community.de/showthread.php? ... post431907)
Greets
Rob

hinkel · Post by **hinkel** » Wed Sep 04, 2013 11:42 pm

Hi !
Harakiri Summer Games 2.5 Crashpilot1000 is a genius !
http://vimeo.com/73100707

mr.sneezy · Post by **mr.sneezy** » Sat Sep 07, 2013 3:02 pm

A hypothetical question about MultiWii Serial Protocol, FrSky telemetry protocol and Harakiri.

Is it possible to interleave MWSP and FrSky telemetry from the serial port on a Naze32 with Harakiri ?

The reason I ask is that I have added video with OSD to my quad, via a minimOSD board using the KV-OSD firmware on it. While the OSD works nice, I understand I would not be able to use my FrSky telemetry at the same time (I have not verified that yet) ?
Or is there a way ?

I guess baud rates might have to be matched, and the various protocols would need to be header aware at the very least ?

Cheers if anyone can answer some of this.
Martin

timecop · Post by **timecop** » Sat Sep 07, 2013 3:11 pm

I duno about harakiri, but this will be possible soon w/softserial implementation in baseflight.
Since FrSky is very low speed (9600 baud?) it will be easily handled by softserial transmit.
You will need an external inverter for frsky junk tho..

Plüschi · Post by **Plüschi** » Sat Sep 07, 2013 4:25 pm

If softserial is a bitbanging interface you wont need no real inverter. A soft-inverter will do

TC, if frsky is junk, and we both dislike spektrum, what do you consider good?

timecop · Post by **timecop** » Sun Sep 08, 2013 1:46 am

No, I meant junk as in their silly requirement for inverted faux-rs232 serial. when I asked them WHY would they do that, their reply was "back when we came up with idea of frsky telemetry, most PCs still had a serial port".... Other than that frsky is awesome

I dunno if software inversion will be enough, I thought their transistor-based inverter stuff will need more than 3V to switch but who knows.

mr.sneezy · Post by **mr.sneezy** » Sun Sep 08, 2013 2:39 am

timecop wrote:No, I meant junk as in their silly requirement for inverted faux-rs232 serial. when I asked them WHY would they do that, their reply was "back when we came up with idea of frsky telemetry, most PCs still had a serial port".... Other than that frsky is awesome

I dunno if software inversion will be enough, I thought their transistor-based inverter stuff will need more than 3V to switch but who knows.

I can confirm that software serial inversion works fine when direct connected into an FrSky receiver. I have two such devices running like that and into D8R-II receivers. They are both FrSky modified Open-Altimeters. The serial data is sent by the Atmel 328P MCU at 3.3V level on the Servo 2 pin.
http://www.rcgroups.com/forums/showpost ... count=1351
Orignal project here
http://openaltimeter.org/hardware.html

Martin

timecop · Post by **timecop** » Sun Sep 08, 2013 2:42 am

Well that makes it even easier then.

dominicclifton · Post by **dominicclifton** » Sun Sep 08, 2013 5:00 am

mr.sneezy wrote:
timecop wrote:I can confirm that software serial inversion works fine when direct connected into an FrSky receiver. I have two such devices running like that and into D8R-II receivers. They are both FrSky modified Open-Altimeters. The serial data is sent by the Atmel 328P MCU at 3.3V level on the Servo 2 pin.
Martin

just to be clear? have you tried the softserial code i've implemented in baseflight this weekend but with inversion enabled?

mr.sneezy · Post by **mr.sneezy** » Sun Sep 08, 2013 6:16 am

dominicclifton wrote:just to be clear? have you tried the softserial code i've implemented in baseflight this weekend but with inversion enabled?

I'm not sure if the question is for me. If so then no, I'm not aware of your code yet and I'm working on other projects right now anyway (FPV gear).
Regards, Martin

Gaijin · Post by **Gaijin** » Sun Sep 15, 2013 9:33 am

Hey crash pilot,

I wanted to say, SG 2.5, for me, it's practically perfect, it's never flown so well, congrats and thank you.

The only issue I've had, is after flashing with the sonar fix and using cgiesens base flight GUI is that I had to reset the carefree mode tick box and that function no longer seems to work, is it a version mismatch as it is not officially supported anymore?

Also do you still intend to support waypoints, its definately flying reliably enough now, or is there a lack of space?

Crashpilot1000 · Post by **Crashpilot1000** » Sun Sep 15, 2013 5:17 pm

@Gaijin: Thank you very much for your Feedback! I will check the headfreemode with your downloaded version. I always use the normal 2.1 gui but I doubt that the missing headfreefunction is a problem of the bfgui, but who knows, please recheck with the 2.1 gui as well. I improved acc and mag calibration further in the mean time (mag will calibrate as long as needed now 1-5 Minutes dynamically, old mag calibration obsolete and deleted). WP is def the next step but I am running in severe spacelimitations and some other things have to be done as well (autostart function, reorganize GPS code etc). I will probably have to ditch some drivers to make it fit.
Cheers
Rob

timecop · Post by **timecop** » Sun Sep 15, 2013 5:19 pm

Meanwhile latest baseflight builds to
Program Size: Code=45556 RO-data=7352 RW-data=1080 ZI-data=8072

Crashpilot1000 · Post by **Crashpilot1000** » Sun Sep 15, 2013 7:52 pm

@Gaijin: I rechecked the headfreefunction (indoor - rain outside) and it is working with the sonarfixed version you have. Hmmm...

Gaijin · Post by **Gaijin** » Mon Sep 16, 2013 7:44 am

Crashpilot, my mistake, I'm an idiot and had selected HeadAdj not headfree, It is in fact completely perfect!

I've just finished building a Quad controlled by an STM32F4 powered Openpilot Revolution I picked up from the kickstarter run and have posted in the developer forum promoting your achievements to them and suggesting you could share code and ideas, that is after all the great thing about opensource projects, co-operation

http://forums.openpilot.org/topic/33231-harakiri-and-baseflight-32-bit-multiwii-forkport/

TC, As always we are in your dept for this marvel of hardware design, now I know you've said before the naze board layout is pin compatible with the STM32F4, any chance you might produce a run of Super/Turbo Naze32's (reminds me of the TurboGrafX - 16 or SNES, maybe it needs to be called a Super Nazetendo?) I'm sure there's still plenty of scope in the current design but that extra headroom might be nice and hopefully it wouldn't be too tricky?

crazyal · Post by **crazyal** » Mon Sep 16, 2013 1:15 pm

dunno if that's still up to date.
but that's a coding fail:
https://github.com/Crashpilot1000/Summe ... /imu.c#L71
let's read gyro values AFTER we calculate attitude *facepalm*

Crashpilot1000 · Post by **Crashpilot1000** » Mon Sep 16, 2013 5:36 pm

@Gaijin: Thank you very much for your info about that headfree stuff, I was already scratching my head. Since I have no openpilot, I think that their hardware (you need SPI sensors) and software is way superior to what we have here - but how that translates to real life flight experience I dunno.

@crazyal: Yes, that is just left this way to keep the sequence of multiwii and actual baseflight(http://code.google.com/p/afrodevices/so ... 2&r=402#54). They process it exactly in that order - you are right, it seems weird to use gyrodata from previous cycle and not the actual one. I don't know the reason behind that. This codepart will be executed if no MPU6050 is present but you are right, I will change that order. Currently most rigs should work on the MpuSpecial Codepath that does the single shot readout suggested by Sebbi and so the processing with the more understandable order works well.
Thanks for looking at that horrible code

.
Cheers
Rob

crazyal · Post by **crazyal** » Mon Sep 16, 2013 5:49 pm

Crashpilot1000 wrote:@Gaijin: Thank you very much for your info about that headfree stuff, I was already scratching my head. Since I have no openpilot, I think that their hardware (you need SPI sensors) and software is way superior to what we have here - but how that translates to real life flight experience I dunno.

@crazyal: Yes, that is just left this way to keep the sequence of multiwii and actual baseflight(http://code.google.com/p/afrodevices/so ... 2&r=402#54). They process it exactly in that order - you are right, it seems weird to use gyrodata from previous cycle and not the actual one. I don't know the reason behind that. This codepart will be executed if no MPU6050 is present but you are right, I will change that order. Currently most rigs should work on the MpuSpecial Codepath that does the single shot readout suggested by Sebbi and so the processing with the more understandable order works well.
Thanks for looking at that horrible code .
Cheers
Rob

imho there is no reason behind that. It just "works".
I'm redoing that part of baseflight atm, if I don't mess it up and dongs likes and if it flies well. you'll see a change to baseflight in that regard soon.

copterrichie · Post by **copterrichie** » Mon Sep 16, 2013 5:50 pm

Rod,

I have one of TC's Afroflight boards with the ITG3250 and ADXL345 (never did like this ACC). It has been a very long time since I looked at any of these 32bit coding. Question, is the mixing table easy accessible where I can write a custom mix if I decide to use this board again?

Crashpilot1000 · Post by **Crashpilot1000** » Mon Sep 16, 2013 6:32 pm

@Crazyal: I've seen your work and I am very happy to see progress in that area, that is desperately needed. I can only try out stuff and fiddle around, but your approach seems to be more promising! The unfu***** sensor initative is also very good.

@Copterrichie: I would def. rcommend the original BF software for your hardware. The mixer is accessible in the cli but I never used that... You can access the internal mixers here as well: http://code.google.com/p/afrodevices/so ... rc/mixer.c
If you already know what mixer you need it may be reasonable to change it here and recompile - that would save you from cli headache.
Cheers Rob

copterrichie · Post by **copterrichie** » Mon Sep 16, 2013 6:58 pm

Thanks Rob, so that I am clear, the Harakiri will not run on this hardware?

Crashpilot1000 · Post by **Crashpilot1000** » Mon Sep 16, 2013 7:12 pm

Well, I can not comment on hardwarefunction I don't have. So I would go for the official BF in the first place, you can handtest Harakiri as well of course...

copterrichie · Post by **copterrichie** » Mon Sep 16, 2013 7:39 pm

Thanks Rob.

brm · Post by **brm** » Mon Sep 16, 2013 9:42 pm

crazyal wrote:dunno if that's still up to date.
but that's a coding fail:
https://github.com/Crashpilot1000/Summe ... /imu.c#L71
let's read gyro values AFTER we calculate attitude *facepalm*

this is the famous mw sampling of data.
deleting is the best what you can do.

crazyal · Post by **crazyal** » Mon Sep 16, 2013 10:00 pm

that's what I did, makes no difference as far as I can tell.
here are my latest changes: https://github.com/luggi/baseflight/commits/mag

timecop · Post by **timecop** » Tue Sep 17, 2013 2:08 am

copterrichie wrote:Rod,

I have one of TC's Afroflight boards with the ITG3250 and ADXL345 (never did like this ACC). It has been a very long time since I looked at any of these 32bit coding. Question, is the mixing table easy accessible where I can write a custom mix if I decide to use this board again?

I actually just tested latest baseflight commits (after proper sensor reorientation) on freeflight as well as rev0 with adxl and mpu3050 - it does work just fine.

As for custom mix, motor-only based custom mixes are set in cli, using the 'cmix' stuff I believe.
there's no provision for servos in that mix at all, so if you want a servo-based mix you will probably need to modify one of the standard tri/bi setups in code and rebuild.

copterrichie · Post by **copterrichie** » Tue Sep 17, 2013 2:12 am

Thank you TC and honestly, that is a great response. Appreciate it!!!

hinkel · Post by **hinkel** » Wed Sep 25, 2013 6:14 pm

Hi Crashpilot1000 !
Is there a little bug in SG2.5 by Failsave just PH =1 ? if I cut the Radio signal the Kopter lose on Hight if Baro mode was not
actived befor,(just test in 2 meter hight ) with baro mode Actived befor it is OK, autoland etc..... I think this could be eventually normal, software delay to switch the Baro mode bei failsave ?
Excuse my bad English !

Gruss

Crashpilot1000 · Post by **Crashpilot1000** » Thu Sep 26, 2013 1:42 am

Hi, Hinkel!
Thanks for the report and having the guts to test that out! I think there can be done something about that.
What happened:
1: Flight in some non Althold/baromode
2: Turning off the transmitter, normally RX will not immediately quit sending signals to FC (some rx internal timeout).
3: failsafeCnt is being increased without reset by good RC signals (here https://github.com/Crashpilot1000/Summe ... /mw.c#L791)
- after 1 second (failsafe_delay = 10 https://github.com/Crashpilot1000/Summe ... /mw.c#L718) the failsave is engaged and althold is activated (https://github.com/Crashpilot1000/Summe ... /mw.c#L734).
4: So althold is started with the current throttle here: https://github.com/Crashpilot1000/Summe ... /mw.c#L919. At that moment your throttle will be something like 1150 or so (minthrottle). So not a sufficient baselinethrottle is applied in the first place and the copter will keep falling. Then the althold controller will see a big error and adjust the baselinethrottle here (https://github.com/Crashpilot1000/Summe ... mw.c#L1171). The "landing anti hopping algo" will also interfere if the throttleadjustment is not sufficiently done within 2 seconds, damn.

So basically the stuff goes wrong with insufficient throttle assumption on althold engagement (+1s delay of FS detection + internal RX delay). I see 2 ways to get around that.
Check throttle on Fs engagement if it seems too low (like minthrottle + 5%).
1: Take the predefined failsafe_throttle in that case.
2: Gather some mean throttlevalue during flight and use that. I think that would be the best way.
In the upcoming 2.6 there will be some motorstatistics (hopefully of some use to find out if some motors are stressed more than others on asymetric/load unbalanced copters) gathered anyway so theses data could be used, if the copter experienced at least a few seconds of flight before facing a failsave situation.

So, Hinkel thanks a lot for your input!! - Let's make things better

.

Cheers
Kraut Rob

hinkel · Post by **hinkel** » Thu Sep 26, 2013 5:13 pm

Hi Crashpilot1000!
Thanks for your help, I follow your advice and
set failsafe_throttle from 1200 up to 1350 then 1450 and at the end to 1550
but always the same default kopter is Falling by failsafe activity it seems he set the throttle value to 1100 1200 ( my kopter hover by 1400 1450 throttle value and by 1550 he go to the sky ).
I don't remember having this Problem by older Harakiri Code and failsafe_throttle was always 1200.

Test Values:

Harakiri SG 2.5
Source081513-2215Uhr

failsafe_delay = 10
failsafe_off_delay = 200
failsafe_throttle = 1550
failsafe_deadpilot = 0
failsafe_justph = 1
failsafe_ignoreSNR = 1

Gruss

Crashpilot1000 · Post by **Crashpilot1000** » Thu Sep 26, 2013 7:24 pm

Hi, Hinkel!
Sorry for the misunderstanding!
If your copter is equipped with a baro (no matter if activated or not) the failsafe_throttle is ignored. It worked with older versions because they had no "debounce function" for landing. The debouncer will limit the maximal thrust during landing according to the hoverthrottle (gathered over 2 seconds). If that value is too low (that should be the case here), it will "land/drop/crash" with that value with a +5% margin. You would need a margin of 100% or so for al_debounce, wich is unfortunately limited to maximal 20 % in the cli. But you can disable that with zero so changing that could solve the problem (like set al_debounce = 0). I am currently re-doing / fixing that and some other stuff... . So please Hinkel don't endanger your copter any further. If your RX allows it set an appropiate FS setting there for now. Sorry for that bug, hopefully no broken stuff! Haven't been visiting the german forum for quiet a while on purpose because I have some private stuff at the moment (and a funeral) and will hopefully gather up myself and read the recent posts and post some info there as well concerning fs and the plan for upcoming versions.

Cheers Rob

hinkel · Post by **hinkel** » Fri Sep 27, 2013 3:42 pm

Crashpilot,

I am sorry about what arrives at you and your family, my condolences.

Gruss

Truglodite · Post by **Truglodite** » Fri Sep 27, 2013 8:27 pm

Rob I'm very sorry to hear about your loss. My prayers are with you and your family.

Nice find Gruss and Rob. I like the motor statistics method that can compensate for varying pack voltage. I have some reading to catch up on regarding debounce margins; I understand the trouble with and the cause of the 2sec lag, but I don't understand how debounce adds to the problem. I assumed debounce would compare alt predictions with the baro, and kill throttle increase after the baro diverges high for 1-2sec. I figured if the baro went low, then we have uncontrolled descent rate, and debounce is becomes relevant (maybe disable debounce after 1sec of low baro... hopefully won't yoyo in the ground effect).

Truglodite · Post by **Truglodite** » Tue Oct 01, 2013 3:53 am

I use 433 controls, and wanted to compile and test Harakiri sg2.5 with the chatch patch. My hope is to minimize interference. After reading this:
viewtopic.php?f=23&t=1947&start=510

and this:
http://fpvlab.com/forums/showthread.php ... ame/page29

I wonder exactly what to change in the code. TC mentions a line in dev_system, but searching for it I only found a match to those lines quoted from chatch, in the file:
/Harakiri_sg_2_5/lib/CMSIS/CM3/DeviceSupport/ST/STM32F10x/system_stm32f10x.c

Lines 189-191 match exactly:
/* PLL configuration: PLLCLK = HSE * 9 = 72 MHz */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL));
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL9);

I changed line 191 to this and it compiled fine:
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL10);

I want to try this out, but thought to ask the experts first in case that could brick my board.

Any help is appreciated, Thanks
Kev

[edit: I already answered my questions... my rig is flying happily at 80mhz now.

]

hinkel · Post by **hinkel** » Tue Oct 01, 2013 5:21 pm

hinkel wrote:Hi Crashpilot1000 !
Is there a little bug in SG2.5 by Failsave just PH =1 ? if I cut the Radio signal the Kopter lose on Hight if Baro mode was not
actived befor,(just test in 2 meter hight ) with baro mode Actived befor it is OK, autoland etc..... I think this could be eventually normal, software delay to switch the Baro mode bei failsave ?
Excuse my bad English !

Gruss

Hi Crashpilot1000 an all Harakiri SG2.5 Friends !

There is no Bug in Failsafe Code SG 2.5 , the Problem came from my Receiver there was a failsafe enable ( completely forget that I change the receiver some weeks ago ) :roll:

.
Now Failsafe works great as expected ! :mrgreen:

Regards

Crashpilot1000 · Post by **Crashpilot1000** » Fri Oct 04, 2013 9:51 am

@Hinkel @Truglodite: Thanks for the condolences, unfortunately the lightning struck twice in one week... But I am back on track!
@Hinkel: I am glad to hear that this was mainly due to a setting done by your tx, so the althold gathers up the needed throttle fast enough. Anyhow I rearranged the FS stuff and the initial throttle generation. The initial throttle is generated now with that logic:
1: Look up the history of the flight and try to get an average throttle from that
2: If that fails (average throttle < 5% of throttlerange) take the predefined fs_rcthr(varaiable name changed from failsafe_throttle)
as baselinethrottle for first Althold/hover. Althold will start adjusting it anyway, just to get a better initial value. (You can check out the details on github crashpilot1000 and the current untested version..)

@Turglodite: Yes the debounce function during autoland relies on the hoverthrottle, that is gathered during 2 seconds.
I can not help you with that low level frequency stuff because I have no concrete idea of that and no interest in digging into that right now. I've seen that there are some changes in the original BF so I think it's best to ask there.

Cheers
Rob

scrat · Post by **scrat** » Fri Oct 04, 2013 5:20 pm

Crashpilot1000 wrote:@Hinkel @Truglodite: Thanks for the condolences, unfortunately the lightning struck twice in one week... But I am back on track!

Cheers
Rob

theailer · Post by **theailer** » Sat Oct 05, 2013 9:49 pm

1st post

I have summer games 2.5 on my naze32 with a gps. The naze blinks red confirming satellite lock but no GPS data in the various guis. Should it be this way or am I missing something?

subaru4wd · Post by **subaru4wd** » Sat Oct 05, 2013 10:40 pm

theailer wrote:1st post I have summer games 2.5 on my naze32 with a gps. The naze blinks red confirming satellite lock but no GPS data in the various guis. Should it be this way or am I missing something?

Which GPS receiver are you using? The GUI should show the # of sat's and its Lat/Long info.

theailer · Post by **theailer** » Sat Oct 05, 2013 11:21 pm

This one
http://www.goodluckbuy.com/ublox-high-p ... ntrol.html

subaru4wd · Post by **subaru4wd** » Sun Oct 06, 2013 12:04 am

I think you need to use a FTDI adapter, connect to the GPS using the u-center software and change the baud rate to 115k if not done-so already.

theailer · Post by **theailer** » Sun Oct 06, 2013 12:16 am

Thanks. I've ordered an adapter but it haven't arrived yet.

timecop · Post by **timecop** » Sun Oct 06, 2013 4:26 am

in baseflight, gps baud can be configured. no idea if this "feature" was "removed" from harakiri.

subaru4wd · Post by **subaru4wd** » Sun Oct 06, 2013 5:33 am

timecop wrote:in baseflight, gps baud can be configured. no idea if this "feature" was "removed" from harakiri.

Im not sure. Im sure Rob will have alot more on the subject when he checks the thread.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Oct 06, 2013 7:44 am

Hi!
Well, the gps .... oh, boy.
First of all there are a lot of changes in that area and the functionality is not truncated in Harakiri. My used ublox is: GPS-NL-652ETTL with a self build alu-backplate connected to GND and the Dataline has a ferrite.
The instructions here http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20580 (look in the GPS chapter) are still valid. I think my ublox has still the arducopter config file in it's brain. The link has been moved by the apm guys: http://code.google.com/p/ardupilot-mega ... Plane-2.50. I also tried GinJeis zip and that works as well. The baudrates can still be set with "set gps_baudrate = x".
To get a connection to ucenter (to load a configfile etc) the best way is to use an FTDI adaptor but I also did a dumb passthrough for the naze. Go to cli and type "passgps" you will be confronted with a simple menue because a parameter is expected to set the correct baudrate/gps. Passgps has some downsides: 1.: It's basically a crude endless loop exchanging serial bytes between naze usb and the gps serial port. It may loose a byte but that is not a problem because the transmission between ucenter and gps is checksummed. If an error occurs the datapackage will be resent by the application without bothering the user. You can only exit that by typing in 5 times "#" in the serial monitor, or unpower the naze. So when you are done with ucenter and the config is saved to your gps, powercycle the naze.
2.:The baudrates are not watched and the serial speed is not adjusted when the application switches baudrate. Example: You start "passgps 4" (ublox 38Kbaud), exit your favourite terminal program and fire up ucenter. You can connect with ucenter at 38K and everything is fine. You can load up the arducopter config file and save it to ublox eeprom with no problem because that config file will be parsed and executed by your gps while uploading and the preset Baudrate of that file is 38K (like your naze and your ucenter is already on). If you try to upload a config file that presets 115K, that must fail, because it will set the GPS to 115K during upload and the naze will keep doing 38K - connection lost (repower naze). In that case "passgps 2" (force ublox to 115k for that session) would have done the trick. So an ftdi is easier (i think the windows driver will adjust baudrate between the application and ftdi?) but you will def. get the job done with "passgps" for $0. If you suddenly loose ucenter connection to the gps you 100% screwed up the baudrate, in that case repower naze & gps and start again (with a better baud preselection). EDIT: You can not wreck the gps with config file "uploadus interruptus..."
The passgps baudrates are only for that session. In normal operation with "set gps_type = 1" the ublox will be forced/overwritten to "gps_baudrate = 115200 (default)" no matter what the previously saved ublox config suggests. If using "set gps_type = 4" the ublox configuration is untouched by naze so you will have to set a correct "gps_baudrate = x" according to your ucenter configurations.
The basic usage of ucenter is described here: http://code.google.com/p/ardupirates/wi ... PSTutorial.
I hope it's somehow understandable...
Cheers
Rob

EDIT: P.s.: I know the documentation of each parameter is outdated. I don't know when I will come to that. For now you can look in config.c and find most parameters described: https://github.com/Crashpilot1000/Summe ... fig.c#L166