Harakiri aka multiwii port to stm32

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

I had a new flight test on TestCode3 now. I have not made any changes to config since last test.

Only slight wind so it was easier to test. It flies pretty good and smooth. Stock PIDS.

- Rate mode was good. I find it a bit soft.
- Angle and Horizon was good and smooth. Again maybe a bit too smooth.
- Mag and Baro worked good. Kept height within 1m most of the time.
- GPS Hold made no difference, just kept drifting with the wind for 3-4 meters before I had to take control. Repeated this a couple of times. I had 3 blinks. I could count them while in air. I decided to land, disarmed, armed and made a new go. No difference. It drifts ~4 meters before I run out of flight room.

I switched back to mag and baro to fly back to my house. Decided to try landing in baro mode. It lowered towards the ground but would not touch down completely. Was missing 20cm. In the wind i got nervous and flipped to rate-mode with no throttle and nothing happened. It then touched the ground and bounced a couple of times before settling. It was drifting sideways at the same time so I bent a couple of thin alu standoff legs.

So GPS Hold was no success and baro-mode landing was a bit sketchy. Probably user error. It usually is

I have Angle, Baro, Mag and GPS hold at the same time when I test GPS Hold.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Apr 10, 2014 9:58 pm

@Subaru: You can try Tescode4 as well. I am pretty sure ubloxdumb worked in SG2.5.
@strips: Thx for your feedback.
When GPS PH is absolutely not working I would check 2 things first (besides the obvious LAT/LON feedback).
1. Proper calibrated Mag / proper mag declination.
2. Nick/Roll being neutral when released and well within the Deadband.

