Baseflight aka multiwii port to stm32

whakahere · Post by **whakahere** » Wed Mar 06, 2013 4:12 pm

Thanks guys. I do have a blue board as well ..... well the arco cause I never use baro, mag or all the other stuff. I just need gyro for flying ... the rest is just to fancy for my needs. Which of those two boards has the better FC? I haven't used the naze32 acro yet. I have already set looptime to 300 ... will I need to change acc_lpf if I never use level?

My quad is a full plastic. It a battle style .... for hard to the ground crazy flying. It does very well. I has plastic PVC pipe arms and coroplast center. Very stiff too. I changed the foam tape on the bottom of the FC with a different type (from 3M) much smoother now. I'll play around more later. First I need to fly.

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 4:25 pm

Well, just an FYI, I search postings on ebay while having my morning coffee and I have seen many many many flight controllers appearing (Junk), so why not quality? Could it be because they believe there is no market for quality? Just a thought. Oh and many of them are STM32. Hmmm.

copterrichie · Post by **copterrichie** » Wed Mar 06, 2013 4:30 pm

P.S. the Raspberry PI has EXPLODED!!

Crashpilot1000 · Post by **Crashpilot1000** » Wed Mar 06, 2013 5:06 pm

@whakahere: I understand your thinking because i thought the same before i started looking at the code. Why should i care about acc when i just fly acro?
Because the Acc values are used ALL the time to correct the gyro error (if acc is present)!! When you fly acro you use these corrected values. So set acc_lpf_factor = 100 to avoid that your Gyro is corrected with wacky acc values.

JollyJoker · Post by **JollyJoker** » Wed Mar 06, 2013 9:08 pm

hinkel wrote:Hi JollyJoker !

With Crashpilot recommended settings it should be fine too on Harakiri 9 , are you sure that you set gps_ins_vel = 0 and
gps_ins_pos = 1 your video look like you invert this parameters ?
To set it, use Multiwiiconf and Putty for the moment it will be safer than some clone software !

Greetings
hinkel

Thanks for having a look into it. I checked the parameters with putty once more, just to be sure, and it is like it has been suggested, gps_ins_vel = 0 and ..._pos = 1.

But I was not aware that I have to activate mag by myself (thougt it is part of the hold command)! Next test will be with full sensors :idea:

So allways good to talk about. That should give a more consistant hold?
The behavior at the field is exactly the same as on the table/balcony (given enough sat´s in view), sometimes the copter starts to travel some meters, then rest again and so on.

Have to test some different settings for all those parameters, to see what gives the best pos_hold.
Will also test pure baseflight again.

Regards Peer

hinkel · Post by **hinkel** » Wed Mar 06, 2013 10:29 pm

@ JollyJoker .

With Baseflight the GPS stuff works on my copter with default PID . Don't forget to calibrate Acc first
than mag " 30 seconds time for mag" .
For GPS PH you must activate Angle , Baro , Mag , GPS hold.
The Harakiri 9 GPS stuff with defaults settings is not faraway from Baseflight only gps_ins make the difference,
" I don't tell about the GPS Initialisation stuff from Crashpilot and other thinks I forget ......sorry

".

Also you can try Harakiri 9a follow this advice from Crashpilot:
Without a fix reported back, the gps functions are disabled. So i took the current mwii ublox parser and implemented it in harakiri9 and called it 9a. You can pick it up here http://fpv-treff.de/viewtopic.php?f=18& ... =80#p21784 (i will upload it here as well). Maybe JollyJokers' quad lost 3dfix but still had a 2Dfix and the gps functions bailed out temporarily then? Try 9a and do PID tuning. The default pids are suitable for my quad (60cm diagonal and 1,2Kg) but GPS Pid tuning is still a real pain. Since the gps logic is basically the same, you will have to use eos bandi's guide http://i2c-gps-nav.googlecode.com/files ... tation.pdf or the german translation http://www.wii-copter.de/forum/download ... l&df_id=24.
Always re - do MAG and ACC Calibration after FW upgrade!! It will take you just 1,5 Minutes!

Greetings
hinkel

brm · Post by **brm** » Wed Mar 06, 2013 10:53 pm

