Harakiri aka multiwii port to stm32

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

> hinkel

I like your idea would an excellent feature, it would work for what I prefer to do as it would also free up a position on my 3 way switch. Yes I have more switches but my style is i prefer to simplify my switches. right now i like stabilize/PH/RTL and I think your suggestion would blend with the stabilize nice. It makes sense. What an interesting idea.

Now i have to test Harakiri AH and add stabilize at same time to see how It acts. I never tested the Alt hold yet by itself as I was focusing on GPS, maybe Harakiri already has it so if you adjust altitude with throttle it will hold to new level while in dead band. Now you got me curious.

You know, another interesting idea is the new "hybrid" flight mode in arducopter. I think its both altitude and position but still gives full control out of deadband.

have you already modified harakiri? and if yes have you tried it in the newer testcode?

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Crashpilot1000 wrote:@Mr-fiero: The baro already has that filtering to put out most spikes. On the other hand the hight reading is very temperature (sunlight etc) sensitive. I also own a "compatible" that does serious artificial heating of the baro not helping it's function, my N4 also artificially heats up the baro but less worse.
Nothing much to do to fight that - at least I am not aware of a solution. The hightdrop in forward flight (though throttleangle compensation) is more than in old SG2.5 because I simply forgot to implement my little "accz trick" in the "testcode3/4" after reworking parts of the IMU.
@Colorado: I use the original mwii 2.1 gui, especially on my slow centrino - several - years - old -WinXP - Laptop.
Cheers Rob


Hi,

Your project is lookong outstanding, and it sound the best one for my need over my DIY naze32 alike boards.

One question puzzle me ... how precise need to be acc calibration for make alt hold accurate ?

Any small angle during calibration ... a small angle per the sensor inside the chip ... will cause a wierd Z reading:

Let assume the sensor is a bit inclinated, so at the time of calibration the Z acc will be a bit less then 1g ... but the firmware will map this as 1g internally

Now, when the board get a bit inclination, and still is not moving at all, the Z axis may report a reading higher then the one at calibration time ... so .. the firmware may assume the copter does accelerate vertically ...

So .. all these Z acc compensation for noise baro ... still they sound tricky to me
Also the lame 6 position calibration from APM R&D, sound even a more wierd approach, since it complicate things, without solving the original problem.

Thanks a lot in advance for your point of view about it.

Does you firmware support X and Y acceleration for improve GPS hold too ?

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

Mr-Fiero wrote:> hinkel

I like your idea would an excellent feature, it would work for what I prefer to do as it would also free up a position on my 3 way switch. Yes I have more switches but my style is i prefer to simplify my switches. right now i like stabilize/PH/RTL and I think your suggestion would blend with the stabilize nice. It makes sense. What an interesting idea.

Now i have to test Harakiri AH and add stabilize at same time to see how It acts. I never tested the Alt hold yet by itself as I was focusing on GPS, maybe Harakiri already has it so if you adjust altitude with throttle it will hold to new level while in dead band. Now you got me curious.

You know, another interesting idea is the new "hybrid" flight mode in arducopter. I think its both altitude and position but still gives full control out of deadband.

have you already modified harakiri? and if yes have you tried it in the newer testcode?


Mr Fiero

I don't know if this idea is excellent ? I just test in the backyard and it working funny . The modified Harakiri is Summer Games 2.5 and there are other modification Inside :
* Failsafe info for OSD KVteamosd or MWOSD
* GPS time for MWOSD ( Shikra Patch )
* A don't fall from sky security for people like me " when your are in autoland and switch baro off ....... :lol: "
* In Baro mode if you yaw Throttle stick have no influence (Mode 2 Transmitter only)
* and some newer modification from Crashpilot1000
This is just a test code don't fly with it because it is very special and certainly not working on Naze32 rev5 !
http://github.com/hinkel/SummerGames2.5/tree/barotest

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@Hinkel: Hi, dude! You are known to me as someone with very good ideas over the years aside the mainstream copterfunctions.
I just want to repeat your idea here if i understood it right. You do a "normal" flight (with your new function) and when you idle on the throttlestick for 2 seconds althold is automatically engaged. When movement on the throttlestick re-appears althold is disengaged and the real throttlestick throttle is used again. Besides triggering autolanding and deadpilot failsafe stuff there might be some other problems with this procedure. During althold the althold controller will rise the virtualthrottle so that when re-engaging real throttlestick throttle (esp. with a deadband) you might see a rapid hightloss you will have to compensate for on the sticks quickly. To avoid that the althold should be able to rescale the real throttlestick input (= un-linearize it) for that flight session based on the averaged altholdthrottle and the real stickinput. I bit my teeth on that before, perhaps I was wrong with that idea and therfor just ran into the same wall over and over again. The althold should only be possible then in between a certain throttlestickrange like "copterflying = true" (or some other lower limit, perhaps a new number) and a upper limit (like you suggested) otherwise there might be trouble on the limits of the rc throttlerange. I have a hard time finding your github repo with google please can you post the link again, because it seems you already have tested code at hand (as I know you :) ) so just if you like to share it you are welcome.
@ Mr-Fiero: I have nothing new to present, because I was a) *lazy* (TM) and b) had to organize a birthdayparty as well...
I read across the vrbrain guys post on 3DR concerning that hybrid mode as they posted it. From what I read there it seems to be a similar idea harakiri already had at play: Oversteer PH with the sticks, but I guess they got the re-engagement of PH smooth and slick (without flyback to some previous gathered GPS position, like observed with my stuff). I can not flight test arducopter code anymore since I put my apm out of business after having much damage and after having a tree stopping a flyaway - I washed my underwear from brown stains (i think they call it "brownout") and shelfed the apm.
@ e_lm_70: Thank you for the flowers but baseflight has much improved and is definitely better structured and organized than my stuff. Harakiri was just started because there was no movement in the BF trunc that has dramatically changed and I am really happy about that! There were several lowlevel driver changes that BF made for good reason I didn't take over because a)I didn't want to change stuff that I knew worked very solidly b)I don't know that lowlevel interrupt stuff. Concerning your acc calibration question. Yes there is accelerometer and gps velocity fusion going on as well to improve fast reactions on sudden x/y changes. The acc calibration. Well that is a field that is beyond my limited mathematical understanding but I farted around with that a lot (even fusion of MPU6050 acc and adxl and mma). At the end of the day it seems to be sufficient to me to use the invense supplied 1G value (at the set scaling) and calibrate it like multiwii suggests with a flightcontrol that is eyeballed, maybe better, horizontal. That http://imaginaryz.blogspot.de/2011/04/l ... -data.html algo gets better mag offsets but I couldn't get it to work better on acc or gyro offsets. The 3DR (since the opensource dev is completely company driven, that's why I mention that company here) acc calibration routine was lifted/copied/whatever people may call it from a project that used uncalibrated adxl (analog?) sensors, it adds hassle to the calibration but is (just from my findings) of limited use of already precalibrated digital parts like mpu, mma etc. Besides the supplied 1G value calibration method you can extend it by using pythagoras term to get the total sensor value of the resting sensor for 1G reference to cancle out slight mounting tilting. I once did it but not right of what I found out later when putting the copter upside down - I might revisit that procedure but don't expect miracles from it. However, everybody expects temperature drifts on the gyro part but they are more severe on the acc (especially z) values from what I've seen. So having a practical temperature compensation that really has impact on real life performance seems to me the first thing to engage concerning the calibration aspect of gyro AND acc. Ending up with explanting a flightcontrol putting it with lipo into a fridge/radiator is no practical option - or flinging around a big model around for acc calibration in a tight timeframe - I would sacrifice precision over practical and hasslefree operation any day. But that is a question of philosophy. There are probably some intelligent mathematical tricks available but they are beyond me.
P.s.: Sorry for slow going..
Cheers
Rob


EDIT: I just send this text because I was afraid the froumsoft would eat it, that's why I respond to your latest post here.
Thank you very much for putting your code on display, dude, I will definitely have a look at your work and I think many others will appreciate your work and effort as well..!

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

crashpilot1000

yea I too parked my APM2.5 , 4 units..... for almost the same reasons as you. When they do fail, its spectactular! Skydrops are common too. and pixhawk is way too new. \it might suffer skydrop issue too. Too early to tell.

funny but with your firmware i just dont crash.... close, but only because i deserved it (my faults). I have had only success so far. I think I will fly Testcode3 as it just works for me, and whenever, someday your code changes, \i will continue to follow it and test.

\i run same hardware on the different FC flashed with Harakiri and its funny how I dont get skydrops anymore, its been great. lol

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

Wow there are some great ideas in here!

I esepcially love the Failsafe information being sent to the OSD.

Hope to see some of these features in Harakiri soon :)

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

