Harakiri aka multiwii port to stm32
Re: Harakiri aka multiwii port to stm32
Hey Rob.
I flashed SummerGames2.1 to my flight controller, but it seems like if I try to use the CLI in BaseFlightGUI 2.2.9.0 it gives me a ton of strange text and never lets me configure through CLI. I tried using a couple other GUI's and got the same results. Is there a GUI we should be using with SummerGames2.1?
Also, now that I have flashed SummerGames2.1, i can no longer flash anything else. The STMFlashLoader tells me
"Unrecognized device... Please, reset your device then try again
Please, reset your device then press any key to continue"
Resetting the device does nothing.
Thanks.
I flashed SummerGames2.1 to my flight controller, but it seems like if I try to use the CLI in BaseFlightGUI 2.2.9.0 it gives me a ton of strange text and never lets me configure through CLI. I tried using a couple other GUI's and got the same results. Is there a GUI we should be using with SummerGames2.1?
Also, now that I have flashed SummerGames2.1, i can no longer flash anything else. The STMFlashLoader tells me
"Unrecognized device... Please, reset your device then try again
Please, reset your device then press any key to continue"
Resetting the device does nothing.
Thanks.
Last edited by subaru4wd on Thu Jul 18, 2013 10:08 pm, edited 2 times in total.
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:@mr.sneezy: Yes i turn the copter by hand and look at the gui. A 90 deg trun should be equal to the compassmovement. N/S and W/E should be exactly 180 deg (+-2 deg, sensor accuracy) If your calibration is wrong you will see it directly. Also check for deviation when tilting. I heard of people killing their Mags by putting real magnets onto them for testing the hell of it. I don't know, if thats true but magnetizing a Mag sensor seems to be not the greatest idea....
@Truglodite: Nice Vids! Harakiri PIDS are not the same like BF! Normally you can set at least the P higher. Harakiri does it with floatpoint calculation and uses some delta time as well. I think it is smoother than the original 8Bit port.
@bovi: Don't know whats up with your setup. A PosP of 200 is crazy, that's for sure.
Cheers
Kraut Rob
EDIT: Next Harakiri will have some Mavlink/Missionplaner/MinimOSD support. Mavlink is working quiet well right now but needs some polishing. Actually I am fighting with EEPROM, when that is Done you will be able to record your flight (15Min Limit) and re - do (& Autolaunch) it or load it in missionplanner and edit it as WP list (but limited WP Numbers - may be 20 - or more? - i don't know what i really need for data right now). Thats the plan. There will be restricions (no circle mode or extra fancy stuff right now) but that is the masterplan. I think that is something to look forward to. Meanwhile i revised the PH/INS stuff for that. Testing seems very promising - so stay tuned.... more to come.
Currently I implemented Mavlink/Mwii Autosensing (DONE) so you can fire up MP or Mwii Gui or whatever and it will connect. GCS doesn't understand the Parameterlist right now - only god knows why. Mp shows the parameterlist and you can edit/save/compare it. For MinimOSD I transmit the RC Channels, Voltage, GPS Data, IMU Data and flightstate. MinimOSD expects 57K. So there seem to be 2 Options: Set Harakiri to 57K on USB or compile (Arduino IDE) MinimOSD to use 115K Baud. It should be sufficient to connect MinimOSD only with +/- and TX because my current code sends the data at ca 2 Kb/s without request (that is normally necessary for minimOSD). When i am finished typing codelines i will heat up the soldering iron and attach a real minimOSD to see what it is doing...
your Version still suffers from:
Code: Select all
angle[ROLL] = constrain(atan2f(EstG.V.X, EstG.V.Z) * 1800.0f / M_PI, -1800, 1800);
angle[PITCH] = constrain(-asinf(EstG.V.Y / -sqrtf(EstG.V.X * EstG.V.X + EstG.V.Y * EstG.V.Y + EstG.V.Z * EstG.V.Z)) * (1800.0f / M_PI), -1800, 1800); // This hack removes gimbal lock (sorta) on pitch, // * 1.0227 is an arbitrary value to get 90 Deg
when angle[] has been changed from int16_t to float - yes, then you achieved an improvement.
the first try cost me a motor ...
my 2 Cents on These stupid int16_t abreviations.
ADDENDUM:
error = error * (float)cycleTime / BasePIDtime; // Crashpilot: Include Cylcletime take 3ms as basis. More deltaT more error
when others do so - you should do not the same.
this adds artefacts on top of the proportinal-controller.
the time variant is taken into account on the I and D part.
i fly with 496hz refreshrate on the esc's - your calculation changes the p controler ... the faster the softer.
because of #define BasePIDtime 3000.0f
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
@Truglodite: Just put your FC higher with a alu plate under it and twist powercables, that will normally do the trick!
@subaru4wd: You can still enter the flashmode, like depicted in the attached readme ("RRR" or enter cli with "###" and type "flash"). Shorting pins also works like always. Flash like described in TC BF manual. The current code is compatible with the mwiigui 2.1 and any terminal program. These programs are the primary compatibility targets because other guis may come and go - like actually seen and closing the github source as well - that's exactly the spirit I expected (still have that repocopy/source on hdd, if anyone should need it).
@brm: I am very sorry to hear that you destroyed a motor!!! Putting those angles to floats is a good idea, I will try that. But I wonder how int16 was able to cause damage? Will check the dt Errorstuff asap, that is a very good point!! Thank you very much for your input! Keep it coming! Sorry for your motor!
There is still an issue with mavlink when you arm, while missionplanner is downloading the parameterlist. Currently working on that as well...
Greetings
Rob
@subaru4wd: You can still enter the flashmode, like depicted in the attached readme ("RRR" or enter cli with "###" and type "flash"). Shorting pins also works like always. Flash like described in TC BF manual. The current code is compatible with the mwiigui 2.1 and any terminal program. These programs are the primary compatibility targets because other guis may come and go - like actually seen and closing the github source as well - that's exactly the spirit I expected (still have that repocopy/source on hdd, if anyone should need it).
@brm: I am very sorry to hear that you destroyed a motor!!! Putting those angles to floats is a good idea, I will try that. But I wonder how int16 was able to cause damage? Will check the dt Errorstuff asap, that is a very good point!! Thank you very much for your input! Keep it coming! Sorry for your motor!
There is still an issue with mavlink when you arm, while missionplanner is downloading the parameterlist. Currently working on that as well...
Greetings
Rob
Re: Harakiri aka multiwii port to stm32
Thanks for the quick reply Rob. I was able to gain access to the CLI tab after using the ### trick. I also confirmed i can connect using PuTTY, so all is well.
However I still am unable to flash any firmware to the board. If I use the "Flash" command in the CLI, it tells me to close the terminal and flash firmware. So I try, and the STMFlashLoader gives me this error string:
I am using the Baseflight GUI to try the flash, maybe I should try another piece of software? I suppose there really is no need to mess with flashing firmware now that I have CLI access.
Thanks again.
However I still am unable to flash any firmware to the board. If I use the "Flash" command in the CLI, it tells me to close the terminal and flash firmware. So I try, and the STMFlashLoader gives me this error string:
Code: Select all
Activating device [KO]
No response from the target, the Boot loader can not be started.
Please, verify the boot mode configuration, reset your device then try again.
Please, reset your device then then press any key to continue
I am using the Baseflight GUI to try the flash, maybe I should try another piece of software? I suppose there really is no need to mess with flashing firmware now that I have CLI access.
Thanks again.
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:@Truglodite: Just put your FC higher with a alu plate under it and twist powercables, that will normally do the trick!
@subaru4wd: You can still enter the flashmode, like depicted in the attached readme ("RRR" or enter cli with "###" and type "flash"). Shorting pins also works like always. Flash like described in TC BF manual. The current code is compatible with the mwiigui 2.1 and any terminal program. These programs are the primary compatibility targets because other guis may come and go - like actually seen and closing the github source as well - that's exactly the spirit I expected (still have that repocopy/source on hdd, if anyone should need it).
@brm: I am very sorry to hear that you destroyed a motor!!! Putting those angles to floats is a good idea, I will try that. But I wonder how int16 was able to cause damage? Will check the dt Errorstuff asap, that is a very good point!! Thank you very much for your input! Keep it coming! Sorry for your motor!
There is still an issue with mavlink when you arm, while missionplanner is downloading the parameterlist. Currently working on that as well...
Greetings
Rob
hi,
my sw and my Problem
jitter on the time line is normal. in the Video below i have up to 10 percent jitter on the cycletimes.
https://www.youtube.com/watch?v=3zvi3EApokY&feature=c4-overview&list=UUIq1PaR9qEuyT_N0JqyIVpw
this no Problem as Long as the pid Controller is implemented correctly (my view)
the Integrator should have the term dt being multiplied with. then you have the correct 'area' on the time time.
the same applies to the d term - dividing with dt causes the appropriate changes. as dt is quite small the changes on the d-term do vary much.
as you have floats you might increase the 'I' value by 1000 and when calculating the i-term you multiply with 0.001.
this gives you a more precise i term because all multiplicators are quite small (dt, error and I).
i am playing quite much with the f3 mcu - really nice having an fpu
i am also still working on the f1 stuff.
cheers rob
Re: Harakiri aka multiwii port to stm32
Hi Truglodite, thanks, the works not quite over yet though, and I'm not sure if I'm the Martin you mean as I have not posted in RCG's DIY forum for some time. The posts were possibly about DIY 2.4Ghz dipoles if that's what you mean.Truglodite wrote:Nice work Martin! Are you the same Martin from the RCG DIY antenna tuner thread?
Anyway, I may have to remove the Mag sensor from the GY-86 board. Reason as described on the BaseFlight thread here, it's very hard to work out the correct Mag axis corrections to set in CLI for a non standard Mag orientation.
The fix will be either fluke it or desolder the HMC5883 and refit my old Mag sensor module.
While I do have some good SMD soldering gear at home, I don't have a hot air rework station either. To remove the boards old redundant sensors I used the 'heat the whole chip from the top with a large tip' method. This destroys the chips mostly but in these cases I don't care. I did save the BMP085 though as it was originally fitted by me and done so I could remove it with stainless steel foil.
On a different topic, I'm having a lot of strife with BaseFlight GUI new version. For me it's not doing a Mag or Acc Calibration at all (hangs the communications and board does not enter cal routine), and also the CLI tabs Set button sometimes results in some error messages and does not show the CLI tables. I'm still running the old Harakiri10Beta4 or something, so not sure if that is an issue. Other GUI's are doing the Cal stuff fine though...
I want to sort out my new IMU hardware before loading 'Harakiri Summer Games 1 or 2' (sounds like some smutty teen movie title BTW
Martin
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
@Brm: I will try that with dt and basetime just on I and D. dt on "p" is a real no-brainer that is completely right!
@subaru@sneezy: Using the normal target - toolset (mwii gui 2.1, serial monitor (like putty etc), and stm flashloader - like written in TC BF Manual - and make sure it is set to erase all and 128K) works without any compatibility problems. Even editing the parameters and saving/comparing parametersets works with arducopters' missionplanner (it will complain about some missing arducopter specific variables at the beginning).
"Summergames" is not a teen movie , it is in memory of C64 summergames! http://www.youtube.com/watch?v=qw31Eocnie8
Greetings
Rob
@subaru@sneezy: Using the normal target - toolset (mwii gui 2.1, serial monitor (like putty etc), and stm flashloader - like written in TC BF Manual - and make sure it is set to erase all and 128K) works without any compatibility problems. Even editing the parameters and saving/comparing parametersets works with arducopters' missionplanner (it will complain about some missing arducopter specific variables at the beginning).
"Summergames" is not a teen movie , it is in memory of C64 summergames! http://www.youtube.com/watch?v=qw31Eocnie8
Greetings
Rob
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:@Brm: I will try that with dt and basetime just on I and D. dt on "p" is a real no-brainer that is completely right!
@subaru@sneezy: Using the normal target - toolset (mwii gui 2.1, serial monitor (like putty etc), and stm flashloader - like written in TC BF Manual - and make sure it is set to erase all and 128K) works without any compatibility problems. Even editing the parameters and saving/comparing parametersets works with arducopters' missionplanner (it will complain about some missing arducopter specific variables at the beginning).
"Summergames" is not a teen movie , it is in memory of C64 summergames! http://www.youtube.com/watch?v=qw31Eocnie8
Greetings
Rob
will create patch when i load the sw.
you have no clue when you try to adjust something in the pid calculations using the 'basetime'.
for example you have the Situation where the sensor Fusion reports a smaller error with regards to the setpoint but before you where reading the gps.
this would result in a time-slip - your basetime Thing just does the wrong Thing in any case.
cheers rob
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Well I just thought of the basetime stuff just like a prescaler to keep the Pids in normal mwii range, because it will boil down to just a factor like * 3,33E-4. The gps is a different story because of the laggy gps data. I think you would need a list there and collect the reported gps movements and align that with the acc data of that time (timeshifted by gps lag) and project that error, maybe by further processing to the actual situation. That is def. way beyond my capabilities and I think it's not working out with the current mwii IMU. It would be great if you had a kalmancode at hand and that would run without a special math unit....
Greetings
Rob
EDIT: Hi, BRM! I just altered the mainpidcontroller to your suggestions but included the mwwii basetime as constant now. It works really great !!!
EDIT: EDIT: Did a new hex on that: http://fpv-treff.de/download/file.php?id=5868
Greetings
Rob
EDIT: Hi, BRM! I just altered the mainpidcontroller to your suggestions but included the mwwii basetime as constant now. It works really great !!!
Code: Select all
...
float tmp0flt, dT, MwiiTimescale;
....
tmp0flt = (float)cycleTime;
MwiiTimescale = tmp0flt * 3.3333333e-4f;
dT = tmp0flt * 0.000001f; // pt1 element http://www.multiwii.com/forum/viewtopic.php?f=23&t=2624
prop = (float)max(abs(rcCommand[PITCH]), abs(rcCommand[ROLL])); // range [0;500] Crashpilot: prop is float now
switch (cfg.mainpidctrl)
{
case 1: // 1 = OriginalMwiiPid pimped by me
for (axis = 0; axis < 3; axis++)
{
if ((f.ANGLE_MODE || f.HORIZON_MODE) && axis < 2) // MODE relying on ACC 50 degrees max inclination
{
errorAngle = constrain(2.0f * (float)rcCommand[axis] + GPS_angle[axis], -500.0f, +500.0f) - (float)angle[axis] + (float)cfg.angleTrim[axis];
PTermACC = errorAngle * (float)cfg.P8[PIDLEVEL] * 0.01f;
tmp0flt = (float)cfg.D8[PIDLEVEL] * 5.0f;
PTermACC = constrain(PTermACC, -tmp0flt, +tmp0flt);
errorAngle *= MwiiTimescale; // Crashpilot: Include Cylcletime take 3ms as basis. More deltaT more error
errorAngleI[axis] = constrain(errorAngleI[axis] + errorAngle, -10000.0f, +10000.0f); // WindUp
ITermACC = ((float)errorAngleI[axis] * (float)cfg.I8[PIDLEVEL]) / 4096.0f;
}
if (!f.ANGLE_MODE || f.HORIZON_MODE || axis == 2) // MODE relying on GYRO or YAW axis
{
error = (float)rcCommand[axis] * 80.0f / (float)cfg.P8[axis]; // Removed INFO BRM
error -= (float)gyroData[axis];
PTermGYRO = (float)rcCommand[axis];
error *= MwiiTimescale;
errorGyroI[axis] = constrain(errorGyroI[axis] + error, -16000.0f, +16000.0f);
if (abs(gyroData[axis]) > 640.0f) errorGyroI[axis] = 0;
ITermGYRO = errorGyroI[axis] * (float)cfg.I8[axis] * 0.000125f;
}
if (f.HORIZON_MODE && axis < 2)
{
PTerm = (PTermACC * (500.0f - prop) + PTermGYRO * prop) * 0.002f;
ITerm = (ITermACC * (500.0f - prop) + ITermGYRO * prop) * 0.002f;
}
else
{
if (f.ANGLE_MODE && axis < 2)
{
PTerm = PTermACC;
ITerm = ITermACC;
}
else
{
PTerm = PTermGYRO;
ITerm = ITermGYRO;
}
}
PTerm -= ((float)gyroData[axis] * (float)dynP8[axis] * 0.0125f);
delta = ((float)gyroData[axis] - (float)lastGyro[axis]) / MwiiTimescale;
lastGyro[axis] = gyroData[axis];
deltaSum = delta1[axis] + delta2[axis] + delta;
delta2[axis] = delta1[axis];
delta1[axis] = delta;
if (cfg.mainpt1cut != 0) // pt1 element http://www.multiwii.com/forum/viewtopic.php?f=23&t=2624
{
deltaSum = lastDTerm[axis] + (dT / (MainDpt1Cut + dT)) * (deltaSum - lastDTerm[axis]);
lastDTerm[axis] = deltaSum;
}
DTerm = (float)deltaSum * (float)dynD8[axis] * 0.03125f;
axisPID[axis] = PTerm + ITerm - DTerm;
}
break;
....
EDIT: EDIT: Did a new hex on that: http://fpv-treff.de/download/file.php?id=5868
Re: Harakiri aka multiwii port to stm32
Hey,
Decided to give this a go and loaded it in my FreeFlight v1.2.
All fine but no cli, similar problem to what was described by subaru4wd before.
Even using a normal terminal tool all I get is bogus text in the cli mode, flashing is fine but I need the cli to set a couple features like PPM and change the mixer.
Decided to give this a go and loaded it in my FreeFlight v1.2.
All fine but no cli, similar problem to what was described by subaru4wd before.
Even using a normal terminal tool all I get is bogus text in the cli mode, flashing is fine but I need the cli to set a couple features like PPM and change the mixer.
Re: Harakiri aka multiwii port to stm32
hi,
i will give it a test tomorrow.
in the mean time i hope you have a zip file with the sources.
run through another test series ...
cheers rob
i will give it a test tomorrow.
in the mean time i hope you have a zip file with the sources.
run through another test series ...
cheers rob
Last edited by brm on Fri Jul 19, 2013 9:28 pm, edited 1 time in total.
Re: Harakiri aka multiwii port to stm32
...nevermind... working now.
That's what you get for using windows...
That's what you get for using windows...
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Here something from the readme:
- Autosensing Mavlink/Multiwii protocols (can change every 4 seconds)
- Due to Autosensing you will see the Mavlink "1Hz Heartbeat - garbage" in cli.
- Entering the CLI requires three times "#" now! ("###"). Alternatively 3 times <RETURN>. CLI entering is only possible when disarmed.
- Flashing requires three times "R" now! ("RRR")
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Harakiri aka multiwii port to stm32
Now my interest is aroused. "Mavlink "1Hz Heartbeat"
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:Here something from the readme:- Autosensing Mavlink/Multiwii protocols (can change every 4 seconds)
- Due to Autosensing you will see the Mavlink "1Hz Heartbeat - garbage" in cli.
- Entering the CLI requires three times "#" now! ("###"). Alternatively 3 times <RETURN>. CLI entering is only possible when disarmed.
- Flashing requires three times "R" now! ("RRR")
Thanks Rob. I should have paid more attention to that part of the Readme.
-
- Posts: 48
- Joined: Sat Jun 22, 2013 2:37 am
Re: Harakiri aka multiwii port to stm32
Rob, thanks for posting that info on ###/RRR... that one has already caused some headaches I'm sure. Now the GUI needs to add those extra 2 keystrokes.
BTW, for whatever reason I cannot unzip SummerGames 2.2?! Here's a dump from WinRAR (explorer doesn't work either):
I keep getting folders with no files in them, and weird permission dialog's when I go to delete the empty folders. Not sure if it's me or the zip file. Has anyone else had this problem?
Sorry, the other Martin was posting about a DIY SWR meter, and your good soldering craftsmanship reminded me of his work. Sorry to hear working out those mag signs is turning out to be difficult; I figured that would just be a 3x3 matrix to guess & check, but there's probably a lot more to it. Interesting idea with melting off the IC. I have a Frys electronics within 5min driving of my home, who has the Aoyue 852A rework station in stock for $140 USD. I may buy myself one this weekend; not just to remove a compass, but for all the mad scientist projects that come my way.
BTW, for whatever reason I cannot unzip SummerGames 2.2?! Here's a dump from WinRAR (explorer doesn't work either):
Code: Select all
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\HarakiriREADME\BearingHeadingExplain.jpg
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\HarakiriREADME\PhBathtub.jpg
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\HarakiriREADME\README.txt
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\obj\baseflight_NAZE.bin
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\obj\baseflight_NAZE.hex
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\baseflight_mavlink.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\baseflight_mavlink.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\baseflight_startups\startup_stm32f10x_md.s
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\baseflight_startups\startup_stm32f10x_md_fy90q.s
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\baseflight_startups\startup_stm32f10x_md_gcc.S
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\board.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\buzzer.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\cli.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\config.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_adc.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_adc.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_adc_fy90q.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_adxl345.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_adxl345.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_bmp085.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_hcsr04.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_hcsr04.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_hmc5883l.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_i2c.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_i2c.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_i2c_lcd.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_i2c_lcd.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_i2c_soft.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_l3g4200d.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_ledring.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_ledtoggle.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_mma845x.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_mpu3050.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_mpu6050.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_ms5611.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_pwm.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_pwm.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_pwm_fy90q.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_system.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_system.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_uart.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\drv_uart.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\gps.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\imu.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\main.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\mixer.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\mw.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\mw.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\printf.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\printf.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\sensors.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\serial.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\spektrum.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\telemetry.c
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\ardupilotmega.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_ahrs.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_ap_adc.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_digicam_configure.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_digicam_control.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_fence_fetch_point.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_fence_point.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_fence_status.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_hwstatus.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_meminfo.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_mount_configure.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_mount_control.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_mount_status.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_radio.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_sensor_offsets.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_set_mag_offsets.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\mavlink_msg_simstate.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\testsuite.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\ardupilotmega\version.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\checksum.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\common.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_attitude.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_attitude_quaternion.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_auth_key.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_change_operator_control.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_change_operator_control_ack.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_command_ack.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_command_long.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_data_stream.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_debug.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_debug_vect.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_global_position_int.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_global_position_setpoint_int.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_global_vision_position_estimate.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_gps_global_origin.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_gps_raw_int.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_gps_status.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_heartbeat.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_hil_controls.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_hil_rc_inputs_raw.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_hil_state.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_local_position_ned.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_local_position_ned_system_global_offset.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_local_position_setpoint.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_manual_control.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_memory_vect.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_ack.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_clear_all.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_count.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_current.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_item.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_item_reached.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_request.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_request_list.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_request_partial_list.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_set_current.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_mission_write_partial_list.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_named_value_float.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_named_value_int.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_nav_controller_output.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_optical_flow.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_param_request_list.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_param_request_read.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_param_set.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_param_value.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_ping.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_raw_imu.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_raw_pressure.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_rc_channels_override.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_rc_channels_raw.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_rc_channels_scaled.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_request_data_stream.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_roll_pitch_yaw_speed_thrust_setpoint.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_roll_pitch_yaw_thrust_setpoint.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_safety_allowed_area.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_safety_set_allowed_area.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_scaled_imu.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_scaled_pressure.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_servo_output_raw.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_global_position_setpoint_int.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_gps_global_origin.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_local_position_setpoint.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_mode.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_quad_motors_setpoint.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_quad_swarm_roll_pitch_yaw_thrust.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_roll_pitch_yaw_speed_thrust.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_set_roll_pitch_yaw_thrust.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_state_correction.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_statustext.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_system_time.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_sys_status.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_vfr_hud.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_vicon_position_estimate.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_vision_position_estimate.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\mavlink_msg_vision_speed_estimate.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\testsuite.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\common\version.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\matrixpilot\matrixpilot.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\matrixpilot\mavlink.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\matrixpilot\testsuite.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\matrixpilot\version.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\mavlink_helpers.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\mavlink_protobuf_manager.hpp
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\mavlink_types.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\protocol.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_cmd_airspeed_ack.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_cmd_airspeed_chng.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_filt_rot_vel.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_llc_out.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_air_temp.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_air_velocity.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_attitude.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_bias.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_position.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_qff.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_velocity.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_obs_wind.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_pm_elec.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\mavlink_msg_sys_stat.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\sensesoar.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\testsuite.h
! C:\Users\Kevin\Documents\RC hobby\FPV\baseflight\Source190713-1945Uhr.zip: Unknown method in Source190713-1945Uhr\src\v1.0\sensesoar\version.h
I keep getting folders with no files in them, and weird permission dialog's when I go to delete the empty folders. Not sure if it's me or the zip file. Has anyone else had this problem?
mr.sneezy wrote:Hi Truglodite, thanks, the works not quite over yet though, and I'm not sure if I'm the Martin you mean as I have not posted in RCG's DIY forum for some time. The posts were possibly about DIY 2.4Ghz dipoles if that's what you mean.
Anyway, I may have to remove the Mag sensor from the GY-86 board. Reason as described on the BaseFlight thread here, it's very hard to work out the correct Mag axis corrections to set in CLI for a non standard Mag orientation.
While I do have some good SMD soldering gear at home, I don't have a hot air rework station either. To remove the boards old redundant sensors I used the 'heat the whole chip from the top with a large tip' method. This destroys the chips mostly but in these cases I don't care. I did save the BMP085 though as it was originally fitted by me and done so I could remove it with stainless steel foil.
Sorry, the other Martin was posting about a DIY SWR meter, and your good soldering craftsmanship reminded me of his work. Sorry to hear working out those mag signs is turning out to be difficult; I figured that would just be a 3x3 matrix to guess & check, but there's probably a lot more to it. Interesting idea with melting off the IC. I have a Frys electronics within 5min driving of my home, who has the Aoyue 852A rework station in stock for $140 USD. I may buy myself one this weekend; not just to remove a compass, but for all the mad scientist projects that come my way.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
@Subaru: Now worries but I had to change that because of the Autodetection stuff in disarmed mode. The current code would have interpreted a single incoming "R" as "wanna flash now" or a single incoming "#" as "enter cli". So this had to be done to pull mavlink ahead and avoid accidently entering an unwanted mode. I know that this produces incompatibility to some guis but it is done out of a necessity and not to annoy users - though it is annoying in the shifting phase. The code changes for Guis would be minimal to cope with that.
@Crrichie: The mavlink support is still basal and supports minimosd and the naze parameterlist. The plan is to do some wp stuff and display the flightpath. That would also open up some android stuff for those people who like that. Everybody thinks that mavlink is so ressource killing but it adds up to ca 2,5KB of codesize and the datarate on serial is around 1,5KB/s for sending inflight data (GPS/Sensors(ACC/GYRO/BARO/MAG)/volt/8Rcchannels(RAW)+Throttle scaled (0-100%)/RSSI (not gathered by naze right now)/Flightstatus) that's not too shabby in my opinion and the Updaterates are sufficient for telemetry. GCS (tested on windows) seems to be crazier than missionplaner and will only start to behave when you send "i am arducopter" to it - so thats done in the last code.
@BRM: I don't know if your post was adressed to me but I always include the source on the frontpagestuff because TC needs something to laugh about .
I just looked at your code. WOW, I don't understand a thing of that Kalman but impressive! Currently the kalmanpart seems to be working on it's own with gyro & acc data. I looked in IMU and found that http://code.google.com/p/afrodevices/so ... /imu.c#187 , I did a short test and think it improved the INS part - will test more tomorrow. Don't know where that 0.5 comes from but it seems to be good, you are a genius!
@Turglodite: Oh! I fiddled around with my 7Zip program and different .zip compressions - must have chosen some incompatible compressing mode.. I will re - uplod it here. Stand by!
EDIT: THis forum just supports 256KB Attachment, so uploaded again here http://fpv-treff.de/viewtopic.php?f=18& ... 576#p20576 (It's the first file "
Source190713-1945Uhr.zip") It's compressed in lzma or something, hopefully your pc does that!
BE WARNED: DUE TO BRM's CORRECTIVE INPUT THE MAIN PIDCONTROLLER IS MORE AGGRESSIVE, LOWER AT LEAST P FOR THE FIRST FLIGHT
Greetings
Rob
@Crrichie: The mavlink support is still basal and supports minimosd and the naze parameterlist. The plan is to do some wp stuff and display the flightpath. That would also open up some android stuff for those people who like that. Everybody thinks that mavlink is so ressource killing but it adds up to ca 2,5KB of codesize and the datarate on serial is around 1,5KB/s for sending inflight data (GPS/Sensors(ACC/GYRO/BARO/MAG)/volt/8Rcchannels(RAW)+Throttle scaled (0-100%)/RSSI (not gathered by naze right now)/Flightstatus) that's not too shabby in my opinion and the Updaterates are sufficient for telemetry. GCS (tested on windows) seems to be crazier than missionplaner and will only start to behave when you send "i am arducopter" to it - so thats done in the last code.
@BRM: I don't know if your post was adressed to me but I always include the source on the frontpagestuff because TC needs something to laugh about .
I just looked at your code. WOW, I don't understand a thing of that Kalman but impressive! Currently the kalmanpart seems to be working on it's own with gyro & acc data. I looked in IMU and found that http://code.google.com/p/afrodevices/so ... /imu.c#187 , I did a short test and think it improved the INS part - will test more tomorrow. Don't know where that 0.5 comes from but it seems to be good, you are a genius!
@Turglodite: Oh! I fiddled around with my 7Zip program and different .zip compressions - must have chosen some incompatible compressing mode.. I will re - uplod it here. Stand by!
EDIT: THis forum just supports 256KB Attachment, so uploaded again here http://fpv-treff.de/viewtopic.php?f=18& ... 576#p20576 (It's the first file "
Source190713-1945Uhr.zip") It's compressed in lzma or something, hopefully your pc does that!
BE WARNED: DUE TO BRM's CORRECTIVE INPUT THE MAIN PIDCONTROLLER IS MORE AGGRESSIVE, LOWER AT LEAST P FOR THE FIRST FLIGHT
Greetings
Rob
Re: Harakiri aka multiwii port to stm32
back again... I was testing the GPS.
I'm using a UBLOX and the FC can dected the incoming messages, I see the heartbeat pulse in the UI, it also detects the 3D Fix in the UI and by the FC ledd blinking, but it doesn't get the Lat/Long coordinates.
I tried loading the 3DR-Ublox.txt and again the same, still if I use the passgps mode it shows me the lat/long coordinates.
I even ended up setting manually the binary mode and enabled the SOL, VELNED and POSLLH messages, but still no luck.
I suppose I'm missing some settings in the gps that is causing this, any idea what might be?
I'm using a UBLOX and the FC can dected the incoming messages, I see the heartbeat pulse in the UI, it also detects the 3D Fix in the UI and by the FC ledd blinking, but it doesn't get the Lat/Long coordinates.
I tried loading the 3DR-Ublox.txt and again the same, still if I use the passgps mode it shows me the lat/long coordinates.
I even ended up setting manually the binary mode and enabled the SOL, VELNED and POSLLH messages, but still no luck.
I suppose I'm missing some settings in the gps that is causing this, any idea what might be?
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Try this: set gps_type = 4 (ublox dumb skips the automatic configuration, so your ucenter config is taken, enable pedestrian and 5Hz)
set gps_baudrate = 115200 (115200 is the default. Enter your ucenter configured gps baudrate here, should be greater than 38400)
With that you will skip the Autosettings, just the ublox raw, binary messages will be parsed. What ublox are you using?
set gps_baudrate = 115200 (115200 is the default. Enter your ucenter configured gps baudrate here, should be greater than 38400)
With that you will skip the Autosettings, just the ublox raw, binary messages will be parsed. What ublox are you using?
Re: Harakiri aka multiwii port to stm32
Thanks! I'm going to try that.
I'm using a is a uBLox 6M with eeprom in the shield and a 1575R antenna.
(This thing is fast to get a 3D fix, comparing to another ublox I have with a much smaller one)
I'm using a is a uBLox 6M with eeprom in the shield and a 1575R antenna.
(This thing is fast to get a 3D fix, comparing to another ublox I have with a much smaller one)
Re: Harakiri aka multiwii port to stm32
I had it already running at 5hz / 11520), so set the remaining and double-checked what messages I was sending (NAV_SOL, NAV_POSLHN, NAV_VELNED all set to 1).
Changed the settings in the FC but still no luck.
It gets the sat count and detects the 3D fix but doesn't get the lat/lon coordinates. (does it needs a minimum sat count? I let it go up to 6 and the led in the FC was already flashing 2x)
After enabled the passgps and opened ucenter and it was reading all well.
Changed the settings in the FC but still no luck.
It gets the sat count and detects the 3D fix but doesn't get the lat/lon coordinates. (does it needs a minimum sat count? I let it go up to 6 and the led in the FC was already flashing 2x)
After enabled the passgps and opened ucenter and it was reading all well.
Re: Harakiri aka multiwii port to stm32
i am forced to Switch to the rev. 4 board.
gonna drop all older Drivers due to:
tc - we Need more Flash ....
but not Adobe Flash!
gonna drop all older Drivers due to:
Code: Select all
d:/armm4/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: obj/baseflight.elf section `.text' will not fit in region `FLASH'
d:/armm4/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 1868 bytes
tc - we Need more Flash ....
but not Adobe Flash!
Re: Harakiri aka multiwii port to stm32
Truglodite wrote:Sorry, the other Martin was posting about a DIY SWR meter, and your good soldering craftsmanship reminded me of his work. Sorry to hear working out those mag signs is turning out to be difficult; I figured that would just be a 3x3 matrix to guess & check, but there's probably a lot more to it. Interesting idea with melting off the IC. I have a Frys electronics within 5min driving of my home, who has the Aoyue 852A rework station in stock for $140 USD. I may buy myself one this weekend; not just to remove a compass, but for all the mad scientist projects that come my way.
LOL, I have been soldering for a long time, so glad it still passes inspection. These days I solder SMD with a low power stereo microscope, gone are my days of doing it by naked eyes.
Speaking of age (which we weren't) I'm guessing Crashpilot1000 Rob is bordering on 45ish, maybe a bit more, judging by the reference to the C64 games. I had a C64 and then a 128D. Chiped both IIRC to 'root' them as it seems to be called now.
Thanks for noting that Hot Air Rework Station, checking one out on Ebay as I write. At work we pay $1K-2K for them, so I never thought of buying one for home till now.
Cheers,
Martin
PS. Sounds like you have SMD soldering experience. If not, one big tip is use a good liquid flux when desoldering. I use a flux pen.
PSS. Just bought one of these for home on Ebay for $59 AU !
http://www.youtube.com/watch?v=vva2t21sOAs
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
@IceWind: Hi! I refreshed the ublox parser. Hopefully it will cope better with your setup. It works (like the old one) on my rig.
http://fpv-treff.de/viewtopic.php?f=18& ... 576#p20576
@sneezy: Don't make me older than I actually am....
http://fpv-treff.de/viewtopic.php?f=18& ... 576#p20576
@sneezy: Don't make me older than I actually am....
Re: Harakiri aka multiwii port to stm32
Truglodite wrote:I'm frustrated that I can't join in on the fun due to my problems with compass interference. I'm close to jumping off that cliff and dremeling off my onboard compass; I looked carefully and cutting traces isn't possible (SCL trace hides under the compass).
It doesn't matter, if you just cut the SDA, the compass is disconnected.
Re: Harakiri aka multiwii port to stm32
brm wrote:we Need more Flash ....
No you need quality code and better compiler.
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:@IceWind: Hi! I refreshed the ublox parser. Hopefully it will cope better with your setup. It works (like the old one) on my rig.
http://fpv-treff.de/viewtopic.php?f=18& ... 576#p20576
ACK! I'll load it and let you know how it goes.
In the mean time I may get a Naze32, I can't make my MAG working on the FreeFlight and I do want to try the full deal.
Re: Harakiri aka multiwii port to stm32
Tested and approved! Thanks for the quick fix.
- Loaded 2.3 FW
- Reset to defaults
- Enabled GPS feature
- Working!
One question related to the ALT value. I saw that you changed the code, and his value comes from combining the BARO readings with the the ACC Z axis.
(among other sensors, like sonar if present...)
At the moment I see that it can very accurately detect variations in the altitude but the readings doesn't reflect the end altitude as after showing the increase/decrease in the altitude it goes back again to ~0. I suspect this is due to my bmp085 been damaged. (I think I gave it too much heat when soldering)
I saw the cfg.baro_debug var and I'll compile a version with it to debug but I just wanted to make sure I understood the code.
- Loaded 2.3 FW
- Reset to defaults
- Enabled GPS feature
- Working!
One question related to the ALT value. I saw that you changed the code, and his value comes from combining the BARO readings with the the ACC Z axis.
(among other sensors, like sonar if present...)
At the moment I see that it can very accurately detect variations in the altitude but the readings doesn't reflect the end altitude as after showing the increase/decrease in the altitude it goes back again to ~0. I suspect this is due to my bmp085 been damaged. (I think I gave it too much heat when soldering)
I saw the cfg.baro_debug var and I'll compile a version with it to debug but I just wanted to make sure I understood the code.
Re: Harakiri aka multiwii port to stm32
timecop wrote:brm wrote:we Need more Flash ....
No you need quality code and better compiler.
for Adobe Flash you are right.
-
- Posts: 48
- Joined: Sat Jun 22, 2013 2:37 am
Re: Harakiri aka multiwii port to stm32
z01z wrote:Truglodite wrote:I'm frustrated that I can't join in on the fun due to my problems with compass interference. I'm close to jumping off that cliff and dremeling off my onboard compass; I looked carefully and cutting traces isn't possible (SCL trace hides under the compass).
It doesn't matter, if you just cut the SDA, the compass is disconnected.
Perfect, thank you very much for the advice! I studied a little i2c last night, and you are absolutely right. I ordered a 5V compass module; now I have to find a quiet spot to mount it. I'm looking forward to test flying it this week. Should get rid of that sudden 45* forward pitch I saw yesterday in PH... LOL.
On another note, I finally got the hang of alt hold. It took a minute to get used to how it responds, including having to recenter the stick to activate vario. It was every bit as locked in as my APM rig (which says a lot!), but it responds much quicker to climb rate adjustments. I prefer the more aggressive CR control; I don't have to hit the brakes as much when something very tall gets in the way... feels a lot like full manual, except the floor doesn't drop out after you come screeching to a stop... just what I need.
OTOH, I noticed what seemed like a lot of drift in acro mode while moving along 15-30mph. I had to keep feeding in forward elevator otherwise it wanted to slow itself down. The roll was also hunting around a bit, which diminished my confidence in threading smaller gaps. I think I may have to crank up my gains to get rid of the drift... but then it might fly too stiff like baseflight (which doesn't drift at all). Has anyone else delt with acro drift like this? Any suggestions what gains to start with? I figured they all may need to be increased, especially I gains, but I'm open to suggestions. This is with SG 2.0.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
@IceWind: Thanks for the test feedback!
It looks like your baro is dead but the driver for BMP is working currently on its' limit and closes the gap to ms baro (ms baro is better of course, but bmp is not too shabby after all). You don't need to recompile. Just type "set baro_debug = 1" you should see these values in the debugs (I would use a fast gui for that):
debug[0] = EstAltBaro * 10 That is pure baroalt * 10 cm
debug[1] = EstAlt * 10 That is combined baro/acc hight * 10 cm
debug[2] = BaroClimbRate That is the pure baro climbrate in cm/s
debug[3] = vario That is the combined baro/acc climbrate in cm/s
"pure" barovalues means they are filtered but not influenced by acc. A dead baro will report a constant value in debug[0] I guess, since my baros are working...
The BMP driver is tuned but I doubt that it can't cope with your BMP, but recheck the Baro with original TC BF just to be sure.
@Turglodite: Thanks for the feedback! Althold is a matter of tuning of course, but on APM I was never successful - but it's retired anyway with some old 2.9.x on it. Much too vibration sensitive and modeswitch produced a skyrocket. APM 3.0x should be a burner after all I read but that apm put me one time too much out of control so I don't have faith in their stuff and can not fly relaxed anymore with that. Thanks to brm's suggestions the main pid controller is revised, please re-check with the summergames 2.3 if that works better for you. EEPROM space is getting a real issue in the meantime, I wonder what to throw out.
Cheers
"The other" Rob
At the moment I see that it can very accurately detect variations in the altitude but the readings doesn't reflect the end altitude as after showing the increase/decrease in the altitude it goes back again to ~0. I suspect this is due to my bmp085 been damaged. (I think I gave it too much heat when soldering)
I saw the cfg.baro_debug var and I'll compile a version with it to debug but I just wanted to make sure I understood the code.
It looks like your baro is dead but the driver for BMP is working currently on its' limit and closes the gap to ms baro (ms baro is better of course, but bmp is not too shabby after all). You don't need to recompile. Just type "set baro_debug = 1" you should see these values in the debugs (I would use a fast gui for that):
debug[0] = EstAltBaro * 10 That is pure baroalt * 10 cm
debug[1] = EstAlt * 10 That is combined baro/acc hight * 10 cm
debug[2] = BaroClimbRate That is the pure baro climbrate in cm/s
debug[3] = vario That is the combined baro/acc climbrate in cm/s
"pure" barovalues means they are filtered but not influenced by acc. A dead baro will report a constant value in debug[0] I guess, since my baros are working...
The BMP driver is tuned but I doubt that it can't cope with your BMP, but recheck the Baro with original TC BF just to be sure.
@Turglodite: Thanks for the feedback! Althold is a matter of tuning of course, but on APM I was never successful - but it's retired anyway with some old 2.9.x on it. Much too vibration sensitive and modeswitch produced a skyrocket. APM 3.0x should be a burner after all I read but that apm put me one time too much out of control so I don't have faith in their stuff and can not fly relaxed anymore with that. Thanks to brm's suggestions the main pid controller is revised, please re-check with the summergames 2.3 if that works better for you. EEPROM space is getting a real issue in the meantime, I wonder what to throw out.
Cheers
"The other" Rob
Re: Harakiri aka multiwii port to stm32
Rob, I downloaded SummerGames2.3 and tried to unzip it, but kept getting an error.
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:@IceWind: Thanks for the test feedback!At the moment I see that it can very accurately detect variations in the altitude but the readings doesn't reflect the end altitude as after showing the increase/decrease in the altitude it goes back again to ~0. I suspect this is due to my bmp085 been damaged. (I think I gave it too much heat when soldering)
I saw the cfg.baro_debug var and I'll compile a version with it to debug but I just wanted to make sure I understood the code.
It looks like your baro is dead but the driver for BMP is working currently on its' limit and closes the gap to ms baro (ms baro is better of course, but bmp is not too shabby after all). You don't need to recompile. Just type "set baro_debug = 1" you should see these values in the debugs (I would use a fast gui for that):
debug[0] = EstAltBaro * 10 That is pure baroalt * 10 cm
debug[1] = EstAlt * 10 That is combined baro/acc hight * 10 cm
debug[2] = BaroClimbRate That is the pure baro climbrate in cm/s
debug[3] = vario That is the combined baro/acc climbrate in cm/s
"pure" barovalues means they are filtered but not influenced by acc. A dead baro will report a constant value in debug[0] I guess, since my baros are working...
The BMP driver is tuned but I doubt that it can't cope with your BMP, but recheck the Baro with original TC BF just to be sure.
No prob!
Awesome, I'm liking this code more and more.
Did a test and debug[0] keeps showing crazy values. I recorded a bit the UI (quality is not the best) but first the quad is stopped and after I move it up/down (can be seen by the Acc Z axis reading) Still the readings don't match and are totally bogus.
http://www.youtube.com/watch?v=gGG2hgwvS5E
Time to take the hot air station out of the storage...
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Thank you very much for your video but your bmp seems to work. BTW I think you are not using mpu accelerometer (probably adxl ?). I would do a simple flight test. If you see althold doing crazy stuff than you can always flip the switch.
Besides the ordinary Alt Pid tuning (mainly P and I) you have several parameters reachable in cli as well esp. the ones for baro/acc integration:
accz_vel_cf = 0.985 // Crashpilot: Value for complementary filter accz and barovelocity
accz_alt_cf = 0.940 // Crashpilot: Value for complementary filter accz and altitude
They were smaller before: accz_vel_cf = 0.982 and accz_alt_cf = 0.85.
The accz_vel_cf is the "mother" because it is the first step of integrating acc and baro (acc can only do accelerations so that is velocity if summed up over time). The greater it is the more acc influence you will have over the Baro in general. The next step is taking that result and align that with baro altitude with accz_alt_cf (greater more acc influence). You can always watch the result of you changes baro_debug because each component is on display. Vario (debug3) is responsible for the "I" component later on and debug1 for p.
@subaru4wd: Don't know what 7-Zip (http://www.7-zip.de/) setting i screwed up this time. Maybe "rar" next time?
Greets Rob
Besides the ordinary Alt Pid tuning (mainly P and I) you have several parameters reachable in cli as well esp. the ones for baro/acc integration:
accz_vel_cf = 0.985 // Crashpilot: Value for complementary filter accz and barovelocity
accz_alt_cf = 0.940 // Crashpilot: Value for complementary filter accz and altitude
They were smaller before: accz_vel_cf = 0.982 and accz_alt_cf = 0.85.
The accz_vel_cf is the "mother" because it is the first step of integrating acc and baro (acc can only do accelerations so that is velocity if summed up over time). The greater it is the more acc influence you will have over the Baro in general. The next step is taking that result and align that with baro altitude with accz_alt_cf (greater more acc influence). You can always watch the result of you changes baro_debug because each component is on display. Vario (debug3) is responsible for the "I" component later on and debug1 for p.
@subaru4wd: Don't know what 7-Zip (http://www.7-zip.de/) setting i screwed up this time. Maybe "rar" next time?
Greets Rob
Re: Harakiri aka multiwii port to stm32
duplicate post
Last edited by subaru4wd on Wed Jul 24, 2013 4:31 pm, edited 1 time in total.
Re: Harakiri aka multiwii port to stm32
Crashpilot1000 wrote:@subaru4wd: Don't know what 7-Zip (http://www.7-zip.de/) setting i screwed up this time. Maybe "rar" next time?
Greets Rob
So how are we supposed to get 2.3 then? I tried using WinACE to extract the .zip and got the same errors.
I downloaded 7-zip and was able to successfully extract it using that.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Didn't know that there are so much variations of zip files that are actually incompatible with each other. Little progress note: After resolving that eeprom saving more than 1KB stuff (TC was right after all, you have to clear every page..) I managed to program a datalogger that compresses the data just to "deltas" with a little loss of precision. So with an initial complete dataset every further dataset is compressed to 4 "delta" Bytes only, containing LAT/LON/ALT/CompassHEADING. So you can store 20 Minutes of flight in 2,3Kb at 0.5Hz rate. The logfile is written after disarm to eeprom. Currently I haven't figured out how to "beam" that data to missionplaner. The idea is, that you can not only see the flightpath but also alter it and write it back as a "mission" - but every WP is much more than 4Bytes then, so no 550 Datasets anymore... Or even a "relative" mission so that the stuff you flew in place "A" will be flown in place "B" as well. Still miles to go, and I will have to change the current logging because it will tilt out above 40KM/h.
Edit: Just added some untested code here https://github.com/Crashpilot1000/Harak ... c/floppy.c
I will see if that is practically usable or if it accumulates errors that makes useless (I hope not...) .
Cheers Rob
Edit: Just added some untested code here https://github.com/Crashpilot1000/Harak ... c/floppy.c
Basic Function
==============
The LOGGER just works with Byte deltas and reduce the resolution of the accuracy.
The initial Dataset is complete but reduced in accuracy
Lat / 64 Error = 64 * MagicEarthNumber = 71,245 cm or (+-35,6 cm)
Lon / 64 Error is the same at equator, increasing to the poles by 1/cos(lat)
Alt / 100 Stores delta in meter not cm so thats the error here. 100 cm
Heading / 1,5 Stores +-180 Deg with round about 2 degree resolution. So no "delta" here
SpeedLimits at o,5 Hz (1 Dataset every 2 seconds)
================================================
Horizontal Speed
================
Maximal GPS delta is Byte (8Bit) + 6 Bit (that div 64 stuff) - 1 Bit for sign = 13 Bit
That is 8192 * MagicEarthNumber("1,113195") = 9119,29cm/2 sec = 45,6 m/s = 164,15 Km/h.
So logging beyond 164,15 Km/h will tilt out.
Vertical Speed
==============
Maximal delta in m between readings is 7 Bit (1 Bit for sign), so 128m/2 sec = 64m/s = 230 Km/h
YAW Speed
=========
Not limited, since heading is stored without delta. Resolution is reduced to about 2 degree.
Duration of Logging at 0,5 Hz and current bytesize
==================================================
Dataset = 4 Bytes and 2340 Bytes available = 585 Datasets at 1/0.5s = 1170 sec = 19 Min 30 sec
I will see if that is practically usable or if it accumulates errors that makes useless (I hope not...) .
Cheers Rob
Last edited by Crashpilot1000 on Wed Jul 24, 2013 9:54 pm, edited 7 times in total.
Re: Harakiri aka multiwii port to stm32
Thanks Rob for the insights.
Yes, the FF board uses the ADXL ACC, to be honest I probably never even used it as I only fly with GYRO. But for the GPS features I know it needs ACC so I'll give it a try.
As for the BARO, I'm used to the readings/behaviour of the Multiwii so that must be why. As the BARO reading are visually different and I assumed this one was bad. Again I'll set a switch for it and see how it behaves.
Btw, it would be something to consider to add similar debug behaviour to the MAG.
Been fighting to make it work correctly and having direct readings form it would help.
(I'll see if I can hack the code to include that just for testing)
Thanks again for you help!
Crashpilot1000 wrote:Thank you very much for your video but your bmp seems to work. BTW I think you are not using mpu accelerometer (probably adxl ?). I would do a simple flight test. If you see althold doing crazy stuff than you can always flip the switch.
Yes, the FF board uses the ADXL ACC, to be honest I probably never even used it as I only fly with GYRO. But for the GPS features I know it needs ACC so I'll give it a try.
As for the BARO, I'm used to the readings/behaviour of the Multiwii so that must be why. As the BARO reading are visually different and I assumed this one was bad. Again I'll set a switch for it and see how it behaves.
Btw, it would be something to consider to add similar debug behaviour to the MAG.
Been fighting to make it work correctly and having direct readings form it would help.
(I'll see if I can hack the code to include that just for testing)
Thanks again for you help!
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Well, the gui actually displays the pure magADCfloat[] after that aligning stuff(mr.sneezy is currently up for a fight with) so it will not get purer than this, i guess...
-
- Posts: 48
- Joined: Sat Jun 22, 2013 2:37 am
Re: Harakiri aka multiwii port to stm32
Rob, is this SG3 the same as SG2.4 in the readme?
https://github.com/Crashpilot1000/Harak ... kiriREADME
I've already compiled & loaded it on my mini quad. Are there any new things to add to my pretestflight checklist? I noticed the PID scaling is a little different (coming from SG2). Nice to see your project is now in SVN!
I guess I can install 7zip, but I already have a lot of semiredundantrequiredforcompatibility freeware on my computer as is. Rar works for me, or maybe there's a way to setup 7zip defaults so they're compatible with win?
Kevin
ps: My external mag arrives Friday... can't wait to try it out.
https://github.com/Crashpilot1000/Harak ... kiriREADME
I've already compiled & loaded it on my mini quad. Are there any new things to add to my pretestflight checklist? I noticed the PID scaling is a little different (coming from SG2). Nice to see your project is now in SVN!
I guess I can install 7zip, but I already have a lot of semiredundantrequiredforcompatibility freeware on my computer as is. Rar works for me, or maybe there's a way to setup 7zip defaults so they're compatible with win?
Kevin
ps: My external mag arrives Friday... can't wait to try it out.
Re: Harakiri aka multiwii port to stm32
Just use 7za.exe (command line 7zip extractor) and don't bother installing the full communist GUI for it.
Re: Harakiri aka multiwii port to stm32
command lines are so 1980....
Re: Harakiri aka multiwii port to stm32
Truglodite wrote:I ordered a 5V compass module; now I have to find a quiet spot to mount it.
Be careful with the 5V module, it will have some kind of level converter. The one I have has a dual FET (i guess, it's a 6 pin SOT23 component) with 5V and 3V pull-up resistors. IMHO none of these are needed, the sensor I2C lines should be directly connected.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
@Truglodite: Hi! First of all: I am not really on SVN because I delete the repos and load up new stuff. The next thing is: That code there is mostly experimental and unflown and just for demonstration, so
BTW: My posted logging code has some errors. Even with those corrected it works like sh** right now... but hopefully I will somehow make it working...
EDIT: Found an issue with logging, the main reason for crazy logs seems the new MTK parser (or my implementation!) i used for testing, so i will revert back to my own "- stupid - codestyle - but - simply - works - and - rolls - like - a - tank" mtk parser. Hopefully that solves some of the logging issues.
EDIT EDIT: Logging seems to work now. Github updated.
Cheers Kraut Rob
- YES, you are the first to fly that code! The version you upladed is just a split up of the gps part and the implementation of current mtk driver - so there SHOULD be no difference for you, BUT still UNTESTED - that's why no Hex is included....Are there any new things to add to my pretestflight checklist?
BTW: My posted logging code has some errors. Even with those corrected it works like sh** right now... but hopefully I will somehow make it working...
EDIT: Found an issue with logging, the main reason for crazy logs seems the new MTK parser (or my implementation!) i used for testing, so i will revert back to my own "- stupid - codestyle - but - simply - works - and - rolls - like - a - tank" mtk parser. Hopefully that solves some of the logging issues.
EDIT EDIT: Logging seems to work now. Github updated.
Cheers Kraut Rob
Re: Harakiri aka multiwii port to stm32
Hi,
i've tested Harakiri a long time ago, but as i'm going to need a working PH, i'd like to get back to Harakiri again. Question is..does it have the anti-descend-wobble thing implemented yet ?
Thanks
i've tested Harakiri a long time ago, but as i'm going to need a working PH, i'd like to get back to Harakiri again. Question is..does it have the anti-descend-wobble thing implemented yet ?
Thanks
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
It has BRM's suggested pt1 element viewtopic.php?f=23&t=2624 . PH works well with ublox, mtk is still a mess.
Re: Harakiri aka multiwii port to stm32
Just came back from the field. Started with default Summergames 2.3 gps PIDS. Tuned Acro/angle modes first to my liking. Calibrated ACC, MAG. As it was a windy day, the quad was holding altitude within ~1m+-. It was holding direction with MAG enabled.
Things got worse when i started playing with PH (which i need the most atm). With PH+BAR+Mag+Angle enabled, the quad stayed in position for a few seconds...then started drifting some 2-5 meters, then suddenly changind direction towards where PH was enabled, then some 10-20 meters back while getting more and more 'swingy'. I tried playing with pids according to several texts i've found...no luck.
Perhaps someone could make a short walkthrough how to correct certain "symptoms" of not properly working PH ? Or simply...some short GPS pid tuning ABC (like with usual pids..increase P till oscillations, then reduce, etc etc).
EDIT: and it was also a windy day...so at times it seemed like it's not helping the quad to do PH
EDIT EDIT: i'm using UBLOX Neo-6M, 10hz, 115200 baudrate.
Thanks
Things got worse when i started playing with PH (which i need the most atm). With PH+BAR+Mag+Angle enabled, the quad stayed in position for a few seconds...then started drifting some 2-5 meters, then suddenly changind direction towards where PH was enabled, then some 10-20 meters back while getting more and more 'swingy'. I tried playing with pids according to several texts i've found...no luck.
Perhaps someone could make a short walkthrough how to correct certain "symptoms" of not properly working PH ? Or simply...some short GPS pid tuning ABC (like with usual pids..increase P till oscillations, then reduce, etc etc).
EDIT: and it was also a windy day...so at times it seemed like it's not helping the quad to do PH
EDIT EDIT: i'm using UBLOX Neo-6M, 10hz, 115200 baudrate.
Thanks
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Hi Justas!
Thank you very much for your Feedback! Maybe the gps_ph_abstub is causing the trouble. You can reduce it (default = 150) to 100 or so or disable it with "set gps_ph_abstub = 0".
Cheers Rob
Thank you very much for your Feedback! Maybe the gps_ph_abstub is causing the trouble. You can reduce it (default = 150) to 100 or so or disable it with "set gps_ph_abstub = 0".
Cheers Rob
-
- Posts: 48
- Joined: Sat Jun 22, 2013 2:37 am
Re: Harakiri aka multiwii port to stm32
Truglodite wrote:z01z wrote:Truglodite wrote:I'm frustrated that I can't join in on the fun due to my problems with compass interference. I'm close to jumping off that cliff and dremeling off my onboard compass; I looked carefully and cutting traces isn't possible (SCL trace hides under the compass).
It doesn't matter, if you just cut the SDA, the compass is disconnected.
Perfect, thank you very much for the advice! I studied a little i2c last night, and you are absolutely right. I ordered a 5V compass module; now I have to find a quiet spot to mount it. I'm looking forward to test flying it this week. Should get rid of that sudden 45* forward pitch I saw yesterday in PH... LOL.
On another note, I finally got the hang of alt hold. It took a minute to get used to how it responds, including having to recenter the stick to activate vario. It was every bit as locked in as my APM rig (which says a lot!), but it responds much quicker to climb rate adjustments. I prefer the more aggressive CR control; I don't have to hit the brakes as much when something very tall gets in the way... feels a lot like full manual, except the floor doesn't drop out after you come screeching to a stop... just what I need.
OTOH, I noticed what seemed like a lot of drift in acro mode while moving along 15-30mph. I had to keep feeding in forward elevator otherwise it wanted to slow itself down. The roll was also hunting around a bit, which diminished my confidence in threading smaller gaps. I think I may have to crank up my gains to get rid of the drift... but then it might fly too stiff like baseflight (which doesn't drift at all). Has anyone else delt with acro drift like this? Any suggestions what gains to start with? I figured they all may need to be increased, especially I gains, but I'm open to suggestions. This is with SG 2.0.
So... I cut the SDA trace, wired in the external compass, and now my compass doesn't move in the GUI. It's a 3-5V compass, and I'm powering it with my uBec (4.7V verified with meter at the compass), but now apparently my Naze32 doesn't see a compass.
Am I missing something? My module does have a DRDY breakout. Should I pull that high or low... code change? Please help, or just be honest and tell me I just permanently ruined RTH with this board.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: Harakiri aka multiwii port to stm32
Well, the gui (mwiigui2.1) will show a green box around mag if it is found. The "compass pictogram" will only move when the mag is calibrated (that is different from mwii/bf !!). Another way to find out if your sensor is alive is to enter the cli and type "scanbus". That will scan the I2C Bus and every responding device will be listed. Its' name will be printed, if it's known. Here is what scanbus has to say about my naze:
I hope that helps.
Cheers Rob
EDIT: Concerning cutting traces look at the bottom of this page: http://copter.ardupilot.com/wiki/common ... rformance/
Code: Select all
# scanbus
Scanning I2C-Bus
I2C device found at 0x1c Probably it's MMA8452
I2C device found at 0x1e Probably it's HMC5883L
I2C device found at 0x68 Probably it's MPU3050/MPU6050
I2C device found at 0x77 Probably it's MS5611
4 Devices
#
I hope that helps.
Cheers Rob
EDIT: Concerning cutting traces look at the bottom of this page: http://copter.ardupilot.com/wiki/common ... rformance/