Crashpilot1000 wrote:@mr.sneezy: I attached a screenshot with my settings used in the videos here: http://fpv-treff.de/viewtopic.php?f=18& ... =40#p21395
When using gps i would recommend to combine: ACC, MAG and probably BARO. Dail in a decent P for the mag as well (4 is of no use anyway, try 10 or more).

hi,
can you write up your changes?
i am going to hook up a gps soon.
it would be helpfull to get more infos about what ypou did.

thanks!

Crashpilot1000 · Post by **Crashpilot1000** » Wed Mar 06, 2013 11:56 pm

@brm: I did the complete description last weekend here: http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20577 it is in german. It is written really uncomplicated so google translator shoud do it for now. ( http://translate.google.de/translate?hl ... 8%23p20577 ) Besides Mag calibration is extended to 60 sec now. Currently i am working on a brand new PH controller. So i don't want to waste time on a translation. Basically the gps functions are the same but they are called at >300Hz (original called at 5Hz) and the acc is implemented just to compensate between gps reads (that is preset in 9a). If you use NMEA GPS stay with a 5Hz firmware, 10Hz FW overload current gps and are just marketing hype. APM - MTK 3329 Binary protocol 1.6 and 1.9 are fully supported. Ublox binary protocol is fully supported with autoconfiguration. You can change the acc influence with the gps_ins parameters if you want more. I would suggest to gps pid tune the hell out of 9a and then start fiddeling with gps_ins parameters starting with gps_ins_vel. I will not do that because if my new PH controller idea works out, there will be basically just 2 core parameters left to tune for PH.
Cheers
Kraut Rob

timecop · Post by **timecop** » Thu Mar 07, 2013 1:23 am

Crashpilot1000 wrote:@whakahere: I understand your thinking because i thought the same before i started looking at the code. Why should i care about acc when i just fly acro?
Because the Acc values are used ALL the time to correct the gyro error (if acc is present)!! When you fly acro you use these corrected values. So set acc_lpf_factor = 100 to avoid that your Gyro is corrected with wacky acc values.

is this in your code?
because in default baseflight/multiwii, gyro only does really mean gyro only.

green/blue naze32s should be same, MPU3050, only accel on blues can be changed between ADXL345 and MMA (default).
If its the blue acroafro, then its mpu6050 and ADXL345. Sorry, too many different versions, but basically,
anything not white w/mag+baro = MPU3050+either adxl or mma accel
anything not white w/o mag = MPU6050
white = MPU6050+mma accel

brm · Post by **brm** » Thu Mar 07, 2013 12:18 pm

Crashpilot1000 wrote:@brm: I did the complete description last weekend here: http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20577 it is in german. It is written really uncomplicated so google translator shoud do it for now. ( http://translate.google.de/translate?hl ... 8%23p20577 ) Besides Mag calibration is extended to 60 sec now. Currently i am working on a brand new PH controller. So i don't want to waste time on a translation. Basically the gps functions are the same but they are called at >300Hz (original called at 5Hz) and the acc is implemented just to compensate between gps reads (that is preset in 9a). If you use NMEA GPS stay with a 5Hz firmware, 10Hz FW overload current gps and are just marketing hype. APM - MTK 3329 Binary protocol 1.6 and 1.9 are fully supported. Ublox binary protocol is fully supported with autoconfiguration. You can change the acc influence with the gps_ins parameters if you want more. I would suggest to gps pid tune the hell out of 9a and then start fiddeling with gps_ins parameters starting with gps_ins_vel. I will not do that because if my new PH controller idea works out, there will be basically just 2 core parameters left to tune for PH.
Cheers
Kraut Rob

i have no problem reading or writing düütsch - my compass declination is about 138.
for the mag calibration i prefer a least square method to find the center of the elipsoid.

the gps driver should create events - does not make sense checking input a million times a second...

what is your definition of a ph controler?

since maxwell there is nothing real new from a control law perspective.

pid tuning is simple - when having correct data the copter flies - no tuning required :idea:

cheers roberto

mr.sneezy · Post by **mr.sneezy** » Thu Mar 07, 2013 1:50 pm

hinkel wrote:@ JollyJoker .
For GPS PH you must activate Angle , Baro , Mag , GPS hold.

Greetings
hinkel

What happens if you don't have angle with PH ?
( I guess somebody has tried it).

What would happen if you have PH and RTH both active at the same time ???
Does it have a logic meltdown

Martin

timecop · Post by **timecop** » Thu Mar 07, 2013 2:19 pm

JollyJoker · Post by **JollyJoker** » Fri Mar 08, 2013 1:12 pm

mr.sneezy wrote:Guy's, not sure if I'm missed something, but I can't install TC's new HEX file from today. I get a message from the STM loader saying it can't use the file, and I've noticed the file size of the .HEX is 397Kb instead of around 150kb for previous versions.
I used the same 'save file as' method as previously to download the file.
Not sure where my problem lies ?

Thanks,
Martin

Why start offending others, if you are not able to download a single file from the internet by your own?

nicog · Post by **nicog** » Fri Mar 08, 2013 2:04 pm

mr sneezy, just use the latest aIO naze configurator for windows.
You can update with 2 clicks, first to get the latest firmware and the second to update the board. easiest is impossible

Crashpilot1000 · Post by **Crashpilot1000** » Fri Mar 08, 2013 7:24 pm

@timecop: Damn, you are right I was wrong! Acro really means gyro only i mixed it up with apm stuff. Thanks for clearing that!
@brm: Can you post your "least square method to find the center of the elipsoid" code? I am too stupid for that stuff. Besides i didn't mean to re-invent the principles of pid controllers. I mean by "doing a new PH Pid controller" i write a different one from the current. My progress is very good and the acc stuff really pays off now. And it really benefits from the speed of calculation. I am still fiddeling with variables but when it is done it will boil down to just 2 parameters for position hold (PH). I think it will be better than the current implementation, right now it isn't.
@mr.sneezy: With Harakiri9a angle mode is automatically turned on (horizon is turned off) when using a gps mode. When activating RTH and PH at the same time, RTH will be executed. So no logical meltdown is expected

.

One WARNING with Harakiri9a: When using feature pass, make sure your Transmitter is running, otherise the motors can power up with full throttle. I already fixed that (http://fpv-treff.de/viewtopic.php?f=18& ... 100#p22158) but it is still in the 9a!!! So use that feature with care!

General GPS Tip: While fiddeling with some parameters i found that nav_slew_rate = 30 (Default BF) is too much. The slew rate is some kind of lpf at the end of the whole gps output. It will smooth and delay the gps steering commands. Try lower values there. With my copter a value of 12 seems to be a good compromise between quick reaction and smoothiness.

Cheers
Kraut Rob

mr.sneezy · Post by **mr.sneezy** » Sat Mar 09, 2013 1:28 am

nicog wrote:mr sneezy, just use the latest aIO naze configurator for windows.
You can update with 2 clicks, first to get the latest firmware and the second to update the board. easiest is impossible

Thanks for that info, I've not been aware of that software, I've just been using the STM loader.
I sorted my file download problem days ago BTW, hope you were not one of the 'offended' :?:

Usually with hex or zip file links on web pages I just have to right click and 'save link as' to pull it down as a file, but in github what looks like a *.hex file link on the page actually opens another page, and that is not what I expected. Then there is a RAW link that gets the file like I'm used too with a 'save link as" in the following page (maybe it's a quirk with my current browser).
Regards,
Martin

mr.sneezy · Post by **mr.sneezy** » Sat Mar 09, 2013 1:37 am

Crashpilot1000 wrote:@mr.sneezy: With Harakiri9a angle mode is automatically turned on (horizon is turned off) when using a gps mode. When activating RTH and PH at the same time, RTH will be executed. So no logical meltdown is expected .

Cheers
Kraut Rob

Hi Rob. I haven't tried Harakiri9 yet, I guess partly because Baseflight has been very good for me so far, and partly because of the rapid changes in Harakiri9. I guess I'm being a bit too cautious because I don't get much time work on the quad.
Sounds like version 9a is what you'd say is the 'stable' version currently ?

BTW Rob what is the meaning of 'Harakiri' if it has one ?

Cheers,
Martin

Crashpilot1000 · Post by **Crashpilot1000** » Sat Mar 09, 2013 3:18 am

Hi, mr.sneezy!
First of all, there is no need for you to change your current BF is everything is working fine for you and you don't want to have other features like a RTL hight.
The 9a is working for me without any surprises. It is solid and i wouldn't expect drawbacks from current BF. I implemented some security features to prevent your copter flying to bonanza. If the code smells something fishy it will bail out and fall back to angle mode and do autoland if in failsave mode. The feature pass could be trouble if your transmitter is turned off (see WARNING).
I described, why it is called harakiri in german here: http://fpv-treff.de/viewtopic.php?f=18& ... 578#p20576. My primary work was done on mwii (althold) but i started to port it to naze without having the hardware. Since i have black humor and the hardware is from TC/Japan i called it harakiri. I hope Japanese people are not offended by this. My first version had an endless loop at the beginning and didn't start at all the second version destroyed some propellers ... than my naze arrived and the harakiri - days were over - except for the feature pass thing.
Perhaps another name is more suitable? I don't know what it should be - banzai, samurai, sushi, Schnitzel? Plain numbers are so boring. Anyway i just post my stuff here as well, perhaps it is of use for somebody or inspire someone.
Cheers Kraut Rob

mr.sneezy · Post by **mr.sneezy** » Sat Mar 09, 2013 10:40 am

Hi Rob,

Thanks for your reply, they always are good on details.
Can I extract some more ?

Is what you referred to as RTL the same thing as RTH ?

Falisafe is not something I've setup yet. How do you implement yours ?
I set the RX failsafe to 'throttle off' on the quad, but I can also set the RX to send no PPM instead, or is there a better way ?

I like the Harakiri name, can't see a need to change it really...

Regards,
Martin

Crashpilot1000 · Post by **Crashpilot1000** » Sat Mar 09, 2013 4:54 pm

@mr.sneezy: I always mix RTL (return to launch) and RTH (return to home) up when writing. They are synonyms. If your receiver supports a failsafe setting it is a good idea to set it up in the first place. I also did it with my frsky system. All sticks to center, except throttlestick (full down), set your RTL switch to on and save these settings in your RX (frsky: short press of the rx bind button - followed by a beep on tX). If the satfix is lost, it will autoland. If your RX dies in the air the naze failsafe will only be engaged if it was set before in cli with "feature failsafe" (don't forget "save"). My naze failsafe covers different situations depending on the onboard sensors. Check out my manual. Without at least a baro (autolanding) you will have to setup/check some other parameters (throttle and timeout stuff).
Greetings Rob

mr.sneezy · Post by **mr.sneezy** » Sun Mar 10, 2013 7:08 am

Thanks Rob,

I am still using the 'motor stop' feature on my board, if failsafe is set to throttle stick down will the quad still do a RTH, or will it fall out of the sky ?
(I'm thinking it's time to use the motor-run at arm method, if that's a better way to go for failsafe).

Your manual ?
Is there a link you could post to it ?

Thanks,
Martin

Gimbal · Post by **Gimbal** » Sun Mar 10, 2013 10:29 am

having trouble with naze32 gui can't change gps type (stay's at 0) and baud rate fix't to 38400, am i missing some thing? and i don't see gps in mw win gui, i can select typ of multirotor set ppm, gps etc

Gimbal · Post by **Gimbal** » Sun Mar 10, 2013 11:16 am

fix't it, latest naze32 gui ;-)

Crashpilot1000 · Post by **Crashpilot1000** » Sun Mar 10, 2013 3:24 pm

@Gimbal: These new gui's are def. a step in the right direction but depending on nazefw they can lead to trouble. Always check crucial things with cli (realterm/putty).

@mr.sneezy: feature motor_stop is no issue, because the althold controller takes over your throttlestick before this motorstop-check is done in the mixer.c. So it will see a normal throttlesignal - till touchdown. Your copter will not fall out of the sky if the baro is engaged (like in failsafe or rtl/rth) - i tested it. The "manual" is always here in german: http://fpv-treff.de/viewtopic.php?f=18& ... 578#p20577 .... google translator will do some funny stuff with it but it should be understandable..
Greetings Rob

jingej · Post by **jingej** » Sun Mar 10, 2013 3:38 pm

but you have to activate alt-hold before you pull back throttle for autoland - or else......

mr.sneezy · Post by **mr.sneezy** » Mon Mar 11, 2013 9:23 am

This might be a dumb question in these circles, but is a good check of mag orientation as simple as the checking the MultiWii GUI display compass points dead on North while I hold the quad true north (gauged by satellite maps) ??
I know there is a setting for local declination, but my mag board can be rotated at will, so I guessed that if I turn it to indicate North on the GUI I'd be setting it right, or maybe not...
Martin

crazylittle · Post by **crazylittle** » Mon Mar 11, 2013 9:27 pm

Is the NAZE32AIO-[2012-10-20].rar the latest one or is somebody else adding patches? I've bumped into a few gui crashes here and there.

nicog · Post by **nicog** » Mon Mar 11, 2013 9:30 pm

no one other than the guy who did it have patched that. And i believe that that is the latest one. What are the errors you are getting?

crazylittle · Post by **crazylittle** » Mon Mar 11, 2013 9:36 pm

I don't have the error in front of me but it was when I was trying to setup openaero32 on a naze32 board using the AIO gui. When you go into the CLI and try to set the new var's that happysundays added it crashed loading the list.

mahowik · Post by **mahowik** » Mon Mar 11, 2013 9:48 pm

Crashpilot1000 wrote:General GPS Tip: While fiddeling with some parameters i found that nav_slew_rate = 30 (Default BF) is too much. The slew rate is some kind of lpf at the end of the whole gps output. It will smooth and delay the gps steering commands. Try lower values there. With my copter a value of 12 seems to be a good compromise between quick reaction and smoothiness.

Hi Rob,

I also started investigate GPS mwii code. You are right nav_slew_rate it's factor for lpf on output BUT you made LPF stronger with decreasing this coef.

E.g. with 30 value (comparing with 12) you will have more wide range (in constrain) to increase result. As result with 30, lpf will be more lite...

Code: Select all

if (cfg.nav_slew_rate) {
                    nav_rated[LON]  += constrain(wrap_18000(nav[LON] - nav_rated[LON]), -cfg.nav_slew_rate, cfg.nav_slew_rate); 
                    nav_rated[LAT]  += constrain(wrap_18000(nav[LAT] - nav_rated[LAT]), -cfg.nav_slew_rate, cfg.nav_slew_rate);
                    GPS_angle[ROLL]  = (nav_rated[LON] * cos_yaw_x - nav_rated[LAT] * sin_yaw_y) / 10;
                    GPS_angle[PITCH] = (nav_rated[LON] * sin_yaw_y + nav_rated[LAT] * cos_yaw_x) / 10;
                }

So you need to increase nav_slew_rate to get less smooth lpf and less delay in result...

Pls correct if i'm wrong here...

thx-
Alex

Crashpilot1000 · Post by **Crashpilot1000** » Mon Mar 11, 2013 10:30 pm

Heheh, yes i see that too, NOW.... a lower value will constrain more and reduce the over all change with each iteration

. It boils down to this
filtered = filtered + constrain(newdata - filtered), -slew_rate, slew_rate) so the higher "slew_rate" the more change is possible.
Thank you very much for clearing that!!
Meanwhile i disabled it anyway and replaced it with an own testfilter - i should have looked closer before deletion!
Greets Rob

mahowik · Post by **mahowik** » Tue Mar 12, 2013 3:35 am

I have played with rotation matrix from harakiri9. At first I can say that all signs and axises are on the place! Cool and thanks a lot!
Some times ago I already tried to find all signs but had an error at least for global Z axis... So now it works fine! And you can replace accZ calculation in getEstimatedAltitude() to simplified and more rapid version from rotation matrix

Code: Select all

  acc_south = (cp * cy) * accLPFGPS[1] + (sr * spcy - cr * sy) * accLPFGPS[0] + (sr * sy + cr * spcy) * accLPFGPS[2];
  acc_west  = (cp * sy) * accLPFGPS[1] + (cr * cy + sr * spsy) * accLPFGPS[0] + (-sr * cy + cr * spsy) * accLPFGPS[2];
  // if (abs(acc_south) < 40) acc_south = 0;                   // Cancel out some acc noise maybe 40?
  // if (abs(acc_west) < 40)  acc_west  = 0;                   // Cancel out some acc noise maybe 40?

  float accZ = (-sp) * accLPFGPS[1] + (sr * cp) * accLPFGPS[0] + (cr * cp) * accLPFGPS[2] - acc_1G;

Only one strange issue I got during the tests. In some case acc_south & acc_west was not near zero (about 20..30) even after set of ACC calibrations and when board in calm and horizont. But then issue is gone and I have +/-2..4 values (in calm and horizont), i.e. near zero... I reproduced this one-two times... Probably it's avr compiler issue... I don't know, but remember the same issue, which I got during alt hold implementation with getting of accZ...

thx-
Alex

mr.sneezy · Post by **mr.sneezy** » Tue Mar 12, 2013 8:27 am

Tuning GPS/Mag PID or other.

I'm using Baseflight current beta and trying out GPS PH and RTH. Getting a side to side flight motion in PH and also in RTH. Big and slow swings laterally, gets bigger over time as it moving towards me. Gyro and ACC flights are very stable and little drift.
Anybody got a hint on a value or values to alter first up ?
Thanks all,
Martin

Crashpilot1000 · Post by **Crashpilot1000** » Tue Mar 12, 2013 9:37 pm

@mahowik: I am very happy that you can use some of it! The accz althold thing also crossed my mind but i wanted to leave it as it is and not open another can of worms until the GPS thing is done. It will def. save cpu cycles. I observed acc inconsistencies as well and i think, a more precise acc calibration (perhaps alexmos has some nifty code already published?) would help. APM and Arm-o-copter (closed source) use a more complex acc calibration and i think that's the reason. APM just turned to the extended acc calibration in its' last release. Another point of improvement would be a more complex model of the earth magnetic field, like brm hinted at. At least the acc thing seems to be imperative to be done (somehow ....). I am very unhappy with the weather right now it really freezes me....

@mr.sneezy: The GPS is very picky with the magnetometer. If your mag is disturbed by your motors/powersupply forget about a good gps function. PH will circle and RTH will always be in trouble with the correct heading. For mag calibration and watching the compass put in the mag declination first and do the acc calibration first.

Greetings Rob

mahowik · Post by **mahowik** » Tue Mar 12, 2013 9:56 pm

if you are using mpu6050, as I know it goes calibrated from factory, e.g. comparing with prev ACCs generation: bma180/020, adxl345... So actually I'm satisfied with precision of scales of mpu6050. But in some cases you just need to apply small deadband (near middle/zero point) before integrators. As result you provide less instructions to end users and avoid set of unnecessary questions during support of your software... it's just my POV... also 3 axis acc calibration will be pain to do each time when you going outside with less temperature...

Crashpilot1000 · Post by **Crashpilot1000** » Tue Mar 12, 2013 10:18 pm

Ahh, the mpu is precalibrated, that's good to know. Probably the apm guys are too academic about it then - or the apm1 hardwaresupport requires it. I totally agree with you to keep things simple. And adding a little deadband before integration is a very good idea! Why didn't i get the idea!? I always thought of a deadband after rotation.. I will experiment on that

. If everything goes well i will end up with 2 core parameters for althold. Perhaps the WP/RTL stuff can be reduced as well?

mahowik · Post by **mahowik** » Tue Mar 12, 2013 10:40 pm

You can see mwii IMU as example where deadband applied to accZ before integrator
http://code.google.com/p/multiwii/sourc ... ed/IMU.ino

> Perhaps the WP/RTL stuff can be reduced as well?
If you are talking about reducing the number of PID params, when you get right algorithm, as result default PID setting will be acceptable for most configurations... this the point from my experience...

mr.sneezy · Post by **mr.sneezy** » Sun Mar 17, 2013 1:56 pm

Question for TC (or anyone else who knows the answer).
When I updated the Baseflight firmware a couple of weeks back the PID 'D' parameter settings for PosR and NavR changed (on my board), and I only just realised that this weekend. The D value for both of those changed to 0.0 (from 0.045 & 0.080).

Would that have been made by a change in the Baseflight firmware, or perhaps did the data just get corrupted for those parameters on my board ? (The PID's that I had changed before seemed unchanged though...)

I guess saying I'm unsure as to the exact relationship between the CLI and PID settings parameters and any changes I've made, and then what happens to those settings when a new firmware is loaded. Is there a rule as to what to expect ?

Thanks,
Martin

timecop · Post by **timecop** » Mon Mar 18, 2013 12:52 am

If you erase flash when loading new firmware or firmware version changes and it wipes it to defaults, then yes, numbers could change. You can look at commit history to see if GPS P/D changed but I doubt it - so maybe something you changed and forgot?

mr.sneezy · Post by **mr.sneezy** » Mon Mar 18, 2013 8:39 am

timecop wrote:If you erase flash when loading new firmware or firmware version changes and it wipes it to defaults, then yes, numbers could change. You can look at commit history to see if GPS P/D changed but I doubt it - so maybe something you changed and forgot?

Thanks TC.
Yeah anythings possible with me messing around with the GUI while learning how it's used. I know I did tune the P's for Pitch Roll & Yaw, but nothing else needed my input at the time. Next firmware refresh I'll check more carefully afterwards.
Since I had some trouble with GPS guided flight last time out, I guess these 0'd settings might explain it. I'll correct that and try again next calm evening here.

Thanks,
Martin

menno · Post by **menno** » Mon Mar 18, 2013 6:07 pm

I am trying to find the last revision that supports my Freeflight board. I think it is r220? Can anybody confirm this.

Also I don't think that this file is in the regular download area. Is it correct that I can browse the through source for the r220 file and than right click on 'view raw file'.

Thanks!

timecop · Post by **timecop** » Tue Mar 19, 2013 12:01 am

Any revision will work on freeflight. Support for older hardware hasn't been removed.

menno · Post by **menno** » Tue Mar 19, 2013 12:10 am

Great thanks for the reply. I thought that I read something about an extra accelerometer on the newer boards which would make it incompatible.

Do I need to disable something in CLI or am I okay as it is?

timecop · Post by **timecop** » Tue Mar 19, 2013 4:28 am

Nope, its all autodetected and no changes needed. This isn't #define forest like multiwii-8bit

mr.sneezy · Post by **mr.sneezy** » Wed Mar 20, 2013 7:51 am

menno wrote:I am trying to find the last revision that supports my Freeflight board. I think it is r220? Can anybody confirm this.

Also I don't think that this file is in the regular download area. Is it correct that I can browse the through source for the r220 file and than right click on 'view raw file'.

Thanks!

Latest versions are found here in case you missed it.
https://github.com/multiwii/baseflight/ ... stream/obj

menno · Post by **menno** » Wed Mar 20, 2013 9:07 am

Thanks. I think that's the one I downloaded with the naze32 aio program yesterday. I can't find an option to check the version loaded on the board?

mr.sneezy · Post by **mr.sneezy** » Wed Mar 20, 2013 11:12 am

menno wrote:Thanks. I think that's the one I downloaded with the naze32 aio program yesterday. I can't find an option to check the version loaded on the board?

Me neither, although I'm sure I saw it once some place. I thought it would be shown from a 'status' command in the CLI, but it's not. The CLI 'version' command shows the CLI version only. Wait for TC to check in again...
BTW, I don't think the CLI interface in the Naze32 AIO lets you type in commands, so you might need Putty for that.

timecop · Post by **timecop** » Wed Mar 20, 2013 11:18 am

'version' does print out build date/time.

mr.sneezy · Post by **mr.sneezy** » Wed Mar 20, 2013 11:24 am

Flew my quad again tonight (finally).
GPS controlled flight is better now that I've fixed the NavR and PosR parameters. RTH is quite usable to get the quad back from a good distance, tried it several times. It's a bit soft in position hold though, and once it's arrived at the RTH location it also wanders around 10 meters or so. So I need to increase some parameters (which ?) or maybe try out Harakiri9a and compare Robs tweaks.
Cheers,
Martin

mr.sneezy · Post by **mr.sneezy** » Wed Mar 20, 2013 11:36 am

timecop wrote:'version' does print out build date/time.

Ah. Yes the date and time is there, mine is the 4th of March. I think he was looking for a rXXX revision number or something.