@Crashpilot1000 !
Thanks for reply
You understood the function right .
The new stuff will not corrupt Failsafe and Autoland and it is use between a certain throttlestickrange as you imagine,
ESCnoFlyThrottle and cfg.al_maxthrsup,
For the moment I will test it on FPV ASAP to see if it is Problematic .

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

So today I got to fly a FULL day (7+ hours) of nothing but Quad FPV. I got to iron out a ton of bugs with my setup, and things were flying smooth.

I am using Harakiri TestCode3 and I noticed when flying in pure manual mode... i would be cruising in a straight line hands off the sticks. Fast forward flight. After a few seconds, i would begin to get some yaw drift, and it would get worse. As soon as I used the stick and gave any yaw command, it picked its new line and stuck to it... no problem. But if I did not give any yaw commands and tried to maintain a straight forward it would begin to get lazy an start to get some really nasty yaw wag.

I am going to be going through all the gopro video so I will try to find the clip.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

subaru4wd wrote:So today I got to fly a FULL day (7+ hours) of nothing but Quad FPV. I got to iron out a ton of bugs with my setup, and things were flying smooth.

I am using Harakiri TestCode3 and I noticed when flying in pure manual mode... i would be cruising in a straight line hands off the sticks. Fast forward flight. After a few seconds, i would begin to get some yaw drift, and it would get worse. As soon as I used the stick and gave any yaw command, it picked its new line and stuck to it... no problem. But if I did not give any yaw commands and tried to maintain a straight forward it would begin to get lazy an start to get some really nasty yaw wag.

I am going to be going through all the gopro video so I will try to find the clip.



Why you don't activate the MAG if you want to be 100% sure to keep the "line" straight ? Without mag, early or later you will get some Yaw drifting.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Crashpilot1000 wrote:...
@ e_lm_70: Thank you for the flowers but baseflight has much improved and is definitely better structured and organized than my stuff. Harakiri was just started because there was no movement in the BF trunc that has dramatically changed and I am really happy about that! There were several lowlevel driver changes that BF made for good reason I didn't take over because a)I didn't want to change stuff that I knew worked very solidly b)I don't know that lowlevel interrupt stuff. Concerning your acc calibration question. Yes there is accelerometer and gps velocity fusion going on as well to improve fast reactions on sudden x/y changes. The acc calibration. Well that is a field that is beyond my limited mathematical understanding but I farted around with that a lot (even fusion of MPU6050 acc and adxl and mma). At the end of the day it seems to be sufficient to me to use the invense supplied 1G value (at the set scaling) and calibrate it like multiwii suggests with a flightcontrol that is eyeballed, maybe better, horizontal. That http://imaginaryz.blogspot.de/2011/04/l ... -data.html algo gets better mag offsets but I couldn't get it to work better on acc or gyro offsets. The 3DR (since the opensource dev is completely company driven, that's why I mention that company here) acc calibration routine was lifted/copied/whatever people may call it from a project that used uncalibrated adxl (analog?) sensors, it adds hassle to the calibration but is (just from my findings) of limited use of already precalibrated digital parts like mpu, mma etc. Besides the supplied 1G value calibration method you can extend it by using pythagoras term to get the total sensor value of the resting sensor for 1G reference to cancle out slight mounting tilting. I once did it but not right of what I found out later when putting the copter upside down - I might revisit that procedure but don't expect miracles from it. However, everybody expects temperature drifts on the gyro part but they are more severe on the acc (especially z) values from what I've seen. So having a practical temperature compensation that really has impact on real life performance seems to me the first thing to engage concerning the calibration aspect of gyro AND acc. Ending up with explanting a flightcontrol putting it with lipo into a fridge/radiator is no practical option - or flinging around a big model around for acc calibration in a tight timeframe - I would sacrifice precision over practical and hasslefree operation any day. But that is a question of philosophy. There are probably some intelligent mathematical tricks available but they are beyond me.
P.s.: Sorry for slow going..
Cheers
Rob


Thanks Rob,

Luckily you have "limited mathematical understanding" ... otherwise my head would have exploded ... I'm not sure I got much of what is above.
So .. can we summarize with part in bold above ?

"Eyeballed" .. it means calibrate the control board as flat as possible ... that is different to calibrate the control board in the spot that the copter hover stable in the simple angle mode.
If the CoG is not perfectly center, the copter tend to require a little angle for hover on the spot, compared to the Eyeballed.

The assumption of Eyeballed, it is that 6050 chips are produced and mount over the board with the sensor almost perfectly horizontal to the ground level ... so mainly we just calibrate the value of 1G and the zero on the X and Y accelerometer ...
PS: Ideally we should calibrate the 6050 in the space, or into a free falling zero gravity environment :D ... free falling calibration could be an idea :mrgreen: ... instead of 6 position calibration like APM people .. just throw the control board from the 10th floor

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@subaru4wd: Thanks for the report. Besides using magnetometer correction for yawdrift, you could try turning down the yaw "I" term. But I will recheck what's going on in the new multiwii yaw controller and my port of it - I suspect a building up yaw "I" because I put that calculation to float variables.
@Hinkel: Back from work and checking out your changes :)
@e_lm_70: Freefall would not work for acc calibration, don't get me wrong the calibration method using the predefined 1G value also compensates for mounting errors, what I meant was to get the real sensors 1g value. In flight you can use airtrim (it's always active - no cli stuff involved-, must be activated by stickcommand before arming - very simple procedure, see readme.txt)
Last edited by Crashpilot1000 on Mon May 05, 2014 7:25 pm, edited 1 time in total.

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

