Harakiri aka multiwii port to stm32

alistairr · Post by **alistairr** » Thu Dec 05, 2013 1:03 pm

Gps is not very Useful at 1200m underground lol

PacciK · Post by **PacciK** » Thu Dec 05, 2013 3:32 pm

Rob..Thanks for that explanation. Really helping me understand what is going on.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 05, 2013 11:47 pm

@alistairr: Oh, well 1200m beyond the earth level.... well I don't know what you might expect there for airpressure or other physical conditions.
But using a baro should be no problem there either, as long as you fly in stable (airpressure) conditions so a relative hightchange (airpressurechange) can be recognized. I guess you have some ventilation there to keep you alive - but that's a (hopefully) steady airflow that will be zeroed upon initialization. So maybe the change of shifts, where everybody is using the elevator (or whatever transportation device is used), might be the wrong choice of flighttime. Besides that, if gravity is an issue there concerning self leveling - unwillinglingly (for your submerged condition) the pre2.6 has a dynamic handling of gravity. So if you see there is a problem, just recalibrate the acc with stick command or gui. The copter should stand *somehow* level during that. I don't know if you know the movie Aliens/Prometheus but those CGI drones/laserballs are really cool - and would be very easy to bring to reality just with sonar sensors - besides the obvious drawback of the powersupply. I don't know how big your tunnels are in diameter but a self centering drone within walls of 3 or 4 m range on each side (radius) is no problem.... with 4 sonar sensors and 2 week development time.
@PacciK @alistairr: I am very happy that something of the previous post cleared something up, but after all it's just logical. If you imagine being the copter with no eyes and just the current sensorset (gyro/acc/mag/baro/gps/sonar) and want to achieve something (like autolanding, autostarting, rth etc)... many questions will answer itself if you think it through considering the limitations of each sensor and how they could work together. Ships and U - boats can have much greater time of just navigating by gyro and accelerometer data since they are moving slowly, have no space constrains (using laser gyros etc) and vibration can be eliminated completely. Multirotors have cheap, lightweight sensors in shaky conditions ...

rank · Post by **rank** » Fri Dec 06, 2013 5:45 pm

Hi guys, my first post and straight to the question.
Trying to make the telemetry function to work, but with no success. Here's what I have done.
Receiver Frsky D4r-II connected to naza 32 as per picture.
The battery pin on naza connected to the distribution board and the voltage is displayed properly within GUI
In CLI done: "set tele_prot = 1", saved.
In Taranis, I've choosen FAS as voltage source.
But I get no data on the telemetry screen, apart from the receiver's own RSSI A1 A2. FAS voltage is showing 0
I'm I doing something wrong?!

alistairr · Post by **alistairr** » Sun Dec 08, 2013 9:33 am

Thanks Rob again. I did a lengthy reply to your last post but it looks like I lost it somewhere between here and the forum. I'm interested in your multiple sonar setup you mentioned. would it be possible to run 5 or 6 to include above and below. I might just use feelers (carbon rods) for clearance above. Above all it will be a very stable (not acrobatic lol) quad with multiple cameras and possibly 2 different video frequencies to have a second person operate the cameras. Be keen to keep the cost fairly low as the chance of it not coming back is always there....but that is often the case with FPV lol. I'll PM you about the sonar set up.
Thanks again
Alistair

I'll try the telemetry thing soon too. Let us know if you find a solution rank. Could possibly be a Taranis setting issue too?

frog32 · Post by **frog32** » Mon Dec 09, 2013 6:38 pm

I have two questions about harakiri:

- is there a repo available to be able to track the changes? preferably git but i am also happy with everything which is able to show the actual progress.
- what are the differences between harakiri and baseflight? i would be happy to look this uf in a repo myself but to diff two entire projects is a lot of work

thank you for your help

rank · Post by **rank** » Mon Dec 09, 2013 7:03 pm

Is there anyone flying harakiri pre 2.6 with all the gps features working as they should? I mean without flyaways, abnormal behavior etc?!

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 10, 2013 12:05 am

@frog: I have no versioning. But you can always read the readme and use a diff program (like csdiff). There are a lot of differences. I was suprised to suddenly see a gps passthrough in baseflight.
@rank: Weather keeps me grounded for further GPS testing but no, not everything is ironed out in PRE 2.6. The not autolanding on rtl was probably a not centered throttlestick. I am currently working on blocking stickinput during automodes (like Yawstick or throttlestick - when taken over by navcode. Ail/ele will always override and stop an automission - besides the obvious switch that turned on that mode..). If you properly setup the mag and gps you will have a hard time to produce a flyaway on rtl because there is also a parameter (gps_rtl_flyaway = x, x in meter, 0 disables). If that's activated (like "30" meters) the distance to home on rtl start will be set. If the distance increases (instead of decreasing) during RTL beyond this value it will disable GPS function and assume a severe error (mag, half prop gone and copter spinning, wind etc...) and do an baro guided autoland (with no additional drift due to wacky gps). NazeV5 guys should go for BF. I am unsure if it's a good idea to waste further time on V5 compatibility. The additional eeprom is not needed for wp stuff since you can store >100 of them without it.