Concerning your not landing stuff. Did you adjust your PWM Throttlerange?
esc_min = 1100 (Value where all motors run with their lowest speed)
esc_max = 1950 (Maximal Motorvalue)
esc_moff = 1000 (Value where motors don't turn -> that value is send in disarmed state)
esc_nfly = 1300 (Value where Copter gets "light" but can not fly. You can put in "0" as well but then a 5% value of the throttlerange is assumed.

Concerning the Ublox Autoconfiguration. The original multiwii config block is sent + setting pedestrian mode.
Refer here:
http://code.google.com/p/multiwii/sourc ... PS.cpp#231
and
https://github.com/Crashpilot1000/TestC ... _gps.c#L28

Mr-Fiero · Post by **Mr-Fiero** » Thu Apr 10, 2014 10:40 pm

strips >
Crashpilot1000 told you to use gps_type = 4 ("GPS_UBLOX_DUMB") because any other gps_type the code will try to configure your ublox GPS for you. If you use type 4 as suggested, it wont change your custom settings in the Ublox GPS, therefore allowing you to have your own settings saved in the Ublox.

The other types try to force recommended settings but have a safety margin for compatibility between different GPS, so if your GPS has a higher update rate capacity, even after you set to a higher refresh, gps_type will send the Ublox config settings and force it into 5hz and a few other settings (if i remember inside the code correctly).

oh, and yes, i agree with Crashpilot1000, if you do not calibrate your mag, all GPS functions are inop. do a "status" command in CLI to be sure its calibrated.

Also, you might want to make sure sonar is turned off, and use sonar for landing is probably set to 1. I dont know if it matters if the feature SONAR is not turned on but the use sonar for landing is still active. Crashpilot1000 would be best to answer that one. I usually just make sure its off and set the use sonar for landing to 0 to be sure.

I am at a standstill for testing as our winds are crazy! I have upgraded my antenna's on the GPS's to 35mm active ceramics, and have seen massive improvements with deviation tests. I cant wait to test again as I suspect it will be better results. I have minimized my GPS delays as much as possible and change my angle of horizon to 8 degrees because of the stronger signal strengths (more sats in view PDOP way better).

I have also had time to go over everything for and RF issues from OpenLRS and have been looking for noise on the supply bus for the GPS to see if I can find any other improvements. I am impressed that Crashpilot increased the clock to get rid of the harmonics. I am lucky right now as I have an Anritsu Sitemaster in my hands for some time.

Its great because I have now built all my antenna's. Out of stock antenna's, I had about 20 of them all different freqs, for all my devices, and so far have found only two that were any good. I have found that properly tuned antenna's make a massive difference to reduce GPS errors due to RF noise. My current antenna's are very notched and they now get rid of all stray harmonics very well and I have seen awesome gains for GPS accuracy.

I am focusing on the GPS more now than ever. For automatic flight operations, I feel people really need to be %100 sure of the GPS, and I cant stress how important this is. You cannot assume because it says it the best, or was expensive, it will perform. Everyone has to audit all equipment and be clear on what is really going on. Even cheaper GPS engines are VERY effective, if everything is done right. Of course, as Crashpilot1000 develops his code, It will even get better using GPS, but right now, it works well for me. i am eager to see all the automatic modes in the future work as in the source code Crashpilot1000 has already made notes of where Harakiri is headed.

oh, I cant wait to fly again

Mr-Fiero · Post by **Mr-Fiero** » Fri Apr 11, 2014 2:20 am

OK, flew in wind as weather is so poor right now and I think I noticed something.

after letting my GPS settle, and watching map so I know there was no deviation, I proceeded to hover in one area, activated PH and quad moves about 1 meter due to wind, but then it locks in and fights to stay in that spot. This is repeatable.

Also while in PH, if a burst of wind pushes the unit quickly, it wont fight to get back, but rather will lock into the new location.

I suspect this might have something to do with the spike filter. Maybe its already calculating for spikes, and when PH is activated, it is part of the average as a new location. Also with the wind bursts quickly locating the unit, it probably sees this as a GPS spike as well.

Any other time, the PH was good and fought to maintain position very well in the wind, excluding the wind bursts. My wind is 10KM/H to 45KM/H but I had a bit of shelter as I flew behind a fence to cut down some of the wind. This however also creates more turbulence as well.

I had an elevation issue due to the different quad I am flying, I have not covered the barometer yet. But even in the wind, elevation deviation was only 1M.

UPDATE: Have now reverted to TestCode3 and re-calibrated quad, just waiting for a time I am able to re-test under same conditions. I will update my results to compare.

strips · Post by **strips** » Fri Apr 11, 2014 8:25 am

Crashpilot1000 wrote:@strips: Thx for your feedback.
When GPS PH is absolutely not working I would check 2 things first (besides the obvious LAT/LON feedback).
1. Proper calibrated Mag / proper mag declination.
2. Nick/Roll being neutral when released and well within the Deadband.

Concerning your not landing stuff. Did you adjust your PWM Throttlerange?
esc_min = 1100 (Value where all motors run with their lowest speed)
esc_max = 1950 (Maximal Motorvalue)
esc_moff = 1000 (Value where motors don't turn -> that value is send in disarmed state)
esc_nfly = 1300 (Value where Copter gets "light" but can not fly. You can put in "0" as well but then a 5% value of the throttlerange is assumed.

Concerning the Ublox Autoconfiguration. The original multiwii config block is sent + setting pedestrian mode.
Refer here:
http://code.google.com/p/multiwii/sourc ... PS.cpp#231
and
https://github.com/Crashpilot1000/TestC ... _gps.c#L28

Will check what you are mentioning. Both acc and mag have been calibrated. I have to verify esc_moff and esc_nfly.

Mr-Fiero wrote:...
Also, you might want to make sure sonar is turned off, and use sonar for landing is probably set to 1.
...
I usually just make sure its off and set the use sonar for landing to 0 to be sure.

... and change my angle of horizon to 8 degrees because of the stronger signal strengths (more sats in view PDOP way better).

I will check sonar setting.
What do you mean angle of horizon? Didn't know you could limit horizon mode.

Mr-Fiero wrote:I have not covered the barometer yet. But even in the wind, elevation deviation was only 1M.

Wow! Impressive. So there is nothing shielding the baro?

Thanks guys! You are great.

PS. I need more feet for my mini quad. Thin alu standoffs bend to easily. Need something that bounces. (nylon standoffs just break)

doppler · Post by **doppler** » Fri Apr 11, 2014 12:51 pm

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

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

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

Thanks the above was quite handy, I run Debian Linux so had a harder time finding the proper gcc and ended up with;

gcc-4.4-arm-linux-gnueabi

When I do the git clone and make however, I get to the linking stage where it stops with the error;

obj/NAZE/startup_stm32f10x_md_gcc.o: In function `LoopFillZerobss':
(.text.Reset_Handler+0x36): undefined reference to `__libc_init_array'
collect2: ld returned 1 exit status
make: *** [obj/baseflight_NAZE.elf] Error 1

Google has several suggestions for resolving this, but none specific to building this software, was wondering if anyone had a specific fix before I take a stab at the suggested ones.

Thanks
Andrew

DIE_KUH · Post by **DIE_KUH** » Sat Apr 12, 2014 12:48 am

I had the same linker error under Ubuntu when I tried to use gcc-arm-linux-gnueabi, like Mr-Fiero described.

Using another toolchain worked though (https://launchpad.net/~terry.guo/+archive/gcc-arm-embedded):

Step1: Inside Ubuntu, open a terminal and input
"sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded"

Step2: Continue to input
"sudo apt-get update"

Step3: Continue to input to install toolchain
"sudo apt-get install gcc-arm-none-eabi"

Then just clone the repo:

git clone https://github.com/Crashpilot1000/TestCode4.git

Enter the Testcode4 folder and "make".

Now I just need my new motors for the Flip 360 so I can test it with the Naze5 and Harakiri...

Mr-Fiero · Post by **Mr-Fiero** » Sat Apr 12, 2014 1:19 am

OK, another flight in the wind with TestCode3 and different results than TestCode4 on the quad with no baro foam. (I have to do this soon.)

I dont get the drift when PH is activated. Locks in right away, in wind deviation for PH was within .25M and held position really well in winds 5KM/H to 20KM/H. Also I did not have the position drift when a burst re-positioned the unit. It would try to go back to the original position when first activated PH.

I think now the spike filter in the TestCode4 does have some differences in performance. This is not to say it wont work, I just think when you first activate PH, the spike filter takes a second to gather averages, but it places the PH position slightly off where it was activated. (this was also my reason why I felt PH always moved and at first posts I would de-activate thinking it was not working) Also in flight if your position is changed beyond a certain threshold quickly (large burst of wind), the spike filter considers it a spike and averages to new physical location and then holds again.

Mr-Fiero · Post by **Mr-Fiero** » Sat Apr 12, 2014 1:30 am

> DIE_KUH

Excellent, I like that toolchain! you found a better working repo and its simple. Thank You.

copterrichie · Post by **copterrichie** » Sat Apr 12, 2014 1:50 am

Have anyone successfully used Eclipse to edit and compile the code?

thanks in advance.

strips · Post by **strips** » Sat Apr 12, 2014 7:13 am

A quick question about telemetry and Harakiri. I have never been able to get it working with Baseflight either.

I set tele_prot = 1 and connect to the dedicated telemetry port on Naze32 v5. Rx on Naze to TX on reciever and gnd to gnd. I have now tried two recievers. D8R-XP and D4R-II. I absolutely nothing changes in Taranis telemetry views.

timecop · Post by **timecop** » Sat Apr 12, 2014 5:57 pm

'dedicated telemetry port' on r5 goes to RX on receiver, no?

KC_703 · Post by **KC_703** » Sat Apr 12, 2014 8:19 pm

timecop wrote:'dedicated telemetry port' on r5 goes to RX on receiver, no?

Correct. The FC is sending telemetry back to the Taranis via the D4R. So pin on the FC is Tx as timecop says... which needs to be connected to Rx on the D4R.

strips · Post by **strips** » Sat Apr 12, 2014 8:21 pm

timecop wrote:'dedicated telemetry port' on r5 goes to RX on receiver, no?

Yup. A typo. TX on Naze goes to RX on receiver. Anyways I have tried to switch tx/rx on reciever with no luck.

timecop · Post by **timecop** » Sun Apr 13, 2014 3:14 am

Telemetry needs arming before data is sent.

strips · Post by **strips** » Sun Apr 13, 2014 8:07 am

timecop wrote:Telemetry needs arming before data is sent.

Nothing changes in telemetry after arming. Did some more testing yesterday evening. Even tried flashing a FAI choice fw on the Taranis but still no telemetry after verifying FAI choice is off.

strips · Post by **strips** » Sun Apr 13, 2014 10:57 pm

Flight test alt-hold and PH - TestCode3

Alt-hold was awesome in relative gusty winds. Even flying pretty agressive in Angle-mode it went from 4m to 2m before stabilizing again. Flying calmly it stayed within 1m.

I had 9 blinks in GPS. 14 satellites! Enabling PH it was rock steady for 3-6 seconds and it started drifting and then flying away. Aborted after 3-4m fast flyaway. Repeated this 3 times. I have a feeling it was the mag causing problems. Either I have a bad calibration or mag is under the influence

But I messed up and broke a prop before I could recalibrate. Was supposed to get some new props from Flyduino on Friday but they were delivered to the wrong post office! Hopefully I can test more tomorrow

Any tips or good videos how to do mag calibration?

All changed settings from default:
Enabled features: PPM VBAT GPS
rc_mid = 1502
tele_prot = 1
al_barolr = 25
gps_type = 4
gps_lag = 600

RC midpoints:

strips · Post by **strips** » Mon Apr 14, 2014 9:28 am

Hmm.. I think I might have forgot to set my magnetic declination after a reset.

Testing a few apps for my magnetic declination.
Geomagnetic field (Android app): 2deg 26.6min
Earth geomagnetic field values (android app): 2.31795 -> 2deg 19.077012min
http://magnetic-declination.com/: 2deg 20min

How big impact are those differences?

Now I have set mag declination to 220 and re done mag calib. Waiting for new props!

Code: Select all

# status

System Uptime: 73 sec, Volt: 111 * 0.1V (3S battery)
CPU 84MHz, detected sensors: ACC BARO MAG GPS
Cycle Time: 3022, I2C Errors: 0

EEPROM:
Total : 2924 B FreeFlash: 148 B
Config: 584 B
Floppy: 2340 B, 0 Datasets of 146 possible

SENSORS:
Gyro MPU
Actual
X Offset: -67
Y Offset: 14
Z Offset: 31
Fallback
X Offset: -67
Y Offset: 14
Z Offset: 30
Temp: 37

Acc MPU6050
Status: calibrated
X Offset: -3
Y Offset: -6
Z Offset: 733
1G val: 2048

Mag HMC5883
Status: calibrated
X Offset: -372
Y Offset: -1042
Z Offset: -375
X Gain*1000: 1000
Y Gain*1000: 1000
Z Gain*1000: 1000
Gain NOT OK

Baro MS5611
Temp: 35

STATS:
GPS:
Max Dist: 0 m
Max Speed: 0cm/s = 0Km/h
Hight:
Max Alt AGL: 0 m
Min Alt AGL: 0 m
Motor:
Actual Range: 1100 - 1950 at 400 Hz PWM.
No Stats

strips · Post by **strips** » Mon Apr 14, 2014 6:03 pm

Not good at all.

Tested a few flights with the new gemfan 5030 3-blade props. Rate was the only mode I dared fly. Even that was not pleasant. I do not know if excessive vibrations can cause sudden 90 plus degree yaw turns or if the mag is way off.

I have not checked the props in a balancer but that's my next step.

OleJohan · Post by **OleJohan** » Mon Apr 14, 2014 8:19 pm

strips wrote:
timecop wrote:Telemetry needs arming before data is sent.

Nothing changes in telemetry after arming. Did some more testing yesterday evening. Even tried flashing a FAI choice fw on the Taranis but still no telemetry after verifying FAI choice is off.

Have you tried to start logging to SD card on your Taranis. I got it to work when I did that.

Mr-Fiero · Post by **Mr-Fiero** » Tue Apr 15, 2014 2:30 am

strips wrote:Not good at all.

Tested a few flights with the new gemfan 5030 3-blade props. Rate was the only mode I dared fly. Even that was not pleasant. I do not know if excessive vibrations can cause sudden 90 plus degree yaw turns or if the mag is way off.

I have not checked the props in a balancer but that's my next step.

try flying with mag off to find out where the issue is.

If it still does that jump in yaw, then you can rule out mag. check esc calibration, and then make sure your motors are same speed with the motor test either via CLI or GUI.

Crashpilot1000 is right, mag is needed for GPS functions, so to be more clear, I was suggesting mag off only in stabilize so you can find your yaw issue, but if its an issue in GPS modes, then its a different problem and it will be related to your mag. If you are not using GPS functions and have sudden yaw, it is due to motor speed, and can be a blade flutter dragging the speed of a motor (very bad blade, or very bad balance), or the motor its self dropping in speed due to either ESC, Motor issues, ESC supply (Bullets) or anything that will cause a sudden change in motor RPM.

I have a couple of machines some of witch have no vibration dampening but the Harakiri is very forgiving.(i think being 32bit helps with the filters also) If ever I think I have an issue with vibration, I lower the lpf to 20 for testing and if it clears things up then I start reducing vibrations and raise the lpf back up as far as it will go and still fly without jitter. If you have to you can even set lpf to 10 just for testing.

Mr-Fiero · Post by **Mr-Fiero** » Wed Apr 16, 2014 7:12 pm

My latest tests were in the wind again but I had good success with Testcode3.

I waited for the GPS to settle with 8-9 satts (cloudy weather). When I activated PH it locked right away, each time. Each time it held position within .5Meters and with a burst of wind it was 1M max.

I tested PH for a total of 4 batteries and had very good success. The only reason why I quit testing is because I had a motor fall apart.... the shaft dropped from the bottom of the motor, but I was really low to the ground and flying above long dried grass and it landed softly. That will teach me to try really cheapo motors off ebay. Another lesson that anything can happen.

Now I think I am going to reflash Testcode4 and try again to see the differences.

hinkel · Post by **hinkel** » Sun Apr 20, 2014 7:43 pm

Hi Crashpilot1000 !
I like your Harakiri failsafe it is very fine !

Crashpilot1000 · Post by **Crashpilot1000** » Tue Apr 22, 2014 7:26 pm

Hi! Just wanted report back after my easter vacation! Thanks for the feedback and the video! I think strips you have some nasty vibrations going on. Don't bolt the FC directly to the frame. I always use 3-4 strips of doublesided foamtape stacked in every corner of naze (no special brand from the hardwarestore, just the cheapest roll I could find.). I never had 3 bladed props but imagine balancing them might not be easy. The code is more vibration sensitive. You can reduce acc trouble by reducing acc_lpfhz (= 10 Hz is default) you can reduce it down to 1Hz (try 5, 2 and 1Hz to see if that solves your trouble). Doing so will make angle/horizon much more vibration resistent but it will slow down finding the horizontal plane. In another thread I read about Harakiri killing off flightcontrols, well I have 3 (Nz3+4 and MW32v2) FC at work and all are fully operational without unhealthy heating of parts. Concerning the mag declination. The HMC has a resolution of 1-2 degree. A correct magdeclination is important but no need to go overprecise with that subject - however having undisturbed magfunction is vital.
Cheers Rob

subaru4wd · Post by **subaru4wd** » Tue Apr 22, 2014 8:13 pm

Rob.

I recently had to switch to Baseflight to get the OSD Switch.

Will harakiri adopt the OSD switch function? I would really like to go back to Harakiri and see about getting a functional Return to Home.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Apr 22, 2014 9:26 pm

But there is an OSD SW checkbox. Hinkel pointed that out some time ago and suggested a fix. So the checkbox is not recognized by osd? If that is the case it must be a protocol thing. Currently I am picking up where I stopped before vaction. I will look at the OSD repos and mwii protocol what is expected to turn on/off osd.

subaru4wd · Post by **subaru4wd** » Tue Apr 22, 2014 10:02 pm

sorry, i should have stated this was with SummerGames 2.5

I havent ran any of your other code.

subaru4wd · Post by **subaru4wd** » Fri Apr 25, 2014 6:53 pm

Okay, i am having one hell of a time getting my GPS to work with Baseflight.

Rob, where can I find some of your latest code to run?

Crashpilot1000 · Post by **Crashpilot1000** » Sun Apr 27, 2014 10:26 am

Hi, Subaru. Testcode4 is currently the last uploaded code. I have something newer at hand right now but weather stops me from GPS testing (rain or bad gps conditions or both ...). There are also a few other things implemented. I think I have some nice addition for the multicopter mixing part concerning behaviour in full throttle situations. Testing suggests it's nice

- stuck to non-float operations so maybe that will be a very nifty addition for 8bit mwii as well since it also makes the copter much more cooperative/recoverable in out of whack PID oscillations. Basically it's just a compression of the range if the calculated PWM range overshoots. Multiwii does a substraction of the overshoot, wich I think is a smart move and a very good idea but I thought hey, let's see what a scaling of the range will do in those situations. Haven't played with TPA / have no flight experience with TPA on my copters but I guess TPA users have a good chance of reducing it.

strips · Post by **strips** » Sun Apr 27, 2014 11:50 am

Crashpilot1000 wrote:Hi! Just wanted report back after my easter vacation! Thanks for the feedback and the video! I think strips you have some nasty vibrations going on. Don't bolt the FC directly to the frame. I always use 3-4 strips of doublesided foamtape stacked in every corner of naze (no special brand from the hardwarestore, just the cheapest roll I could find.). I never had 3 bladed props but imagine balancing them might not be easy. The code is more vibration sensitive. You can reduce acc trouble by reducing acc_lpfhz (= 10 Hz is default) you can reduce it down to 1Hz (try 5, 2 and 1Hz to see if that solves your trouble). Doing so will make angle/horizon much more vibration resistent but it will slow down finding the horizontal plane. In another thread I read about Harakiri killing off flightcontrols, well I have 3 (Nz3+4 and MW32v2) FC at work and all are fully operational without unhealthy heating of parts. Concerning the mag declination. The HMC has a resolution of 1-2 degree. A correct magdeclination is important but no need to go overprecise with that subject - however having undisturbed magfunction is vital.
Cheers Rob

Thanks. I will give it a new go soon. I just got a set of Himodel 5x4.5x3 props to test. They are much more balanced than the gemfans. And they're thick and stiff enough to sand for balance.

I have mounted the Naze32 on rubber rubber stands. So my first priority is stable and smooth rate mode.

Do you have a link for TestCode4? I believe I'm running TestCode3 which you had in a post earlier.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Apr 27, 2014 1:54 pm

You can stick to TestCode3 and wait a little for the next version. I attach here the compiled version of TestCode4 from the repo.
Cheers Rob.

subaru4wd · Post by **subaru4wd** » Sun Apr 27, 2014 6:16 pm

I use TPA, it works great to get rid of high throttle oscillations.

I cant find your repo, i think i found it but last updates were months ago?

Where do we go to get testcode3?

strips · Post by **strips** » Sun Apr 27, 2014 7:04 pm

subaru4wd wrote:
Where do we go to get testcode3?

In this post: viewtopic.php?p=48650#p48650

subaru4wd · Post by **subaru4wd** » Sun Apr 27, 2014 7:24 pm

strips wrote:
subaru4wd wrote:
Where do we go to get testcode3?

In this post: viewtopic.php?p=48650#p48650

Ahh yes, there it is. Im sick of using Forums as a repo. Was hoping there would be a wiki, or at the very least a compiled .hex somewhere on the github or google code or whatever people use these days.

Thanks Strips

Dilbert66 · Post by **Dilbert66** » Sun Apr 27, 2014 8:07 pm

github with change control is the better way. Interested folks can even see what has changed from version to version normally. They can clone the project and be able to follow it's development and even contribute if they so desire and the project lead is open to it. The project would then be nourished from multiple minds working on the issues at hand. With this project, I'm confused. Obviously it's a one person work which is fair enough but for group dev it's not going to work very well as it is.

strips · Post by **strips** » Sun Apr 27, 2014 8:58 pm

Sweet smoothness! I just balanced my new props. Rate mode was smooth. Angle was smooth except it yawed a bit in a fast wobbly decent. Alt-hold was perfect! Kind of weird I newer got enough sats to engage pos-hold after 5 minutes in clear weather. But it has been over a week since the GPS was powered last.

timecop · Post by **timecop** » Mon Apr 28, 2014 11:03 am

Dilbert66 wrote:github with change control is the better way. Interested folks can even see what has changed from version to version normally. They can clone the project and be able to follow it's development and even contribute if they so desire and the project lead is open to it. The project would then be nourished from multiple minds working on the issues at hand. With this project, I'm confused. Obviously it's a one person work which is fair enough but for group dev it's not going to work very well as it is.

That's like beating a dead horse.
The reason this fork is garbage is because of the repeated delete-repository-and-reupload-shit-on-each-release.
Already been mentioned a million times, so just let it be. Nothing of value to see here anyway.

strips · Post by **strips** » Mon Apr 28, 2014 8:47 pm

Still on testcode3 I got perfect gps and alt hold!

I'm only touching the RX to change altitude a couple of times.
http://youtu.be/Ki7uO1kyFsA

This was under perfect conditions. No wind. Only bloody mosquitoes! Huge monsters.

strips · Post by **strips** » Mon Apr 28, 2014 9:45 pm

I got asked about my setup so I'll post it here.

Most of my general unstability problems were due vibrations. Got some new props I where able to balance properly it flies like a dream.

Code: Select all

# dump
Config:
FW: HarakiriSG pre2.6 TestCode3Mar 31 2014 / 18:35:35
ID|AUXCHAN : 01   02   03   04  
00|ANGLE   : --H  ---  ---  --- 
01|HORIZON : -M-  ---  ---  --- 
02|BARO    : ---  --H  ---  --- 
03|MAG     : ---  -MH  ---  --- 
04|CAMSTAB : ---  ---  ---  --- 
05|ARM     : ---  ---  -MH  --- 
06|GPS HOME: ---  ---  ---  --H 
07|GPS HOLD: ---  ---  --H  --- 
08|GPS AUTO: ---  ---  ---  --- 
09|PASSTHRU: ---  ---  ---  --- 
10|HEADFREE: ---  ---  ---  --- 
11|BEEPER  : ---  ---  ---  -MH 
12|HEADADJ : ---  ---  ---  --- 
13|OSD SW  : ---  ---  ---  --- 
Current mixer: QUADX
Custom mixer: 
Motor   Thr   Roll   Pitch   Yaw
Sanity check:   OK   OK   OK   
Enabled features: PPM VBAT GPS 
Current assignment: AETR1234
Current settings: 
rc_db = 20
rc_dbyw = 20
rc_dbah = 50
rc_dbgps = 5
rc_trm_ptch =  0.000
rc_trm_rll =  0.000
rc_minchk = 1100
rc_mid = 1502
rc_maxchk = 1900
rc_lowlat = 1
rc_rllrm = 0
rc_killt = 0
rc_flpsp = 0
rc_motor = 0
rc_auxch = 4
rc_rate = 100
rc_expo = 80
thr_mid = 50
thr_expo = 0
roll_pitch_rate = 0
yawrate = 0
devorssi = 0
rssicut = 0
esc_min = 1100
esc_max = 1950
esc_nfly = 1300
esc_moff = 1000
esc_pwm = 400
srv_pwm = 50
pass_mot = 0
fs_delay = 10
fs_ofdel = 200
fs_rcthr = 1200
fs_ddplt = 0
fs_jstph = 0
fs_nosnr = 1
serial_baudrate = 115200
tele_prot = 1
spektrum_hires = 0
vbatscale = 110
vbatmaxcellvoltage = 43
vbatmincellvoltage = 33
power_adc_channel = 0
tri_ydir = 1
tri_ymid = 1500
tri_ymin = 1020
tri_ymax = 2000
tri_ydel = 0
wing_left_min = 1020
wing_left_mid = 1500
wing_left_max = 2000
wing_right_min = 1020
wing_right_mid = 1500
wing_right_max = 2000
pitch_direction_l = 1
pitch_direction_r = -1
roll_direction_l = 1
roll_direction_r = 1
gbl_flg = 1
gbl_pgn = 10
gbl_rgn = 10
gbl_pmn = 1020
gbl_pmx = 2000
gbl_pmd = 1500
gbl_rmn = 1020
gbl_rmx = 2000
gbl_rmd = 1500
al_barolr = 25
al_snrlr = 50
al_debounce = 5
al_tobaro = 2000
al_tosnr = 1000
as_lnchr = 200
as_clmbr = 100
as_trgt = 0
as_stdev = 10
align_gyro_x = 0
align_gyro_y = 0
align_gyro_z = 0
align_acc_x = 0
align_acc_y = 0
align_acc_z = 0
align_mag_x = 0
align_mag_y = 0
align_mag_z = 0
acc_hdw = 2
acc_lpfhz =  10.000
acc_altlpfhz = 10
acc_gpslpfhz = 15
gy_lpf = 42
gy_gcmpf = 700
gy_mcmpf = 200
gy_smrll = 0
gy_smptc = 0
gy_smyw = 0
gy_stdev = 5
accz_vcf =  0.985
accz_acf =  0.960
bar_lag =  0.300
bar_dscl =  0.700
bar_dbg = 0
mag_dec = 220
mag_time = 1
mag_gain = 0
gps_baudrate = 115200
gps_type = 4
gps_ins_vel =  0.600
gps_lag = 600
gps_ph_minsat = 6
gps_expo = 20
gps_ph_settlespeed = 10
gps_maxangle = 35
gps_ph_brakemaxangle = 15
gps_ph_minbrakepercent = 50
gps_ph_brkacc = 40
gps_wp_radius = 200
rtl_mnh = 0
rtl_cr = 80
rtl_mnd = 0
gps_rtl_flyaway = 0
gps_yaw = 30
nav_rtl_lastturn = 1
nav_speed_min = 100
nav_speed_max = 350
nav_approachdiv = 3
nav_tiltcomp = 30
nav_ctrkgain =  0.500
nav_controls_heading = 0
nav_tail_first = 0
stat_clear = 1
gps_pos_p = 10
gps_pos_i = 40
gps_pos_d = 0
gps_posr_p = 70
gps_posr_i = 0
gps_posr_d = 100
gps_nav_p = 15
gps_nav_i = 0
gps_nav_d = 0
looptime = 3000
mainpidctrl = 0
maincuthz = 12
gpscuthz = 45
p_pitch = 35
i_pitch = 30
d_pitch = 30
p_roll = 35
i_roll = 30
d_roll = 30
p_yaw = 60
i_yaw = 45
d_yaw = 0
p_alt = 100
i_alt = 30
d_alt = 80
p_level = 70
i_level = 10
d_level = 50
snr_type = 3
snr_min = 30
snr_max = 200
snr_dbg = 0
snr_tilt = 18
snr_cf =  0.500
snr_diff = 0
snr_land = 1
LED_invert = 0
LED_Type = 1
LED_pinout = 1
LED_ControlChannel = 8
LED_ARMED = 0
LED_Toggle_Delay1 = 8
LED_Toggle_Delay2 = 8
LED_Toggle_Delay3 = 8
LED_Pattern1 = 1300
LED_Pattern2 = 1800
LED_Pattern3 = 1900

subaru4wd · Post by **subaru4wd** » Mon Apr 28, 2014 10:00 pm

I flashed TestCode3 today and letting the quad sit for a few minutes outisde, I finally got a GPS lock.

Tracking 10 sats in my house. I might get a chance to do some test hovers in the front yard soon.

alistairr · Post by **alistairr** » Thu May 01, 2014 3:24 pm

Hey Strips. Is your mini quad using sonar as well? That test code 3 looked pretty locked in.

strips · Post by **strips** » Thu May 01, 2014 4:20 pm

alistairr wrote:Hey Strips. Is your mini quad using sonar as well? That test code 3 looked pretty locked in.

No sonar. Only perfect flying conditions. I haven't been able to replicate that kind of precision again. In windy conditions it actually drifts 1-2m down before settling altitude. And 3-5m horizontally before halting and slowly inching itself back to where it's supposed to be.

Mr-Fiero · Post by **Mr-Fiero** » Thu May 01, 2014 10:49 pm

Here is an update. Finally nicer weather! Very welcome after a nasty long winter......

With Testcode4 I never got a good lock on the GPS. I even tried more aggressive settings and it does not hold position well. I even had it still try to drift to the right, but I think its because my trims were out and it seems that when PH is activated, it is even more delayed or worse, in testcode4. I keep having to switch PH back and recover as it just does not hold, but having wind does not give me as much time to lock.

But, even trying to compensate for the delays, It still does not perform like I am able to do in testcode3.

To confirm this, I reflashed testcode3 and it worked right away. I had to change my settings back as it was too sensitive. I flew testcode3 on my test unit for a total of ten batteries 4400mah each for 15minutes per batt. ( 80 % drain ) Every test was perfect, and I have only .25M altitude variations.

This unit I have the 35mm ceramic active antenna on the NEO6 GPS engine, and the GPS is rejecting angle to horizon at 8 degrees. its running 8hz update at 115200 buad.

I have perfect locks and for a whole battery I only see maybe 1M drift MAX (Wind), but then it returns nicely. For the whole flight, It drifts only a couple of times for the entire 15 minutes of flight. Its very tight each and every time. 90-95 % of my flight is seriously within .5M MAX LONG/LAT. Altitude hold is also just incredible (yes i finally covered my baro ). My altitude for 90 % of my flights was within .5M max variation in the slight wind. Of course in the past I did tune my PID's for altitude hold so it helps now perform well.

One thing I did have to get used to is that if you re-position while in PH, you have to hold new position with your sticks ( if let go too soon, it tries to return to what seems to be the original postion ) and wait for the GPS to average the new position for a few seconds, then after that it holds again very nice.

I am still testing, but Testcode3 for me seems to be a better choice as it is working very well, even in the wind for GPS functions. When I was doing this last test the wind (as allways) was blowing, but it was only 10KM/h to maybe 25KM/h, so this was a calm day for me. The previous tests were in more aggressive wind.

I still have to test RTL and a few other modes, but I just wanted to be sure of the GPS first.

Crashpilot1000 · Post by **Crashpilot1000** » Fri May 02, 2014 9:30 am

Thank you very much for your feedback mr.fiero!
My gps development is currently a little blocked so i concentrated on mixer and althold stuff - so I really appreciate your gps - feedback!
Cheers
Rob

Mr-Fiero · Post by **Mr-Fiero** » Fri May 02, 2014 6:06 pm

Rob, I am so glad your firmware GPS functions work ! ....

I had an issue where my TX dropped power (bad connector in battery bay). The unit had to fly itself for about 5 minutes in a very tight space as I was flying between my power lines, and close to my roof. I had my OpenLRS failsafe set to PH as I have not tested the RTL yet.

Well, it worked perfectly and stayed away from a power line right beside my unit for the time my TX was down. It gave me time to remove battery cover, unplug, and tighten pins, and plug in power up, and take back control. Normally I dont fly in this tight area, but at the time I was taking pictures of my roof so I could inspect for any damage from winter months.

Awesome, usually in the past if anything like this would of happened it was a crash for sure, but I was so impressed at the performance. I usually worry the wind will push it, but it flew very nice in PH Failsafe, in the wind.

I should also mention, when I set my OpenLRS failsafe, I did it quickly but my radio did not have the ARM switch activated when I set the sticks. I didnt think about this at the time, but when I needed the failsafe, because you have it set that if PH is activated but ARM is not active, it ignores it and stays active while in PH. This worked well for me in this situation.

Colorado CJ · Post by **Colorado CJ** » Sat May 03, 2014 4:06 am

What GUI are you guys using with these firmwares. It seems every GUI I try is either buggy or plain does not work with the Harakiri or test code 3 firmware.

I finally got my scratch built quad all put together and would really like to use test code 3 to get GPS functionality.

Mr-Fiero · Post by **Mr-Fiero** » Sat May 03, 2014 4:11 am

I use BaseFlight GUI if I am looking for a quick tune or change on basic PID's but mostly I stay with the CLI. (multiwii 2.2 works too)

I do not like to use a GUI much because they do not follow code development and they usually are missing features/settings, especially with BETA firmwares! What is nice about the CLI, is I take my dumps, and add "set " to each line, and then can copy/paste into next controller for quick setup. Also having a dump to look at all the settings is really nice.

There is no gui that has all the settings, but the CLI does!

Mr-Fiero · Post by **Mr-Fiero** » Sat May 03, 2014 4:27 am

OK, today I flew in the rain turning to small hail. LOL I have a neighbour friend that is into multicopters, and he drove by while I was flying, he probably thinks I am crazy. :roll:

Anyways, I did notice something new, and I am sure its probably normal. Its related to the baro.

While flying, I had an 1M drop in altitude as soon as PH was activated 9 out of 10 times, but then it was holding altitude, with slightly more variation than my previous tests up to .5M each time. It was a slow variation, and would stick to new altitude. I suspect as the wind was about 10KM/h and with the rain turning to hail it was temperature differences on the baro. (spike filter on baro a good idea? or does it already have this in the code?)

Only today have I ever seen altitude with this much difference, but its not normal conditions so I am sure everything is good. I just wanted to post results under different conditions, thats all.

Well, I had a few flights with same results on baro. even though i was counting on the fact that rain was non conductive, I was pretty wet on my FC and had to bring it in to air dry it all. This is my test quad so its not critical, but I do not want to have it die too early. Its a flip32+ so the baro is under the FC and it was dry.

Crashpilot1000 · Post by **Crashpilot1000** » Sat May 03, 2014 5:41 pm

@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

hinkel · Post by **hinkel** » Sat May 03, 2014 10:15 pm

Hi Crashpilot1000 !
Because your Althold is very fine.
I am testing an automatik althold support. If you are flying and you don't move the throttle stick for 2000ms, althold is engage autonomously and
disable if throttle stick move more then deadband. The goal behind is to keep a stable altitude during flite and don''t move some switch. .

Code: Select all

cfg.al_suptime  = 2000; // 0 = disable // althold is engage autonomously after for ex: 2000 ms when throttle stick is not moving deadband Throttle = 60 
    cfg.al_deadsup                = 60;         // Throttle deadband when Althold support is use  
    cfg.al_maxthrsup              = 1790;       // Over this throttle value Althold support is disangage

It is like a poor man sonar , I don't know !

Regards
hinkel