yeah i dont fly with my mag enabled, and yesterday was my first flight with some new motors. I have a lot of tuning left to do, so i will report back once thats done. It was just the only complaint i had after a 7hr day of FPV :)

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I dont know if its just me but Testcode3 is doing something that is not consistent. Not a major issue, just wierd.

When I activate PH, I have noticed if you give it 2 seconds while holding position with sticks, it will then hold that position and altitude at that spot VERY well. Is this GPS settle speed in the params? My GPS has minimal drift right now, and I was watching via telemetry on map to make sure it was not moving first, so I was activating well below the settle speed. I dont think it was this.

If you do not let it settle, it drifts first then locks PH, but once holding it does it VERY well with .25M drift (maybe/max) for a total of 15 minutes, with altitude only .5M max for this same time.

What I have noticed between 3 multicopters (all running Harakiri Testcode3 with copied params), is that if I want to make an altitude correction to gain height, once past dead band it will climb at a rate related to stick position, if you return to dead band, it holds.

But

This is not always 100 percent for climbing while in PH. It will climb 5 out of ten times and work, and the other times, it does nothing, even with throttle max it still wont climb. It just holds altitude. if you descend though, it works 10 out of 10 times. decent always works.

I verified this about 20 times now between my different multicopters, and I think maybe my next test is to see if I can duplicate this in another mode such as altitude hold.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

@Mr-Fiero

I did notice something similar with AltHold in other "firmware" ... in my case my educated guess was due to the "extreme" filtering. Having an "extreme" filtering it cause to have in the firmware a value that can be old even 1 second or half the second old ... like with filtering of 40 samples at 20Hz .. it cause that the end result is the "real" value but 1 second in the past ... so filtering means to work with old data.

So .. if you are moving and then you click on any hold .. the sensed data cold be old ... due to the filtering.

Anyhow ... it sound to me that the firmware to try here is TestCode3 .. my DIY Naze alike board is ready ... so ... time to decide which firmware to use and put this in the air.

Reading you guys ... I have really high hope ... 0.5m altitude accuracy ... I can get easily with my MultiWii board with just using the 5611 sensor (easy) ... but 0.25m horizontal accuracy in GPS hold ... it sound like a "dream" ... my MultiWii board does 10 time worst ... with +/- 2.5m ... and this is already consider good in the Atmega 8bit world with MultiWii

rank
Posts: 31
Joined: Fri Dec 06, 2013 5:27 pm

Re: Harakiri aka multiwii port to stm32

Post by rank »

My appologies for not reading through the thread. Just curious how the sonar is performing with the latest harakiri? Also, any cheap sonar you could recommend?!

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

rank wrote:My appologies for not reading through the thread. Just curious how the sonar is performing with the latest harakiri? Also, any cheap sonar you could recommend?!


My experience with Cheap sonar is quite bad.

On grass you don't get any reading above 50cm.

On asphalt you get a sonar reading up to 1m sometime up 150cm

Since in general I fly over grassl, 50cm is nothing unless you want to have a double check when the copter is on the ground in case of automatic landing.

Integrate a Sonar is very simple ... just 1 pin for trigger the start, and 1 pin for read the echo .. the time difference between trigger and echo is more or less the distance.

With cheap sonar, it is a waste of time ... the expensive ... I don't know ... but 5611 is already all you need for a precise altitude information.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

> e_lm_70
I just want to point out.......

remember that I have been focusing on GPS and have upgraded my antenna's to 35mm active to try to get the horizontal more accurate with better signals from satts. My GPS fix is tight and has minimal deviation viewable via Ucenter. With Ucenter I can keep deviation plot within 1M max for hours, oh, and its in a basement while testing. I have also reduced as much as possible any RF interference to the GPS (real fun due to OpenLRS having a harmonic on GPS freqs) . My next step is to upgrade the GPS engine. I want to get a Ublox 8 onto a 35mm active ceramic antenna and increase my position update rates and see how it works then. Right now its the neo6 engine. My interest in Harakiri is the GPS functions, but, damn does it fly nice!

You will see good PH accuracy as you hope, I just wanted to point out I am splittin hairs to get it so tight on my GPS, as most GPS's to me seem only able to hold within 1M - 2M. I am however very pleased with Testcode3 and I have had no failures to date, just small quirks. Some quirks are probably just me, but I keep posting my results on the forum just in-case Crashpilot1000 notices anything he can use.

Thanks for the explanation about the filter, I really felt that it was an filter or average. Next flights I am going to test what you have said, and try it while still for adjustments, as well as moving and see what happens.

I cant wait to see how your flights go. I dont doubt you will love the alt hold once your dialed in.

mj666
Posts: 186
Joined: Wed Feb 12, 2014 12:02 pm

Re: Harakiri aka multiwii port to stm32

Post by mj666 »

I have quite good experience with the Mabotix MB1242 I2CXL. This is connected via the I2C bus. The PWM version Mabotix MB1240 should work in the same way. Both are supported by Harakiri.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi guys, short notice.
PH accuracy can not be long term better than the underlying gps feedback, however acc support helps but needs gps correction.
Sonar: Thanks to mj666 strong effort, some I2C Sonars are also supported. The more expensive MB parts do way better over grass than the 5$ HC04. However MB parts come with a catch when connected over I2C because they only support slow I2C speed so mj666 has done an I2C speed switching algorithm.
Althold: Yep, the algo waits for the throttlestick to center before it accepts an altchange. When you are too quick on the throttlestick it may not be recognized, because the deadband around the center is skipped too fast and missed in the relatively slow loop. That also annoys me (forcing myself to be slow at the center so the algo gets it) that can be fixed to work more convenient.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Oh, Thanks for that about the alt hold. Explains it! Now I can adjust my flying to match expectations.