rank · Post by **rank** » Tue Dec 10, 2013 12:55 am

Thanks, I'm on V5, actually have 2 of them. So really hope you won't give up on us. I'm sure V5 will dominate naze32 world shortly.

timecop · Post by **timecop** » Tue Dec 10, 2013 3:32 am

Crashpilot1000 wrote:@frog: But you can always read the readme and use a diff program (like csdiff).
...
I am unsure if it's a good idea to waste further time on V5 compatibility.

He specifically stated he's not interested in wasting time trying to diff shit. I don't blame him, either. Trying to diff stuff which has no indentation/consistent coding style is nearly impossible.

What "compatibility"? It has 12MHz xtal and inverted buzzer, both totally irrelevant if you'd keep using updated drivers instead of some 1+ years old stale shit. Or even better, if you wrote actual original code with proper style and submitted patches that aren't hacks on top of hacks, at least some of the shit would have been in baseflight by now.

scrat · Post by **scrat** » Tue Dec 10, 2013 8:15 am

C'mon man. Why is rev5 such a PITA for you? If it's working for rev4 why can't this work for rev5? Rev5 is the future now

timecop · Post by **timecop** » Tue Dec 10, 2013 10:28 am

There's nothing to fix. Nothing that would matter for any of his code has been changed.

subaru4wd · Post by **subaru4wd** » Tue Dec 10, 2013 5:04 pm

timecop wrote:There's nothing to fix. Nothing that would matter for any of his code has been changed.

Then why wont his code work on Rev5?

bicycle · Post by **bicycle** » Tue Dec 10, 2013 5:10 pm

Because the code is broken. Baseflight works fine on rev5.

cGiesen · Post by **cGiesen** » Tue Dec 10, 2013 5:40 pm

AAAH,
Baseflight and Buzzer on rev5 work from the beginning....
Because of better coder....
viewtopic.php?f=22&t=2387&p=42845&hilit=naze32+buzzer#p42845

hinkel · Post by **hinkel** » Wed Dec 11, 2013 9:24 am