Would it help a bit if I increased my dead band? I am going to try to increase it to 10 and see if I can mask how it acts a bit. I am thinking 5 percent dead band might be easily missed for stick center while flying with altitude hold.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Mr-Fiero: The deadband for althold around throttlestickcenter is defined by "rc_dbah = 50 (default)" and that means +-50 considering throttle stick center as being 0. So normally that is ok but can be increased (maximal value is limited to 100 in the cli).

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Thanks! sorry, I remembered that I saw deadband, but was going from memory (or the lack of, lol) for values... but thanks, I will adjust rc_dbah slightly and test

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Which Configuration GUI are you using on Harakiri.
Is MultiWii2.3 official Java gui, supported ?

I see that the Java GUI sort of "freeze" while ACC or MAG calibration is in progress ... something that I never seen before.

Also it does not look like the heading is shown correctly on the GUI ... I would also need to rotate 90deg the MAG in the configuration (CLI) ... and I know old Baseflight version was bugged on this MAG rotation.

The BMP180 it is not clear if it has been detected correctly or not ... I see some changes in the altitude ... but if I blow over the sensor I don't get the strange alt reading like on Baselight or other controllers ...

EDIT:
Based on the code:
ack = i2cRead(0x77, 0x77, 1, &sig); // Check Baroadr.(MS & BMP) BMP will say hello here, MS not
if ( ack) ack = bmp085Detect(&baro); // Are we really dealing with BMP?
if (!ack) ack = ms5611Detect(&baro); // No, Check for MS Baro
if (ack) sensorsSet(SENSOR_BARO);

The TestCode3 does check first the bmp085 ... so .. it is looking it should work on my BMP180 ...
Maybe the blow effect has not influence due to the Z acc compensation ... (more then Z ... it is a vector here I would guess)

PS: Time to check the MAG

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Something odd happen in my bench test .. using TestCode3

I left running the board for a while .. and after an ACC calibration ... the board did send 515 in the Z acc (so it did grown up from 512) ... and it did believe to be over 4 meter up ... from zero.

It sound that there is no temperature calibration happening on the 6050 .. or .. something else ... 4 meter error in altitude is too much for my BMP180 ... strange

EDIT: I can't enter in the CLI ... in theory using putty .. and pressing # twice I should get the CLI prompt .. but instead I get some noise character on the screen ...

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

e_lm_70
### , then you will get a menu, otherwise you are seeing mavlink stream or worse if your baudrate is not correct... usually 115200 baud.

also, you could use stick combination to calibrate your mag to make things easy. if you compile, you can also increase the calibration time (i set mine to 120 seconds), but default is 60 seconds to rotate all axis.

I always issue a "status" command in the CLI to make sure mag is calibrated. also, there is an i2c bus scan you can use to detect your sensors.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Probably I was too tired last night ;-)

Today ... if I keep my thick thumb over the "#" ... then Putty does show me the CLI.

The behave it is a bit different between baseflight and TestCode3 for enter the CLI .. anyhow .. this is solved now.

Once question is left ... it is safe to use MultiWii 2.3 Java official GUI for configuration ?
My build of TestCode3 does show me V211 ... is this a MultiWii 2.1 based porting ?

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

I use mwii gui 2.1 but 2.3 also works for calibration. The sensororientation (esp. mag) is like it's found on n3/4/5 and on the clones (judging from the pictures). Since you use some homebrew setup with IMU it is most likely that the sensors are soldered up in a different orientation. Concerning the mag orientation the same rules like in the mwii wiki apply. Mr_fiero is right. ### or 3 times <Return> will enter the cli when copter is not armed. There you will find a flashoption as well in the presented listing. Alternatively you can put in RRR for flashing, or short bootloader pads.
I've seen you farting around with the baro and checksums and *somehow* that looks weird.
In CLI you can type "status" and you will see different "onboard" sensors displayed. Alternatively "scanbus" will scan the I2C bus and show what is found. Maybe that will help you. When setting "set bar_dbg = 1" you will get the baro debug values in debug[0..3]. Debug[0] is the filtered, barohight in cm * 10 so that will help you see the pure baro (not acc altered) values.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Crashpilot1000 wrote:I use mwii gui 2.1 but 2.3 also works for calibration. The sensororientation (esp. mag) is like it's found on n3/4/5 and on the clones (judging from the pictures). Since you use some homebrew setup with IMU it is most likely that the sensors are soldered up in a different orientation. Concerning the mag orientation the same rules like in the mwii wiki apply. Mr_fiero is right. ### or 3 times <Return> will enter the cli when copter is not armed. There you will find a flashoption as well in the presented listing. Alternatively you can put in RRR for flashing, or short bootloader pads.
I've seen you farting around with the baro and checksums and *somehow* that looks weird.
In CLI you can type "status" and you will see different "onboard" sensors displayed. Alternatively "scanbus" will scan the I2C bus and show what is found. Maybe that will help you. When setting "set bar_dbg = 1" you will get the baro debug values in debug[0..3]. Debug[0] is the filtered, barohight in cm * 10 so that will help you see the pure baro (not acc altered) values.


My DIY 10DOF has a 5883 90deg off compared to Naze32.
Using different version of baseflight (at beginning I was using a 2013 versions) ... I did find that none of the old Beseflight versions did work fine: I did try all the possible CLI align_mag setting without success. Only with latest version I can use this CLI command and finally my MAG is properly used in the right orientation (so consistently with gyro-acc signals)

So since your TestCode3 is based on a old Baseflight version, I'm afraid I may hit the same bug that I did find on old Baseflight : so I'm afraid it will be too much work to make my 10DOF work on TestCode3.

So ... I will keep my DIY board with Baseflight ... (I did hot glue the 10DOF over the cheap STM32 board)

Soon I should get a new STM32 board and I have some other 10DOF that follow 1:1 the Naze32 orientation and using same components... so with a better clone of Naze32 I will try TestCode3 again.

BTW -> What can you tell me about the ACC reading going crazy?
: if I let my board running for few minutes over USB power ... after a while the Z acc, does report 515 ... and my alt is sensed 4meter up .. this does not happen with Baseflight.
I can understand the 4m up .... but not that the ACC reading go "wild" ... I'm using a traditional 6050 chip here ... and I don't get this issue with baseflight.