Naze32 rev4 Harakiri SG2.5 with KVTeamOSD R370 flight test :
* VBAT
* PH
* RTH
* OSD SW
* FAILSAFE ( Transmitter shut down for test, failsafe_justph = 1; // Does just PH&Autoland an not RTL, use this in difficult areas with many obstacles to avoid RTL crash into something )

If wanted, FAILSAFE info for OSD !

PacciK · Post by **PacciK** » Sat Dec 28, 2013 8:01 pm

Perhaps you remember my previous posts when flying Harakiri and something causing the copter to Flip and Crash ( better described as SMACK ) on the ground......back on page 42 of this very thread.

Well it happened again on another different copter with totally new hardware and electronics...not using Harakiri, but the default Firmware that came with the Pink board from TC.
I posted my issue here.... 3rd post in this link http://www.rcgroups.com/forums/showthread.php?t=1653753&page=59

Reiterating my question .... Anyone using a PPM_SUM RX successfully with GPS functions ??
I am sure the main loop froze.
The copter smacked the ground inverted, props spinning and grinding on the ground until I managed to remove the battery.
None of the 3 props are broken....but they will be trashed ( of course ).

please help!!!!

scrat · Post by **scrat** » Sat Dec 28, 2013 8:25 pm

If you have FrSky Tx/Rx. I hope you have flashed your FrSky Rx with 27ms firmware? If not what happened to you can happen. FrSky protocol have just 18ms between frames. when you use PPM SUM or CPPM etc,...please read this.

http://diydrones.com/profiles/blogs/why ... appointing

http://diydrones.com/profiles/blogs/frs ... -ftdi-cabl

http://www.rcgroups.com/forums/showthread.php?t=1906748

Crashpilot1000 · Post by **Crashpilot1000** » Sat Dec 28, 2013 10:15 pm

Give me a bigger pic (atom level!) of the scrapped prop - that makes things MUCH easier! - Just joking here with my dirty humor.
Well, I am using frsky equipment at PPM all the time with no problem (+GPS - ublox), even without the 27ms FW. WIth the "normal" frsky FW you could produce problems if maxing out several channels at once - like full throtte + full yaw + full nick + full roll + some switches maxed - so that may happen but is unlikely.
I also had sudden crashes that could be tracked down to one faulty ESC that decided after a certain time to say good bye. Seems not likely since you have that on two different/hardware copters?
If your copter oscillates itself to death your pids are too high or your filters/complementary filters are not adaequate for your vibration amount/copter.
I currently observed some problems with Aux1 double/tripple setting with my current code (with gps ph on aux1 + althold on aux 1 + angle mode could *somehow* result in minthrottle with sustained leveling - so it did an absolutely horizontal bumb - no flip - into the grass from *thankfully* low hight) that I saw today and I am currently looking into that including some other stuff I want to iron out.
Sorry that I can not be of more assistance with your actual problem. BTW: RCG mentiones a tricopter - that's hardware I can not test. BTW: I never test horizon mode very much - is it a horizon problem?
I am just a stupid fu*k that just mindlessly copies stuff without a single own inspiration and just doing horrible code with absolutely wrong indentation. No joke, I sincerely think TC should look into your problem in the first place since it happens on his hardware and his software and you paid him.
Nonetheless I am happy that you ask here (since I do not know about that RCG thread until now) and maybe we can solve/reproduce that issue.
I think some questions/informations (besides your big picture) may be helpful:
Is the faceplant associated with another strong RF source on your copter? (Video TX, telemetry, microwave oven etc..)
Is that problem reproducible (flightmode dependent, in hand test)?
Does the FC really lock up? - In hand test with usb attached and gui running - sudden cycletime freeze.
If not answered before - how may I reproduce the problem (so that I get a chance to solve it)?

Cheers Rob

PacciK · Post by **PacciK** » Sat Dec 28, 2013 11:02 pm

Thanks for your input, Scrat. I did know about the FrSky issue, but its not affecting me since I use JETI Duplex system on a Futaba T9CP radio, with 8 channels enabled.

Since my post,I have replaced the props, and went out again this evening and had two uneventful 'flights'.
Flight one Handholding the copter very firmly and wondering around the GPS position hold and observing what the copter does to remain in hold.
The Naze didn't lock, and I had full control from the TX for the whole handheld 'flight' approx 20 minutes ( until I got bored )...

Then I had another flight...on its own this time, and again.... no lock-ups....
And from this flight ( the first one on GPS hold ), I understand that I need to advance the POSR pids higher than the default.

Now that I came in again, I see your post. Thankyou !

The Output from the RMK2 receiver had been previously set to 25ms repeat rate. I have now increased it to 30ms from the jetibox. This is the slowest the Jeti RX allows.
The frame rate is solid, and repeatable, because it is re-computed on the RX side ( my choice ..because i I leave it as the Futaba outputs it, the repeat rate is varying randomly )
The Jeti is a very solid, user friendly system.

Still I cannot understand why the crash from this afternoon happened.

PacciK · Post by **PacciK** » Sat Dec 28, 2013 11:21 pm

Hi Rob, Thanks for chiming in. Even though this is not Harakiri on my pink Board.

There are no other TX sources other than an HC-06 BT adapter on the other side of the RMK2 JEti RX.
The Jeti TX module is run ( illegally ) at 100mW, so I am 101% sure there is no Radio lockout.
This is a test machine, which I am using as a confidence builder for Naze32 with GPS. I know Acro and normal flight are a piece of cake for the Naze 32 with Baseflight.
But the aim is to have a nicely functioning PH and RTH.

Is that problem reproducible (flightmode dependent, in hand test)?

I have done the hand test for 20 mins ( as per above post ), and that gave me 10% confidence to try again for a second battery... this time... flying.
During the handheld flight, GPS satellites were always above 9, and I had my phone communicating through BT to the Naze.
In certain pages, I could FEEL the copter twitching, but stop when I go to the PID's page on my phone.
I was presuming that this twitching was being caused by the telemetry connection from naze to my board ( at 115k2 on the BT ).
The board did not hang up, even with this ''overhead''?? on the comms.

If your copter oscillates itself to death your pids are too high or your filters/complementary filters are not adaequate for your vibration amount/copter.

Nope.... the CF props are amazing. It is buttersmooth. Bestest machine so far. Accel Graphs remain really nice in hover.
PIDs are OK. Wish I had more D-term, because the copter did not oscillate with full D.... the low KV motors and large props do not let it oscillate.
However, still.....I do not have the PIDS up high...pretty conservative..no chance of oscillation.
I even tried to remove the LPF 42 ( to 256 ) on the Gyro, and it still didn't oscillate. ( I returned it to 42 again afterwards ).

So... let's see....I'll have a few more goes with the newly lengthened 30ms PPM_SUM framerate, and we'll see how the 10% confidence grows.

Cheers....and all the very best for 2014.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Dec 29, 2013 1:42 am

I have no Jeti or BT or Dataradio attached to my copter - but I don't think thats the problem source. Sounds more like a hardwarefailure of some kind.
Concerning ppm frame length: https://github.com/multiwii/baseflight/ ... pwm.c#L242
2.7ms is limit.

alistairr · Post by **alistairr** » Sun Dec 29, 2013 2:21 pm

I belive I have had interference from a blue tooth tx. The quad would twitch about every second and it was more noticeable when the blue tooth was sitting near one of the esc signal wires. It never flipped upside down, but I removed the bt and the problem went away. Might not be of any help.

IceWind · Post by **IceWind** » Sun Dec 29, 2013 8:17 pm

Tested today the RTH & AutoLand feature. All perfect out of the box.
The RTH speed is a bit slow but all worked perfectly including the autoland that was a nice surprise to see it land on it's own and stop the motors afterwards. 8-)

subaru4wd · Post by **subaru4wd** » Sun Dec 29, 2013 8:49 pm

IceWind wrote:Tested today the RTH & AutoLand feature. All perfect out of the box.
The RTH speed is a bit slow but all worked perfectly including the autoland that was a nice surprise to see it land on it's own and stop the motors afterwards.

Is this on Harakiri 2.5?

alistairr · Post by **alistairr** » Sun Dec 29, 2013 10:10 pm

Rev 4 or Rev 5 hardware?

IceWind · Post by **IceWind** » Sun Dec 29, 2013 11:23 pm

subaru4wd wrote:
IceWind wrote:Tested today the RTH & AutoLand feature. All perfect out of the box.
The RTH speed is a bit slow but all worked perfectly including the autoland that was a nice surprise to see it land on it's own and stop the motors afterwards.

Is this on Harakiri 2.5?

Probably 2.4, I'll check.

PacciK · Post by **PacciK** » Tue Dec 31, 2013 12:05 pm

Alistairr: nope...its not the BT module. No twitching is observable. and the module is about 10cm away...and on low power.

So....I changed the Receiver to a Turnigy 9x stock receiver, and connected the RX with normal PPM on 6 channels ( AETR+aux1+aux2 )
3 flights of configuring GPS hold, and no flipping or ''FacePlants''.
But the GPS hold on the current Beseflight is not giving me joy.

So I put on SummerGames 2.6 ( because I really like the altitude hold ( very Naza like...) and wanted to try the GPS hold.
And what do you know....30 seconds after observing its mild corrections on GPS hold.....SMACKK!!!!! a flip to the RIGHT and faceplant to ground.
No damage apart from a broken prop.
Changed it, rebalanced, and went out for another flight, this time with video camera.
And again...about 1 minute into GPS hold ( with the stock GPS settings on SG2.6 that are nicer than stock baseflight )....
SMACKKK.....but this time...bent frames, smashed props, etc....

Went to see the video in hope of being able to post it here...but the action was completely out of frame ( novice at capturing myself flying ....)

So.... I'm now lost.
Probably will end up trashing the whole lot because I am now fed up of loosing time, and dosh. ( Angry rant = over......)
EDIT ( 15mins later) ::::: No...I won't trash it, as Naze32 is such a nice little board for small FPV quad to play with......
Pity No GPS play for me though !!!!!

Wish you all a fantastic 2014, guys !!

timecop · Post by **timecop** » Tue Dec 31, 2013 2:25 pm

Better upgrade to DJI shit asap if you like "naza - like althold"

IceWind · Post by **IceWind** » Tue Dec 31, 2013 3:30 pm

IceWind wrote:
subaru4wd wrote:
IceWind wrote:Tested today the RTH & AutoLand feature. All perfect out of the box.
The RTH speed is a bit slow but all worked perfectly including the autoland that was a nice surprise to see it land on it's own and stop the motors afterwards.

Is this on Harakiri 2.5?

Probably 2.4, I'll check.

Here's the video of the RTH and Autoland working.
http://www.youtube.com/watch?v=dWzz1i_rC2g
(The black vertical bars I believe is from the props causing shadow in the video.)

For it to be perfect It return speed should be a tad faster, this was the second try as on the first it took so long the quad was running on fumes
and I had to abort and bring it faster before it would fall due to lack of power.

Fun fact: All in there have Naze32 FC's and they can blame me.

PacciK · Post by **PacciK** » Tue Dec 31, 2013 3:55 pm

Hi TC......

because I really like the altitude hold ( very Naza like...)

Ha !! That was your bait.....to see if you would chime in !!!!

Do YOU have any clue / indication as to why the Faceplant happened to my copter when I was using Baseflight firmware and PPMsum ( as from my previous post asking for help/ideas ?)
At that time , PPM_SUM framerate was 27ms ( No Chance of any main loop time bottleneck issues, no chance of PPM_SUM corrupting, as even under full open channels condition, the trigger pulse is waayyyyy longer than 2.7ms or 2700 !! ). GPS is UBLOX ( which the firmware configures to its liking.....and the BT module was switched off for flying this faceplant GPS_PH. )

BTW.... BUT... There's no doubt, IMHO, that Naza Althold ... ( as well as Ardupilot althold and also Summergames ) are how one comes to expect Althold to work.
C'mon.....

timecop · Post by **timecop** » Tue Dec 31, 2013 4:21 pm

are how one comes to expect Althold to work

sorry, no.
althold works by setting a switch, and it stays there.
vario shit that was forced on retards by DJI will never be in baseflight.

and I have no idea about your faceplant. I've been using PPM for years with zero issues. I don't even bother with this 27ms frame shit because unlike all the hype/whiners claim, chances of the pulses overrunning 18ms are practically zero, you'd have to have first 4 control sticks in such fucktarded positions that you wouldn't be flying at that point anyway, AND all 4 aux switches at max. Likelihood of this happening is similar to Crashpilot1000 starting to use source control properly.

PacciK · Post by **PacciK** » Tue Dec 31, 2013 4:34 pm

Of course.... Sticks are not being held ( ie.. were at centre ) when I was attempting GPS PH.
I wouldn't be crying here if I induced the Faceplant intentionally !!!

From the 'TC style' you write ( which I enjoy BTW...), I am assuming that on your test copter, you have a solid GPS hold / RTH, and also a very solid Althold.... especially with latest Baseflight firmware.
Presuming also that this copter has PPM SUM input ( many years).

Hmmmm..... Somehow this is a bit too salty to swallow.

IceWind · Post by **IceWind** » Tue Dec 31, 2013 4:35 pm

Geee someone is in a bad mood today.

A bit related to the PPM input, one of the guys I was flying with has a Graupner radio, for sometime he was having twitches and problems like the quad flipping for no reason.
Up until he decided to stop using PPM and connected the RX to the Naze using the normal multiple channel output cable.
Result = perfect flying

Ignoring what the problem of the radio or signal might be, what I want to say is that is not to exclude some craziness that some radio brands do.
It's annoying to have to use all those cables but I would test it whenever I would suspect there is issues related to PPM independent of their source.

PS: Orange is the new pink.

PacciK · Post by **PacciK** » Tue Dec 31, 2013 4:51 pm

Ice.... thanks for your point. Graupner radios work with inverted PPMSUM stream ( as far as I remember well ).
But still...this should be no issue as I am not using Graupner but Jeti.....which is like Futaba..ie +ve PPMSUM.

Havn't looked at the code for PPMSUM decoding, but I presume that Baseflight and SG all use interrupts that invert state when an edge occurs.
This mitigates the issue Graupner / Futaba and all the rest.

Would like to try Spektrum and Sbus with Naze32 ....but then I cannot use GPS....Correct ?? ( softserial is only for FRsky telem... ??)

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 31, 2013 5:05 pm

@PacciK: I am very sad to hear about your crash - I also had a few and 2 times a complete loss (one sank in the river rhine with aerial footage on a keychaincam for future archaeologists).... sadly I can not advise you anything, except stick to the version that works best for you. I know you can't buy sh*t from my condolences but I def. know how you feel - but thank you very much for your feedback since it's now clear that it is an non sumsignal only related issue. BTW: You are on Naze V5?
@Hinkel: Thanks for your video!
@IceWin: Nice video, it seems you have some mature vibrations going on

- like on my copters.... Before fiddeling with nav_speed_max and Nav PIDS etc I would increase the nav_tiltcomp (default 20) to 30 or so - it should help the RTH speed (BTW 50 is too much and nearly killed me on low hight RTL ...)
Cheers and happy new Year! (sorry for the slow steps but I want to remove everything that bothered me - like the inflightacc calibration)
Rob

timecop · Post by **timecop** » Tue Dec 31, 2013 6:48 pm

IceWind wrote:Geee someone is in a bad mood today.

A bit related to the PPM input, one of the guys I was flying with has a Graupner radio, for sometime he was having twitches and problems like the quad flipping for no reason.
Up until he decided to stop using PPM and connected the RX to the Naze using the normal multiple channel output cable.
Result = perfect flying

Ignoring what the problem of the radio or signal might be, what I want to say is that is not to exclude some craziness that some radio brands do.
It's annoying to have to use all those cables but I would test it whenever I would suspect there is issues related to PPM independent of their source.

PS: Orange is the new pink.

If you'd actually looked at the code that handles PPM (its like 5 lines, literally) - https://github.com/multiwii/baseflight/ ... pwm.c#L242
You'd realize that none of this "random" kinda shit can happen.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 31, 2013 6:49 pm

Off boozing now - happy new year........

PacciK · Post by **PacciK** » Wed Jan 01, 2014 11:51 am

Happy new year to everyone !!!

TC.... just looked at the code you linked......

Unlike pwmCallback...which inverts the polarity of the interrupt for every fire...... ppmCallback seems not to do that and takes every TIM_ICPolarity_Rising as its cue.( am I correct ??)(that is why it is not compatible with Graupner's inverted scheme ? ).

The mechanism that configurates and uses the capture machine is very clever, but since it was made to be configurable at runtime, it uses pointers, and may lead to some ambiguation when attempting to understand it with NuYr booze in one's head .......

So, could there be an issue with the PPM_SUM configuration, to cause the board's interrupt mechanism to lock the board on some rare occasion?

H.N.Y. !!!!!

IceWind · Post by **IceWind** » Wed Jan 01, 2014 12:48 pm

Crashpilot1000 wrote:@IceWin: Nice video, it seems you have some mature vibrations going on - like on my copters.... Before fiddeling with nav_speed_max and Nav PIDS etc I would increase the nav_tiltcomp (default 20) to 30 or so - it should help the RTH speed (BTW 50 is too much and nearly killed me on low hight RTL ...)
Cheers and happy new Year! (sorry for the slow steps but I want to remove everything that bothered me - like the inflightacc calibration)

@Crashpilot1000: I had a crash a few days before due to a loss of video and swapped all props. I've been using HQProps that come really well balanced but those are different brand and went straight from the package to the quad. Didn't balanced them and that is the result. All videos of that day are garbage.

Before that flight I slightly increased the P for the NAV PID and it seemed to have increased the speed. (From ~4km/h to ~7km/h)
I'll start checking the other settings you mentioned, plus the MAG heading as I want it to turn to face the HOME position.
Thanks for the hints.

Happy New Year everyone!

timecop · Post by **timecop** » Thu Jan 02, 2014 8:38 am

PacciK wrote:So, could there be an issue with the PPM_SUM configuration, to cause the board's interrupt mechanism to lock the board on some rare occasion?

I don't drink, so no.

PacciK · Post by **PacciK** » Thu Jan 02, 2014 8:49 am

I don't drink, so no.

LOL!!!

PacciK · Post by **PacciK** » Sat Jan 04, 2014 6:31 pm

Hello Friends,
Its me again with something to report.....
So...after some experimentation with SG2.5 ( Flies OK, but is not compatible with Android apps ..so No fun... ),,,, Baseflight latest TC's firmware ( flies nice, but GPS Hold is not giving any joy )....and SG2.6( flies nice, GPS hold is really Nice and Vario (Baro hold) flight is nice and works as one wishes.... therefore I settled on SG2.6 to play for today, and try to understand what's going on with GPS PH.

My Current test setup is a small Aluminum DIY XQuad, with Naze32(Blue...i think its V3 ( with the MMA accel )), 3S Lipo 2650mAh, Turnigy9X radio with PPM separates ( therefore only 2 Aux's),
Disconnectable bluetooth module ( enables me to use both USB and BT ..otherwise if soldered on, the BT does not allow USB to work), UBlox GPS with Sarantel antenna and DIY groundplane, sees 12 Satellites at the field, 9 at home). 8x4.5 Plastic props, small blue motors ( can't remember their name..from TC's shop), and 4x 12Amp ESC's with SimonK ( also got them from TC's shop about a year ago). Motors are cool, Esc's Cool,...... Bliss.
Energetic flight is fine. Stock PIDs from SG2.6 work really perfectly.

So... here's what I observed after about 6 lipos of testing in really nice weather..wearing a t-shirt...( and in Europe !!! ).

SG2.6's stock GPS hold Pids work fine. Enabling GPS hold 1 minute after takeoff, lets the Quad remain in less than 1 meter box. One can see the corrections to the attitude start even at 50cm from center. Seems like a bit too much high gain on Position hold, but it really stays there !!
Reducing power, grabbing the quad by hand and walking away makes the copter correct its attitude, wanting to go back to its place.... and its like the max angle that can be reached is around 35 ish degrees tilt/roll... when you're more than 30 meters away from the PH center.
Ok... so I Let the copter go ....and it goes to the last GPS hold position. barely overshoots, and stays there . perfect !!!

Strange feature 1) : If I then fly away still under GPS hold, the copter wants to go back to the last position hold, rather than staying at new position after I let go of the sticks. Is this how it should be ????

Strange occurrence 2) : After about 6 minutes of really accurate GPS hold, I fly for a go around, and come back to same place, switch on Position hold, and it drifts away...( no GPS hold ).
I bring the copter down, plug in the Bluetooth module, and on my phone's GCS, I see that its seeing the usual 11/12 satellites, normal position data coming in speed( cm/s is 2->5 cm/s max )... ( Double check that the Aux Assignments are fine, Disconnect the app, remove the BT module, fly again.. (without disconnecting the copter). GPS Hold is not working still. Hmmmm... This gets me intrigued.....
Bring it down again, disconnect battery, 10 seconds, reconnect again, 12 satellites after 20 seconds... remove BT module, Fly and switch on GPS hold...and it works !!