Ok ... more then ask ... I should go into and read the code ... but for now ... I need to skip this project with my "wild" extreme DIY set up.

The beauty of my "wild" DIY it is that it cost just 14$ and can be build in few minutes with limited skills ... using cheap eBay components. A huge difference in price compared to Naze32 (ok Rev5 of Naze has also a 16Mbit EEprom, that I will not place on my DIY ... still is a 14$ Naze R4 equivalent what I did DIY)

PS. About the checksum fart ... this was an issue with BMP180 and Baseflight ... TestCode3 does not have this issue

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

You can still change sensor orientations but it is most probably more compfortable in BF.
The value you see in the accz field in the gui is arbitrary scaled to 512 or 256 or whatever. But you will see a change of that value during heating up. The altitude/acc complimentary factors are chosen low enough to prevent acc readings from driving off the altitude. That means the barometer still has the last word the absolute hight. From what I see BF uses similar MS5611 driver? So don't know what you are watching there for a difference between the versions. The BMP085 driver is a little different though.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

This is the point ... my 10DOF DIY has a BMP180 that need to use a BMP085 driver.
I will got for TestCode3 with the next DIY STM32 control board.
When I saw the long list of option from CLI ... I got a bit "depressed" ... a lot of learning needed to master your work ... at least from my first look.
Baseflight is looking more "easy" ... so I will take this incremental learning approach.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi lm_70!
No need to get depressed those parameters CAN be changed but in most cases (i guess!) they don't need to. Having a lot of parameters that are preset with values that work with my setup has some advantages. Like example tricopters. I have no flyable naze tricopter but there are several options for those guys and I don't know what servos (digital/analog) and what mechanical linkage they have - so the servo filtering is widely configurable for those guys. I got 1 (!) feedback that it works well with the default values (+reversing on HIS setup with a digital servo) so from my perspective it wouldn't be wise to cut the parameters down - unless some hardware constrains tell me so. Most of the changed parameters are described in the readme.txt or open config.c in some editor - you will find for almost every parameter a text depicting its' purpose and range - and you will see that most parameters (if not all) are there on a purpose because you might run into a situation of changing one or several of them - many find that optional but you can and that is some dji users might dream of. If you can't sort things out there is probably a parameter that can help you - that is the basic idea behind that.
Concerning your statement in the other thread concering the baro detection
.. and there the Baro sensor detection is first check for BMP085 and then check for MS5611 ... and apparently this approach works for my BMP180.
Anyhow, my guess it is that this was an old approach of Baseflight, that is still on Harakiri ... but for some reason the Baseflight development decided to change it.

Just to get it straight that is not how it was done on some ancient BF version. I changed the detection sequence without further notice because I didn't thought it was worth further mentioning. I just didn't get the hang of the BF detection sequence and changed it to something that I could understand and seemed more reasonable to me (+could test it with BMP and MS baro). I am happy to hear that it actually sorted out your baro correctly - just put it the way that seemed understandable and more reasonable to me from a non programmers perspective.

EDIT:
Baseflight is looking more "easy" ... so I will take this incremental learning approach.

Definitely! BF is more structured and has committers that understand programming much better than I do. I can only fiddle around and try to implement what I would like to see in my copter and old guy flying style. So you can't expect Sbus, Graupner, Spektrum or other protocols to work flawlessly in my stuff because I simply don't have it and can not test it. I stand by to be a sponsored guy that has all the hardware available he wants and checks it out and makes it work like expected. But if that should ever happen (I really doubt it) I will clearly state it here, that I am sponsored by XYZ and my talking may be biased. That is my main critics at the German forums i know of in general - some people are sponsored by xyz but they will not state it and fight different thoughts. I think of those guys as moles and don't think there is really a need for that in the hobby area. Open play should be (in my opinion) the main goal in the hobby arena when it should be truthfully called open source. From my understanding open source should run on open hardware. I don't know the legal aspects of it (OSHW licenses etc.) but I just want to represent here of what I think what that means: Have all the code at your compiling hands (even maybe as precompiled file), heat up the soldering iron after visiting the local(?) electronics shop and build something *working* on yourself. If some - of course always (irony) evil - cloners do the same, you (as founder of the hardware or software) will have to take it with a grin because you choose the route for all people in the world that are interested in you project. Ask the doublemoral company 3DR (too sad they even didn't event that, doublemoral is known to humans much longer - BTW does anybody know what 3DR really invented over the already exsisting? - brownouts? glitches?) about it what they think of it - but not in their forums because you will be deleted - that's called free speech in america.

Cheers Rob

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Thanks for your explanation Rob.

I agree with all you state above ... and I'm a guy that like to bring up a different point of view.

The long list of configurable option ... it sound reasonable after your explanation ... so please keep it as it is ... if default value is working in most of the cases .. then it should be easy to handle it.

Your words are a good motivation for try to make a flyable DIY Harakiri ... but .. for now I will do it only with a proper 10DOF ...

I see there are out there some enthusiast over the DIY and STM32 ... I will try, in my very little possibility, to make it more accessible and maybe a bit better known.

So first step for me is to fly ultra cheap 14$ DIY Baseflight ... and then the 22$ DIY Harakiri TestCode3 ... and finally .. make an "unfair"comparison .. between the good basic and the state of art ... both from HW and FW point of view.
Ok ... basic and state of art is probably an extreme and provocative terminology ... so ... but it is the short way to express my comparison goal.

Tchuss

e_lm_70

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Harakiri aka multiwii port to stm32

Post by timecop »

You keep throwing around all these $10, $14, etc, however you're forgetting to factor in your time - which I have a feeling is probably worthless if you have to bring up difference of $4.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

timecop wrote:You keep throwing around all these $10, $14, etc, however you're forgetting to factor in your time - which I have a feeling is probably worthless if you have to bring up difference of $4.


Right ... time is money ... but as well .. for me the time that I spend on it, is also time for learn new things. (Not that I need this learning for my job ... but you never know what you may need ... and for me this mix of HW + FW + RC ... is very addictive ... and it is more fun for me to do DIY then not to fly a simple super stabilized copter, that now everybody can do it)

Anyhow ... about price .. maybe I should move this note on my post#1 -> http://www.rcgroups.com/forums/showpost ... stcount=23
If you don't want to click ... here is the quote of what I already stated on my "blog" report.
PPS: DIY is mainly for learn ... I still strongly suggest to buy the real Naze32 from TimeCop .. without him this board would not exist .. and his price it 100% reasonable ...


Back to 14$ ... 14$ is for the full STM32 board + 10DOF DIY module ... only the 5611 Module cost more then 14$.

BTW ... I just maiden my 14$ DIY Naze32 alike board using BaseFlight ... perfect success ... nice and easy and smooth

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I got to fly today, and it was a good day weather wise....yay

Anyways, I wanted to test PH more. It works awesome. now that I know the altitude gain has to be centre before any altitude adjustment is given while in PH now it feels good. I am getting used to it.

My position locks are VERY tight and will stay within .5M for 10 to 15 minutes.

Altitude hold is incredible.

I was trying to fly while in PH to see what would happen. Altitude hold will try to maintain within 1M while flying. If you stop at a position and let go of the sticks, it will drift a bit off position, then it holds. I think the averaging has to catch up. I changed my gps_ph_settlespeed = 50 because I want to be able to fly, but if I want to hold, to let go of my sticks and have it try to hold. Anyways I noticed if you fly to a location while in PH, and hold position for 2 seconds manually with the sticks, and then let go, it holds that correct position very well.

I was able to fly 8 batteries at a total of 15 minutes per battery, so I got lots of flight time in today. My unit felt really good and reliable.

Anyways, after flying mostly ardupilot, and having so many failures, I am starting to trust my unit more now. I have had NO failures related to Harakiri at all! I am running Testcode3 right now and I want to fly more time with it and see how it performs over time. Now that I dont get "sky drops" or "flyaways" I was exploring around the field I fly in and using my video FPV to fly with. It was great. Finally something that works.

What was really nice, I followed my kids to a different location, and then activated PH for the time they were away out of ground view, but I was keeping an eye on the kids with the multicopter. My kids dont even pay it attention though as I think they are getting too used to it.

Rob, I am so glad to run your code, and finally I can have some fun this year flying, instead of fixing all the time. Thanks for sharing! I am going to skip the Testcode4 because it just didnt work for me with GPS functions, atleast not like the Testcode3 is working. But as you said you were revamping your code, I will test next release and always post my test results in-case you notice something you can use. For now, I will just keep testing with Testcode3 and will post my tests.

Thanks!

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Are you using a NEO6 GPS with some advanced configuration on it ?

Today I did test the AH on my DIY Naze32 with DIY 10DOF, with BMP180 ... got relative "depressed" to see landing from 1.5m up my copter ... not sure if I do something wrong on the sticks, or if I need to add some protection over BMP180 (even if it it has little free air, and no sun light (5883 is over it)) ... or the BMP180 is so poor.

For the rest my DIY fly spot on ... MAG included ... (GPS still not connected)

My DIY so far has been air tested only on BaseFlight

Reading your results ... it makes me jealous ... I have seen already my MultiWii with 5611 sensor doing a decent job on alt hold (still +/- 0.5m ) ... but on GPS hold ... when I get +/- 2m I feel lucky ... so .. your achievement are outstanding.

Just win on eBay one more STM32 board for 6.5$ shipped ... soon I should have my 2nd and 3rd DIY Naze32 ... next one will have luxus 10DOF with proper 5611 inside ... so I should get same result as you guys ... else ... I will really get depressed .. LOL

Ok ... waiting for finish the PinP processing of my new video KK2.0 does MultiWii2.3 with GPS (in style I may add also) ... my DIY Naze32 video is already available .. nothing special .. but it did fly very nice and smooth.

Tchuss

e_lm_70

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Dont be too jealous, its been a long path to get where I am today! In the past with other controllers I have seriously had about 50 crashes to date. I am not joking about the total, but I am the kind of person that will NEVER give up. So, Till now I have never been totally happy.

Anyways, about my GPS.

Its a Neo6 Ublox, but I removed the antenna and added an active 35mm ceramic. I did this because I wanted the signal strengh to be stronger to try to get a better fix. Also, I looked inside of Harakiri and activated ONLY what it would use for messages. Then, I started testing the Ublox with Ucenter and watched for the results with the deviation meter. The main adjustment was instead of having the angle to horizon set to 5 degrees for sat view, I changed it to 8. I cant remember the value names, but there is one for PDOP and another for HDOP mask, and the default value is 25. I also played with these values, as they are what new data would be accepted as valid. other adjustments made I just kept adjusting untill the GPS held position with minimal deviation, but still could accept position changes quickly. But then, again to stop and provide position with no deviation again.

Then after I got the unit as tight as possible, I started to play with RF as I run 1.2Ghz video TX, and OpenLRS at 420Mhz. Both produce harmonics and I had to slightly change my OpenLRS. The video I found channel 1080mhz will work with out flooding the GPS signal level. I also found if I fed my flight controller board with 5v it was less of a GPS signal, where 5.5 volts works better. I think this was because the power needed for the active antenna as the GPS has its own regulator, so it has to be the antenna pre-amps. I did find that the power supply on the GPS is sensitive to noise on the power bus also. this might also be because I bet the active antenna has poor filtering.

I made new antenna's for everything used and this allowed me to "notch" my antenna's so that the frequency I wanted would be the best SWR, but they are really narrow band, so this also helps stray harmonics. Its a good idea Crashpilot1000 had to slightly change the clock speed on the FC as well, as there was an awkward harmonic before but since clock speed was increased, it fixed it. I was lucky because my work has an Anritsu Sitemaster with a ton of options and they let me take it home for as long as we dont need it at work.

So, yea, its not normal what I am doing with my GPS, but I am focused on it and we will see where i end up. Anyways, as soon as I can I am going to purchase a Ublox 7m engine, and 35mm ceramic antennas to see how good it is as the 7m will do over 5hz update. yes i realize the neo6 will send updates over 5, but they are not real. the neo6 is only good maybe up to 5hz or 6hz. I do want to test the Ublox 8 but that wont be for a while. I have Ublox MAX7C not realizing the 7C ment the engine would not supply my antenna with parasite power. (another lesson learned...lol) I could build the circuit but why, I'll just get a 7m soon. I have a firm belief that if you fly, and want to use automatic functions that use the GPS, then your unit can only perform as good as your GPS is. And GPS's are not that accurate, or lets say people expect too much for a device that lists its accuracy at 5M or 2M. Now that being said, they are awesome units and I cannot believe once you log into the Ublox how powerful it is. Its not the firmwares that give accuracy, its the GPS, but works hand in hand with the firmware.

The new Ublox 8 will have a saw filter on it, that will help bigtime with any RF problems. Cant wait.

Anyways, I'm allways messing with stuff, and this is my first year I am able to reliably fly with GPS functions. I have had so many other firmwares fail, on same hardware/frames......

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Wind today was only 5km/h to 10km/h

Flew a total of 8 batteries again 4400mah @ 15minutes flight each.....

it was awesome today, but, I did crash once.... I deserved it. I was flying while in PH very aggressive and the ground jump up.... lol, only bent a motor mount.

anyways, here is a small sample of the unit in PH while a slight breeze is blowing. You can see the wind has bursts, but the multicopter takes it well. Not my best PH, but it was a good example of what I am seeing from Testcode3.. My day was another awesome flying day!

here is the google plus link

https://plus.google.com/114605860380045 ... NSsAyMBLrw
https://plus.google.com/114605860380045 ... 8rGm6t4VsV

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Very impressive ...

Why you don't use YouTube instead of Google+ ?

I'm impress that horizontal accuracy it looking much better then the vertical/altitude one ... that is a bit "odd" ... as well it is a sign that your GPS is doing an amazing work.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I dont use youtube at all. I dont even like to view it because now days its plastered with advertising, and junk... Google + is very handy as it integrates well with my phone, and automatically uploads into my google + without thinking about it. Being a linux fan, Android/Linux serves me very well, therefore since google is so integrated these days, it just works. Just my preference I guess.....I just cant see the advantage of youtube. I did notice however that youtube is now trying to tie into google + but why?

Anyways, yes, your right, I have some deviation on my altitude, I have been trying to work it out. when I am flying it is not too bad because I usually only see the 1M difference I was talking about. I have to play with my PID''s some more and see if I can get it to smooth out.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

> Crashpilot1000

Can you clarify gps_ph_settlespeed for me?

Is this the length of average of GPS position updates, or is it a setting that below this speed the GPS is considered settled before hold is active?

OK, searching the src files I found this
// 1 - 200 cm/s PH settlespeed in cm/s

Is it correct thinking that the PH will lock when position updates ground speed are under this value? If I set this to a high value will it try to hold sooner, lets say when I correct position manually with the sticks, but its moving slighly, will it start to average position updates as long as they are under this value? My GPS is tracking very fast, and accurate, so I am going to try a high value while flying in PH, and then stop and see how it holds.
Last edited by Mr-Fiero on Tue May 13, 2014 7:44 pm, edited 1 time in total.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

Mr-Fiero wrote:I dont use youtube at all. I dont even like to view it because now days its plastered with advertising, and junk... Google + is very handy as it integrates well with my phone, and automatically uploads into my google + without thinking about it. Being a linux fan, Android/Linux serves me very well, therefore since google is so integrated these days, it just works. Just my preference I guess.....I just cant see the advantage of youtube. I did notice however that youtube is now trying to tie into google + but why?

Anyways, yes, your right, I have some deviation on my altitude, I have been trying to work it out. when I am flying it is not too bad because I usually only see the 1M difference I was talking about. I have to play with my PID''s some more and see if I can get it to smooth out.


About YouTube and Google ... as you may know YouTube is owned by Google, and Google is trying to merge some functionalists in order to boost their Google+ experience (that is still far behind FaceBook that is consider a competitor of Google+) ... anyhow
You may dislike the ads on YouTube, but actually ads are everywhere on the net.
The main difference of YouTube ads, it is that YouTube is the first service (as far as I know) that does share the ads revenues with the private little content owners, so YouTube users can get a share of the ads shown while the own video is broadcasted on the net. I think this approach of YouTube is simply brilliant.

About the alt hold accuracy ... this puzzle me a little bit ... the math for fix a copter in the space should be exactly the same between vertical and horizontal ... the double integration of the acceleration (minus gravity for Z axis) need to stay at value zero for be fix into one point.

Now, either your gravity sensed has been calibrated wrong, and there is an offset that drag you in a direction and then it get compensate by the "noisy" baro sensor.
Or ... the magic of the horizontal prevision, it is not due to the "math" inside TestCode3, but it is more into the perfect accuracy of your GPS.
Also ... it is possible that you have some noise/vibration that effect the vertical, while on horizontal you have much less vibration/noise ...

Anyhow ... your level of position hold, I think it is possible even better then the market leader DJI Naza :ugeek:
So ... the alt hold mini micro imperfection, it is something not to bother about from my point of view.

PS: For me it would be interesting to know, which type of result you can get with a normal GPS that does provide the classic +/- 3 meters error ... this would prove the quality of the TestCode3 ... anyhow ... matter of time .. and I will have my own test ... and I guess you have no interest on downgrade your copter ;)

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Well, I have other multicopters with stock GPS. After I fly a bit more, and tweak I will copy my setup into my other frames and fly. Then I can let you know how they perform with the GPS. But today, no time cause its finally nice weather outside, really nice and I have all my batteries charged. 3 hours worth.... cant wait.