Strange occurrence 3) : Battery is nearing , therefore, bring copter down to a hover, grab it, lower power a little bit, switch on Position Hold, put transmitter down, walk around, and observe the corrections that the GPS hold makes to attempt to come back to centre..... then all of a sudden, motor 1 ( back right ) goes FULL POWER, and surprises my light grip. Luckily I have good reflexes, and hold on tight to it, aggressively trying to pull the copter up in a -45 degree loop ( ie NorthWest orientation according to the frame....of course.. motor 1 still at full power )... I observe what the copter wants to do, and it goes inverted and then the motor lets go a bit....ie reduces RPM.... Hmmm....
So I grab the BT module from my pocket, then fire up the GCS on the phone, get the copter level ( motor 1 now screaming again.. the other 3 just above Idle (as they were before) )....

a) observe the Artificial horizon... its good, observe motor outputs on the GCS, and surely Motor 1 is at 1890ish..... almost max power.....( so its not the esc's fault ).... Hmmm.... observe the radio throws and auxes, and they are as they should be..... !!! WTF is happening...I say to myself !!!
So I walk towards the transmitter still on the ground, and disarm the copter. All motors stop.
Phew.. !!!

So THIS is what is causing my crashes....faceplants... !!! Damn!!!

What have I learnt:

1) The software/firmware is NOT crashing.... (I had thought it was crashing the main program before... because of a previous no response to the radio control ).....
2) All hardware is fine...Naze, ESC's motors, radio...etc.
3) I desperately need to hunt down what's happening..... accurately, and for the benefit of anyone who may be suffering from the same issue.