About the altitude variations. When I copy all my settings into another unit they all act exactly the same. I need to stress the word exactly. I have 6 FLIP32+ all on quadcopters, and they generally fly exactly the same (excluding the mini quad). Some units have weight differences due to different camera's.

I have been playing around now with vibration reduction and have moved all my electronics up top of the rubber dampening. On the Z axis, its more stiff than X or Y, but could this be what you are meaning about my dampening? Here is my latest design I am testing. But, this is not installed on all my units, so I dont think its this being the issue. I rather like this last design because all my electronics have paces to mount, and they will even fit inside the dome. I did notice however the polycarbonate did reduce the GPS signal, so I opted to keep the GPS outside the dome, as well as my antenna's. I will have to take a picture of a complete unit and post but they did turn out nice. The really nice thing about this design, is to move my controls to another unit, its 4 screws, 4 servo plugs (signal wire only), and one power JST connector. It really takes me 5 minutes tops. I designed it to fit the APM2.5 but still be able to place a FLIP compatible board in the center as well. This mount only adds 100g excluding dome. I got tired of not having good locations for mounting and I do not like the "dead cat" frames. Its just my thing, only my preferences.... but it works good!

https://plus.google.com/114605860380045 ... 8pgb13qs4h

but as you said, you are almost ready and will probably have your answers soon...... I wish you success and am curious myself how your flight goes.

About youtube....I try not to use. I might view 2 videos a year only because I really needed to. There are other solutions. My internet strips adds via my firewall. Its 98% effective. Even at my workplace we are now doing the same. They just are not needed. Hey thats just me.......

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Hi, Mr-Fiero!