So..... Here's what I'm asking:

CrashPilot1000 ( Rob )....please point out what 4 debug values should I be observing / recording during a flight with GPS hold, so that I can try to understand what is going on!!
I plan to screen grab video from laptop while flying, while connected to bluetooth, graphing the 4 debug values in real time.

I will branch out a git from your work, and attempt to play with the code.
also..kindly let me know if I should continue to work on the SG2.6 ( Harakiri10 Summer Games 2.6Oct 14 2013 / 15:33:17 )
or else something more recent... ( if so, let me know where to look for it.)

Cheers !!!!

subaru4wd · Post by **subaru4wd** » Sat Jan 04, 2014 7:43 pm

Im using SG2.5 and it works just fine with my android devices.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Jan 04, 2014 8:20 pm

@PacciK: Thank you very much for your writeup! Just to make it clear for me: The motor going berserk when MPU6050 or MMA is in use? I just ask, since I never testet how mma behaves. My actual dev sw status is "SGTodaysSnapshotSmallerACCDB" I tested it today in angle, Baro and PH (RTL not tested) and it worked quiet nice. The PH code was/is a mess but I unmessed it a little bit... . Since it's not tested beyond one lipo no hex is included, but I can compile it for you too check it out. GPS angles are constrained at the very end before the main PID controllers to their predef. max angles (note: gps_maxangle is 35 deg now) - just to be safe and leave absolutely no room for GPS to do "more...". BTW If you want to check that code out some infos are required:
1. Connect the FC to the GUI (and let the gui display the bogus 1st run data to produce serial traffic) so let the chips warm up 2-X minutes - then press ACC calibration - it will take some time. But warm chips give better results, just saying.
2. The GPS PH Bathtub thing is gone and replaced by an expo function for GPSs' virtual sticks (->readme)
3. Due to that expo stuff the PH prebrake is diminished as well so gps_ph_brakemaxangle and gps_ph_minbrakepercent should be higher now - didn't tune that in the 1 lipo flight...
3. Ununsed GUI GPS parameters are set to 0 upon write - so if you see a 0 after reloading parameters you tried to set - you tried to set an unused parameter.
4. PosR I is put out of work and Pos I is put to work to overcome windy conditions. That Pos I could be too much for your setup (def: 0,5) and could lead to circeling.
Cheers
Rob

PacciK · Post by **PacciK** » Sun Jan 05, 2014 12:13 am

Hi Rob, thanks for your reply.

The motor going berserk when MPU6050 or MMA is in use?

The 'Blue' Naze is (i believe) a Rev 3 Board...therefore, ITG3200 and MMA accel. ( No MPU6050 ).
Don't get me wrong..... the board flies absolutely amazing if you don't want to do any GPS stuff. on Both TC's baseflight, and also on SG2.5/6.
However my troubles only pertain to GPS PH use ( till now ), and the faceplant that happens some random time after GPS hold is active.

OK.. I will have a look at your Git.

But what I wanted to know ( from someone who knows the SG2.6 code by heart ), is what should I be monitoring LIVE in flight.....
I was presuming monitoring the P D and I values of the position hold, and SATS in view ( 4 debug parameters ) and chart them on the graph in realtime while at the field over long grass...waiting for the faceplant to happen.
Then knowing cause will hopefully result in cure.

Should I be targeting those 4 debug values /??? or something else ??

10Q ¬¬

brm · Post by **brm** » Sun Jan 05, 2014 7:49 pm

what about an mpu-3050?
mma comes hand in hand with the mpu-6050.
maybe there are some variants with mpu-3050 and mma unit ...

PacciK · Post by **PacciK** » Sun Jan 05, 2014 11:38 pm