I've been busy the last few days...
Thank you very much for your videos!
Concerning the gps_ph_settlespeed, you are basically right.
In the Position hold cascade, when the sticks are released, the gps speed is gathered and an overspeed brake is performed (after that the final PH).
Basically the braking action is assumed to be ready when the reported gps speed is lower than gps_ph_settlespeed but there is also a timeout because some nasty wind can spoil that. That timeout consists of 2 parts. The first part is an absolute limit of 5 seconds, so no matter what the pure braking will not be longer than that. The other thing is assuming the time that is needed for braking based on the GPS reported speed and the copters' braking possibility/capability represented by gps_ph_brkacc (positive value but actually it is a negative acceleration).

Code: Select all

...
if (AvgSpeed < cfg.gps_ph_settlespeed) PHcascade++;
else
{
    if(!PhTimer1) PhTimer1 = currentTimeMS + constrain(((AvgSpeed - cfg.gps_ph_settlespeed) / cfg.gps_ph_brkacc) * 1000, 1, 5000);  // t = v/a limit to 5 seconds
    else if (currentTimeMS >= PhTimer1) PHcascade++;
}
...


Cheers
Rob

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Harakiri aka multiwii port to stm32

Post by timecop »

glorious indentation

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

Works pretty good in the wind today. It was about 15-20km/h but the bursts might of been25-30km/h at moments. (guessing) I was just testing to see what would happen while flying in PH and it did pretty good. my altitude PID's still need work I know.

https://plus.google.com/114605860380045 ... sQnqbk1wWm

Sorry for the poor example, but its an example that I had that it was functional in wind. The rest of my day I was flying mostly in PH for FPV. I had a wierd issue where I flew into another field behind a hill out of sight, and then my battery on my video monitor went dead. (maybe faulty balance charger) Holy crap, I lost my direction. So, I clicked to PH to think, hoping that it worked. Then after thinking if I wanted to chase it, instead I activated RTL. It was slow but eventually 5 minutes later it came back and hovered at current height. Thank you, Thank you! It didnt try to land, but thats OK, I was so happy to get it back. 5 minutes is a long time.....Again, another lesson anything can happen.

You know, Its great to have these GPS features even if they are just for a small margin of extra safety. It worked very well for me today.

One thing to note, I am testing while flying in PH, so I know this is not a normal condition, but I just want to test everything. I noticed, and its been over all my testing, that when you reposition and let your speed decrease below gps_ph_settlespeed, at first it seems to want to sample averages. The shorter time you allow before letting sticks center, the more the drift back towards a previous position. It seems if you hold position for 5 seconds, you are good when you let sticks center. any less has a direct deviation from new location towards old position, but eventually it holds. You can see it when it locks. Not an issue for me as I am used to it, but there is once instance it works against you. If you fly fast in PH to new location, release to centre sticks, it is quite aggressive to try to get back to the original position, even if it is far away. I mean really aggressive, and will overshoot a few times until it slows below the gps_ph_settlespeed I guess. From what you stated earlier about PH, This is probably related to the 5 seconds you mention.

Another thing noticed, if flying in PH on my other unit, every once in a while, it would circle about 1M once, then go back to correct centre position and lock again. I have to re-calibrate my mag on that unit and see if that condition replicates.
Last edited by Mr-Fiero on Wed May 14, 2014 3:42 pm, edited 1 time in total.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Harakiri aka multiwii port to stm32

Post by e_lm_70 »

5min is very long time for RTH.

In multiwii it is configurable the navigation speed ... this is the first that I did, to increase by a lot the configured default speed.

I guess there should be a parameter on Harakiri too for set the navigation speed to be used in RTH.

Mr-Fiero
Posts: 216
Joined: Sat Apr 05, 2014 3:26 am

Re: Harakiri aka multiwii port to stm32

Post by Mr-Fiero »

I cant remember the defaults for Harakiri, I think it was set to 350 for speed, but I left it at defaults, and when my unit was in RTL, It was not travelling at that speed. It was VERY, slow. But once it was in sight I could see it was heading in the right direction. I left it in RTL anyways and let it finish to see if it was working regardless of the speed, and when it was home, it maintained current height and held position. To be fair, it was far away, probably 1km so I have to do the math, it might of been travelling at correct default speed. Things feel painfully longer while having and incident. LOL

It was so long to return, I was worried about my battery as I knew I was over %70 drain. My timer on my radio was at 10 minutes. But that battery was brand new, so I knew it had a better chance of going to make it as usually new batteries will fly for me for 15 minutes or up to 20 if I had push it (20 not reliable).

anyways, I attribute this one to my issue as I am stress testing the Harakiri firmware. Other than that, I had 2.8 hours of great flights with no incident related to Harakiri. I do however have an issue on one of my fav units. I had a motor start dipping. I dont usually bother with bullet connectors, but on this one I thought I would try them, but now I am going to remove them and solder directly.

When I had this trouble, the firmware was awesome. I flew this defective unit for a total of ten minutes with the motor cutting out for 1 to 3 seconds each time. It sometimes would flip on decent, but then when motor started, it would level again quickly. I kept flying it because I wanted to see how Harakiri handled it, and it kept it flying the best it could. There was an advantage when Harakiri would realize the altitude lost, and gain it back quickly because by then the motor would cut out again. As weird as this bad multicopter was, Harakiri did manage very well at trying to keep it in the air. I never crashed. I should of crashed but it just didnt happen.

Colorado CJ
Posts: 2
Joined: Sat Apr 05, 2014 7:10 pm

Re: Harakiri aka multiwii port to stm32

Post by Colorado CJ »

Anyone using a MinmOSD with testcode3 ? I can't get the Minh OSD to work, when I plug in the battery, my screen just says "mavlink waiting for heartbeats" and doesn't display video from the camera.

strips
Posts: 163
Joined: Thu Apr 03, 2014 1:28 pm

Sv: Harakiri aka multiwii port to stm32

Post by strips »

Mr-Fiero wrote:...
Then after thinking if I wanted to chase it, instead I activated RTL. It was slow but eventually 5 minutes later it came back and hovered at current height. Thank you, Thank you! It didnt try to land, but thats OK, I was so happy to get it back. 5 minutes is a long time.....Again, another lesson anything can happen.
...


Nice one! I too had very slow RTL speed. But only had 7 meters to return. I was surprised at the slow speed. I have only witnesses RTL a few times on a Phantom and the Phantom was racing in comparison.

Mr-Fiero,
I'm curious about you PH / GPS settings. For both Harakiri and Ublox settings. Would you mind sharing them?

Regards
Stian

Post Reply