Hi BRM,

The board is inside a protective shell,( which also has my interesting wind filtering for the baro ) and currently I cannot access it without dismantling everything.

Probably you are correct ..its an MPU3050...

a Scanbus command in CLI returned:

# scanbus
Scanning I2C-Bus
I2C device at 0x1c probably MMA8452
I2C device at 0x1e probably HMC5883L
I2C device at 0x53 probably ADXL345
I2C device at 0x68 probably MPU3050/MPU6050
I2C device at 0x77 probably BMP085

and a Debug command in CLI returned:

GYRO Runtime StdDev*100
X Offset: 4, StdDev: 85
Y Offset: 24, StdDev: 115
Z Offset: -82, StdDev: 67

ACC StdDev*100
X Offset: 100, StdDev: 1099
Y Offset: -6, StdDev: 499
Z Offset: -4, StdDev: 621
1G Sensorval: 4098

MAG calibrated
X Offset: -509
Y Offset: -512
Z Offset: -137
Runtime
X Gain*1000: 1000
Y Gain*1000: 1000
Z Gain*1000: 1000
Gain NOT OK

BARO
Measured Temp: 23

Remarkable is the "Gain not OK " ??? ( Yet the copter flies well, is very acrobatic, yet stable and very predictable ...ehmmmm when not flying Gps PH..... :twisted:

Why is : "Gain not OK" ??

Anything else dodgy from these quoted results ??

Thanks !!!

Crashpilot1000 · Post by **Crashpilot1000** » Mon Jan 06, 2014 12:43 am

Hi!
@BRM: Welcome back!
@PacciK: Thanks for the scanbus result! I still couldn't track down the issue right now - I did some code to check out but the weather stopped me from doing so. Also reworked some mag stuff. However I can comment (at least) on your "Mag gain not OK".
During bootup the mag runs through a self test and returns a fresh measured scale (not to be mixed up with the calibration, that gathers offsets, not gain. Offsets are added/substracted and gains are multipliers). The mag is set to a sensitivity (preset: 1,9 GAUSS) so if the gain tilts out its' scale on one axis the gain is not ok (saturation) and so set blindly to "1.0" for all axes - to make it *somehow* usable...
In other words you have mag disturbance going on. It was pointed out in this forum that 1,9 gauss is too sensitive and a reduction to 2.5 gauss would be ok. It is ok but 1.9 works a little better with gps & acc from my testing.
But you can "set mag_gain = 1" to activate the lower sensitivity of 2.5 gauss for your setup - maybe that will save you from further mechanical changes (recalibration of mag is required - since the offsets are generated relative to the gain - that you changed).
But don't fly the code yet with your mma/adxl until I have a chance to check my code in flight - just to prevent further evil for your rig...
Cheers
Rob
EDIT: The mag gain stuff is going on in: drv_hmc5883l.c

timecop · Post by **timecop** » Mon Jan 06, 2014 8:22 am

brm wrote:what about an mpu-3050?
mma comes hand in hand with the mpu-6050.
maybe there are some variants with mpu-3050 and mma unit ...

rev3 came with (as standard, I think?) with adxl345 + mma for accel and mpu3050 for gyro.
there has been some (requested) variants with mpu6050 and/or no adxl or mma.

so there are either 2 possible accels to choose adxl345 or mma, and in case of mpu6050, adxl/mma/mpu accel.

none of my hardware ever used ITG3200.