Harakiri aka multiwii port to stm32

theailer · Post by **theailer** » Sun Oct 06, 2013 12:34 pm

Ok, got it to work though I'm fairly sure it worked since the start.
I'm using wingui2 and I always looked in the passgps tab for the gps info. Turns out it doesn't output anything. Switching to the MAP tab did indeed verify that the gps was working OK.
Tried to put the ginjein file on my ublox but it wouldn't work with the naze passgps mode, since it changes the baudrate halfway through and I don't know what baudrate it set the gps receiver to. I tried them all with passgps but to no use. I could connect with all of the options but 115200 for some reason.

theailer · Post by **theailer** » Sun Oct 06, 2013 12:39 pm

If I set gps_type = 1, will it disregard the config file regarding update frequency ? Since the 3dr ublox file sets it to 4Hz and the ginjei file sets it to 5Hz, and I can't flash it with the ginjei file.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Oct 06, 2013 3:31 pm

Well I did some flashing in the past with passgps (not in conjunction with a gui only terminal and ucenter) and I can assure you that it works well, if used correctly. Even MTK works. gps_type = 1 will send the mwii ublox configblock (override settings to 5Hz etc) and put the ublox into pedestrian mode. I think the ginjei config does a preset of 115k. I don't know if a separate config/ucenter is required with the configblock of gps_type = 1, since I directly put on the arducopter file onto my ublox on arrival. Edit: I can only test with the hardware I have. But feel free to check/laugh at/improve the code - that's why it's open source and the code is always on display. Most gps problems are related to poor shielding and indoor tests (besides the mag interference).
Cheers Rob

theailer · Post by **theailer** » Sun Oct 06, 2013 8:10 pm

Great. I have it on type 1 now and it works. Tried position hold which I guess is the same as GPS hold in the GUI. It did wander a couple of meters and had some sort of toilet bowl effect, but I had no time to tune it out and I guess my shield plate weren't connected to a ground might also have something to do with it.

IceWind · Post by **IceWind** » Sun Oct 06, 2013 9:03 pm

Hey,

Anyone tried link this to a MimimOSD running Arducam? (Mavlink)
I have one ready to go with version 2.4, but it doesn't get a signal.
So before I start loading other version randomly wanted to check if anyone got this working.

Thanks.

subaru4wd · Post by **subaru4wd** » Sun Oct 06, 2013 9:12 pm

IceWind wrote:Hey,

Anyone tried link this to a MimimOSD running Arducam? (Mavlink)
I have one ready to go with version 2.4, but it doesn't get a signal.
So before I start loading other version randomly wanted to check if anyone got this working.

Thanks.

I tried using the MinimOSD firmware with my SummerGames 2.4 and could never get mavlink to connect. So i gave up and went back to the KV OSD firmware.

IceWind · Post by **IceWind** » Sun Oct 06, 2013 10:51 pm

Ok thanks.
I'll keep the KV OSD as well.

Do you know if it's possible to remove the attitude bar? That thing is annoying and I don't want to spend time touching the code.
What I liked in the Arducam OSD code was that, it was easy to define exactly what I want and placed it exactly where I want to as well.

subaru4wd · Post by **subaru4wd** » Mon Oct 07, 2013 12:01 am

IceWind wrote:Ok thanks.
I'll keep the KV OSD as well.

Do you know if it's possible to remove the attitude bar? That thing is annoying and I don't want to spend time touching the code.
What I liked in the Arducam OSD code was that, it was easy to define exactly what I want and placed it exactly where I want to as well.

Your best bet is to post in the KV thread: viewtopic.php?f=8&t=2918

Crashpilot1000 · Post by **Crashpilot1000** » Mon Oct 07, 2013 11:58 am

That OSD stuff is probably baudrate associated (115K vs 57K). Since KVOSD is a very nice project stick to that. Having native minimosd support isn't a bad idea because I am building a fpv backpack with minimosd. So I can attach it to my (new!)radian pro with arduplane and to my naze copter. Over the weekend I programmed an autostart function to gather up the parts for more autonom. functions. Also did some (minor) bugfixes/improvements. GPS/Mavlink/SavingWP is next on the agenda. Autostart is not for indoor use, unless you want a new decoration or have a 5m ceiling, because its hight is getting reliable at 3m+. The problem with autostart is to find the sweet spot when the copter lifts off, because the turbulences produce a lot of baro misreadings. The current pre2.6 Version in the repo (incl hex - Autostart turned of by default, see the readme) gets that done but I am currently improving that with a std. deviation on the vario to judge upon the launch state (needs some further testing, looking good so far). Theailer, TBE is most likely a magnetometer/mag declination issue. You can try the pre2.6 because it has a function to reduce the magnetometer gain. It will loose some sensitivity/accuracy but gain a robustness from disturbances. With "set mag_gain = 1" your turn that on and with "set mag_gain = 0" off (recalibrate mag on change).
Cheers Rob

Edit: Look for "todays snapshot" here https://github.com/Crashpilot1000?tab=repositories
Edit, Edit: Autostart works now very nice (with that std dev stuff, reliable minimal starthight is now 2m). The climbrate is lowered when reaching targethight. Dunno how its implemented in other projects but it works. You can trigger Autostart when copter is freshly armed (has not flown), Althold engaged and Throttlestick is put to center (and a targethight is set of course - see readme). Note: Stand back during that, it *WILL* work and fly into your face. Tested with and without sonar.

satnaam · Post by **satnaam** » Mon Oct 07, 2013 3:19 pm

Rob, thanks for your continual work SG firmware. How do I get the SG2.6 Ver?? I was able to get the SG2.5. I am looking for it but don't know how to compile a hex file.
Thanks in advance.

satnaam

Crashpilot1000 · Post by **Crashpilot1000** » Mon Oct 07, 2013 4:51 pm

Hi, satnaam!
Yep my private little project keeps on rolling

. The 2.6 final is not ready because I want to reorganize some of the GPS stuff and squeeze that "I returned to home but do sometimes not autoland" bug and needs more testing. The current repo has bin and hex files in the main directory (github didn't like the obj folder) - they are tested without gps functions so pre 2.6 (klick in the right corner to download the whole stuff as zip file).
BTW: I've heard that Harakiri won't run on naze V5. Well I am not planning to buy that v5 stuff, because I see no real benefit in that hardware (and I can not shit money to waste for compatibility), so if you run into that problem you will have to change the code somehow to make it compatible (probably some drv_system / hse stuff), I am currently not looking into that. V4/V3?, Whitespy boards and Flyduino boards will still be compatible. Maybe one fine day the main BF trunc is supplied with some decent GPS code and other useful functions so I can stop that here.
Greets Rob

IceWind · Post by **IceWind** » Mon Oct 07, 2013 8:35 pm

Crashpilot1000 wrote:That OSD stuff is probably baudrate associated (115K vs 57K). Since KVOSD is a very nice project stick to that. Having native minimosd support isn't a bad idea because I am building a fpv backpack with minimosd. So I can attach it to my (new!)radian pro with arduplane and to my naze copter. Over the weekend I programmed an autostart function to gather up the parts for more autonom. functions. Also did some (minor) bugfixes/improvements. GPS/Mavlink/SavingWP is next on the agenda. Autostart is not for indoor use, unless you want a new decoration or have a 5m ceiling, because its hight is getting reliable at 3m+. The problem with autostart is to find the sweet spot when the copter lifts off, because the turbulences produce a lot of baro misreadings. The current pre2.6 Version in the repo (incl hex - Autostart turned of by default, see the readme) gets that done but I am currently improving that with a std. deviation on the vario to judge upon the launch state (needs some further testing, looking good so far). Theailer, TBE is most likely a magnetometer/mag declination issue. You can try the pre2.6 because it has a function to reduce the magnetometer gain. It will loose some sensitivity/accuracy but gain a robustness from disturbances. With "set mag_gain = 1" your turn that on and with "set mag_gain = 0" off (recalibrate mag on change).
Cheers Rob

Edit: Look for "todays snapshot" here https://github.com/Crashpilot1000?tab=repositories
Edit, Edit: Autostart works now very nice (with that std dev stuff, reliable minimal starthight is now 2m). The climbrate is lowered when reaching targethight. Dunno how its implemented in other projects but it works. You can trigger Autostart when copter is freshly armed (has not flown), Althold engaged and Throttlestick is put to center (and a targethight is set of course - see readme). Note: Stand back during that, it *WILL* work and fly into your face. Tested with and without sonar.

That is great news!

Thanks to all the effort you've been putting into it.

The only thing missing would be support for the current sensor no? I was checking on the documentation and I couldn't find if it supports or not.
Either with arducam or kvosd both expect the amp draw to be provided by the FC.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Oct 08, 2013 4:46 pm

I think with kvosd you can solder up an ampere sensor. I am currently not working on that. I know some people want to know the ampdraw, well with my frsky + DHTU its no problem to see that when attaching the ampsensor to the rx but i just did it once to check the hoverthrottle (it was like ecalc predicted). In planes the used mAh are interesting (1h flight time, motor on/off etc) but in copters with relatively short and very predictable flighttimes it's not such a big informationgain imho. It might come in handy when doing a compass motor compensation (like arducopter) but the sense of that is doubtful in my eyes, since a correct mag mounting/setup beats the sh** out of that single correction factor for each axis stuff. So I am currently not up to that current stuff.....

msev · Post by **msev** » Thu Oct 10, 2013 5:26 pm

Crashpilot, since now u have the Radian Pro...you could rule Arduplane out of the equation, and use naze32 also for plane ph,rth etc.

...Its a nice small board compared to the giant diydrones hardware... Could u add that to your to-do list

jingej · Post by **jingej** » Fri Oct 11, 2013 10:46 am

ok, since in baseflight my suggestion is "useless shit" for TC, i may ask here: is it possible to activate the one-pulse mode (one-shot) output of the STM? there are ESCs around who use it and it makes flying even more stable (tested with multiwii... it is a difference)

Gaijin · Post by **Gaijin** » Fri Oct 11, 2013 4:37 pm

Crashpilot1000 wrote:Hi, satnaam!
Yep my private little project keeps on rolling . The 2.6 final is not ready because I want to reorganize some of the GPS stuff and squeeze that "I returned to home but do sometimes not autoland" bug and needs more testing. The current repo has bin and hex files in the main directory (github didn't like the obj folder) - they are tested without gps functions so pre 2.6 (klick in the right corner to download the whole stuff as zip file).
BTW: I've heard that Harakiri won't run on naze V5. Well I am not planning to buy that v5 stuff, because I see no real benefit in that hardware (and I can not shit money to waste for compatibility), so if you run into that problem you will have to change the code somehow to make it compatible (probably some drv_system / hse stuff), I am currently not looking into that. V4/V3?, Whitespy boards and Flyduino boards will still be compatible. Maybe one fine day the main BF trunc is supplied with some decent GPS code and other useful functions so I can stop that here.
Greets Rob

Hey Rob, Maybe we could have a whip round and fund a V5 Naze32 so you can keep it in the loop, I'm happy to make a donation, I really like your branch of code and V4's are going to get tricky to find soon enough, what will I do for future builds?
Plus TC isn't really all that interested in GPS support atm, surely you could use the extra flash for waypoints and other nav features?

satnaam · Post by **satnaam** » Sat Oct 12, 2013 12:06 am

Hi Rob, Gaijin is right. I'm happy to make a donation too if needed to help out. You are doing good work, this is my way to say thanks and continue this on future boards.
fred

Crashpilot1000 · Post by **Crashpilot1000** » Sat Oct 12, 2013 11:00 am

@msev: Thank you very much for your trust, that I could do an airplane branch, but I am too stupid for that. My last rc plane was a gas cessna 25years ago.. and my radian pro has not been maidened yet because I still have some really stupid software setup issues with the #$&%& arduplane and my mounting, maybe a few hours of wiki will solve that otherwise the maiden will be in passthrough.. Johannes did some work on the Naze airplane part here: http://fpv-treff.de/viewtopic.php?f=18& ... 160#p36733. I think airplane should be a different firmware maybe based upon gentlenav. For basic stabilization i would go for a small and simple Hype X3 instead of some mwii/naze but thats only me.
@jingej: Well TC is the ESC and FC guy, if he says that it's sh** it maybe so. I think you are aiming at that, what ronco tried out/did on his nanowii project. If you say that this is practical beneficial it is def. something to look into. Would such an altered pwm generation even produce better results on "normal" esc - or is there a need for a special esc FW (I have blheli on my esc)? I guess during development of such a feature an oscilloscope may come in very handy... I will keep that in mind but have currently no clue how to do it. If anyone has some code to test that out it would be very welcome.

@Gaijin@satnaam: Thank you very much for your supportive intentions!! But I think I will skip that v5 hardware for now. If the sensors would have been on SPI and the extra storage would have been on I2C - I would have been the first person to rush out and buy 2 of them and burn my naze4. Extra memory will come in handy when storing WP of course but you can also do it (in smaller extend) on the v3/v4/flip32/flyduino. I will look into the compatibility stuff tomorrow and hopefully come up with a version to try out on v5.
Cheers Rob

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Sun Oct 13, 2013 8:15 pm

Hi Rob,
What Toolchain/IDE so you use for Harakiri coding/debugging?

Timecop is using Keil for Baseflight coding.

I'd like to add my own OLED and GPS driver (full NMEA Support) to either Baseflight or Harakiri.

Kind regards
aBUGSworstnightmare

hinkel · Post by **hinkel** » Mon Oct 14, 2013 8:50 am

Hi Roberto !

Just a Proposal for next Harakiri code revision :
http://www.multiwii.com/forum/viewtopic.php?f=8&t=2918&start=640#p42268

Best Regards
hinkel

timecop · Post by **timecop** » Mon Oct 14, 2013 9:15 am

aBUGSworstnightmare wrote:add my own OLED

man, I hope it looks better than this...
https://code.google.com/p/multiwii/sour ... D.cpp#1905

cGiesen · Post by **cGiesen** » Mon Oct 14, 2013 2:19 pm

timecop wrote:
aBUGSworstnightmare wrote:add my own OLED

man, I hope it looks better than this...
https://code.google.com/p/multiwii/sour ... D.cpp#1905

How make it better?

Crashpilot1000 · Post by **Crashpilot1000** » Mon Oct 14, 2013 2:48 pm

Short notice, a first test Version for v5 is in the github repo.
@Hinkel: Well an osd switch why not. I have to find the code behind that.
@aBUGSworstnightmare: I am using the free version of Keil + gcc. So you want to do another I2C oled driver. Well, perhaps it's better to do that on TC code, because I will probably discard that complete oled stuff if free mem will become an issue (some LED/LEDring stuff / unused drivers will die first, of course).

timecop · Post by **timecop** » Mon Oct 14, 2013 3:09 pm

cGiesen wrote:
timecop wrote:
aBUGSworstnightmare wrote:add my own OLED

man, I hope it looks better than this...
https://code.google.com/p/multiwii/sour ... D.cpp#1905

How make it better?

If it isn't immediately obvious, then I don't think there's any reason to explain further..

hinkel · Post by **hinkel** » Mon Oct 14, 2013 3:34 pm

Crashpilot1000 wrote:Short notice, a first test Version for v5 is in the github repo.
@Hinkel: Well an osd switch why not. I have to find the code behind that.

Hi Roberto !

I send you the code over FPV-Treff forum in PM.
Because have issue with this Multiwii forum to send the file.

Best Regards
hinkel

disq · Post by **disq** » Wed Oct 16, 2013 11:50 am

Crashpilot1000 wrote:Short notice, a first test Version for v5 is in the github repo.

You should add a zero-byte to MSP_STATUS reply to indicate current profile id even if Harakiri doesn't yet support profiles. Just to avoid breaking MSP. ("global_conf.currentSet" in msp documentation)

Here's a quick diff:

Code: Select all

--- old/Harakiri-SG2.6/src/serial.c   2013-10-16 13:47:28.000000000 +0300
+++ new/Harakiri-SG2.6/src/serial.c   2013-10-16 13:47:38.000000000 +0300
@@ -204,7 +204,7 @@
         serialize32(PLATFORM_32BIT);        // "capability"
         break;
     case MSP_STATUS:
-        headSerialReply(10);
+        headSerialReply(11);
         serialize16(cycleTime);
         serialize16(i2cGetErrorCounter());
         serialize16(sensors(SENSOR_ACC)                   |
@@ -226,6 +226,7 @@
                     f.PASSTHRU_MODE        << BOXPASSTHRU |
                     rcOptions[BOXBEEPERON] << BOXBEEPERON |
                     rcOptions[BOXHEADADJ]  << BOXHEADADJ);
+        serialize8(0);
         break;
     case MSP_RAW_IMU:
         headSerialReply(18);

aBUGSworstnightmare · Fri Oct 18, 2013 11:47 am

Hi,

the OLED driver is already proven/tested on Cortex M3 and M4 devices.
It also includes an OLEDstdio function which makes live a little easier.

The info from the (doxgen) function header is below.

Code: Select all

//*****************************************************************************
//
//! A simple I2C based printf function supporting \%c, \%d, \%p, \%s, \%u,
//! \%x, and \%X for use with OLED displays.
//!
//! \param pcString is the format string.
//! \param ... are the optional arguments, which depend on the contents of the
//! format string.
//!
//! This function is very similar to the C library <tt>fprintf()</tt> function.
//! All of its output will be sent to the I2C.  Only the following formatting
//! characters are supported:
//!
//! - \%c to print a character
//! - \%d or \%i to print a decimal value
//! - \%s to print a string
//! - \%u to print an unsigned decimal value
//! - \%x to print a hexadecimal value using lower case letters
//! - \%X to print a hexadecimal value using lower case letters (not upper case
//! letters as would typically be used)
//! - \%p to print a pointer as a hexadecimal value
//! - \%\% to print out a \% character
//!
//! For \%s, \%d, \%i, \%u, \%p, \%x, and \%X, an optional number may reside
//! between the \% and the format character, which specifies the minimum number
//! of characters to use for that value; if preceded by a 0 then the extra
//! characters will be filled with zeros instead of spaces.  For example,
//! ``\%8d'' will use eight characters to print the decimal value with spaces
//! added to reach eight; ``\%08d'' will use eight characters as well but will
//! add zeroes instead of spaces.
//!
//! The type of the arguments after \e pcString must match the requirements of
//! the format string.  For example, if an integer was passed where a string
//! was expected, an error of some kind will most likely occur.
//!
//! \return None.
//
//*****************************************************************************
void
I2COLEDprintf(const char *pcString, ...)
..

By the way: the code is fully documented; the headers come with doxgen comments.

Well, nowbody is forced to use some of that stuff, but maybe some other folks are around who will find it usefull.

Crashpilot1000 wrote:@aBUGSworstnightmare: I am using the free version of Keil + gcc. So you want to do another I2C oled driver. Well, perhaps it's better to do that on TC code, because I will probably discard that complete oled stuff if free mem will become an issue (some LED/LEDring stuff / unused drivers will die first, of course).

That means the total codesize is less than 32kB or do you just use Keil as the IDE?
Why should there be an issue with codesize? The device is a 128kB flash device.

Kind regards
aBUGSworstnightmare

aBUGSworstnightmare · Fri Oct 18, 2013 11:55 am

timecop wrote:
aBUGSworstnightmare wrote:add my own OLED

man, I hope it looks better than this...
https://code.google.com/p/multiwii/sour ... D.cpp#1905

Hi Timecop,

just had a brief look only! Well, I think it's better than this.

aBUGSworstnightmare

disq · Post by **disq** » Fri Oct 18, 2013 12:53 pm

Here is another useful patch, backported from baseflight (jef78m is the original author, https://code.google.com/p/afrodevices/s ... tail?r=350 )

Allows dumping of matching cmdline variables by running an incomplete set command. ie. something like "set gps" will dump all gps variables. (I tried with stristr/strcasestr, but couldn't make it ignore case, maybe due to toolchain.. imo all variables should be lowercase anyway)

Code: Select all

--- old/Harakiri-SG2.6/src/cli.c   2013-10-18 14:46:41.000000000 +0300
+++ new/Harakiri-SG2.6/src/cli.c   2013-10-16 15:04:30.000000000 +0300
@@ -1153,6 +1153,16 @@
             }
         }
         cliErrorMessage();  // uartPrint("ERR: Unknown variable name\r\n");
+    } else {
+        // no equals, check for matching variables.
+        for (i = 0; i < VALUE_COUNT; i++) {
+            if (strstr(valueTable[i].name, cmdline)) {
+                val = &valueTable[i];
+                printf("%s = ", valueTable[i].name);
+                cliPrintVar(val, 0);
+                printf("\r\n");
+            }
+        }
     }
 }

timecop · Post by **timecop** » Fri Oct 18, 2013 1:06 pm

Here's an amazing idea: how about if harakiri actually had maintanable code base with their improvements (if any) separated so that they could easily upgrade to latest baseflight, without fucking shit up? Oh, right...

subaru4wd · Post by **subaru4wd** » Sat Oct 19, 2013 2:54 am

timecop wrote:Here's an amazing idea: how about if harakiri actually had maintanable code base with their improvements (if any) separated so that they could easily upgrade to latest baseflight, without fucking shit up? Oh, right...

Oh did you finally fix baseflight? :roll:

timecop · Post by **timecop** » Sat Oct 19, 2013 7:06 am

It wasn't broken

Truglodite · Post by **Truglodite** » Sat Oct 19, 2013 11:25 pm

I am currently runningSG2.5 at 80mhz using the simple "chatch patch":

http://fpvlab.com/forums/showthread.php ... post347836

In Harakiri SGpre2.6 (also Baseflight r445), system_stm32f10x.c has changed significantly.

http://fpvlab.com/forums/showthread.php ... post360229

I didn't want to try changing all the references to "RCC_CFGR_PLLMULL9" to "RCC_CFGR_PLLMULL10" without checking first. Can anyone advise how the latest code can be patched to run at 80mhz?

Kev

timecop · Post by **timecop** » Sun Oct 20, 2013 7:47 am

You want to change this line:
RCC_CFGR_PLLMUL = GPIOC->IDR & CAN_MCR_RESET ? hse_value = 12000000, RCC_CFGR_PLLMULL6 : RCC_CFGR_PLLMULL9;
6->7
RCC_CFGR_PLLMULL6 -> RCC_CFGR_PLLMULL7 and
RCC_CFGR_PLLMULL9 -> RCC_CFGR_PLLMULL10

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Sun Oct 20, 2013 8:20 am

Hi Timecop,

looks like I've made some more progress with my Keil <--> ARM Tools issue.

I've added your startup_..._gcc.s as requested but had to modify your comments to make it assemble.
Comment style needs to be changed from

Code: Select all

// HJI - TC bootloader entry on reset mod

to

Code: Select all

/* HJI - TC bootloader entry on reset mod */

It still doesn't link; will have to edit the linker script file next.

Rgds
Joerg
aBUGSworstnightmare

timecop · Post by **timecop** » Sun Oct 20, 2013 9:00 am

Looks like you just need to declare something like int __errno; in some file?

Truglodite · Post by **Truglodite** » Sun Oct 20, 2013 8:20 pm

Roger that TC, and thank you very much! I knew you would be the one to answer. BTW, it did work, and here's the output:

Code: Select all

# version
Harakiri10 Summer Games 2.6Oct 20 2013 / 12:09:33
# status

System Uptime: 117 sec, Volt: 0 * 0.1V (3S battery)
CPU 80MHz, detected sensors: ACC BARO MAG ACC: MPU6050
Cycle Time: 3009, I2C Errors: 0

Total : 2996 B
Config: 656 B
Logger: 2340 B, 0 Datasets

Stats:

Baro:
Max Alt AGL: 0 m
Min Alt AGL: 0 m

Motor:
Actual Range: 1150 - 1950 at 400 Hz PWM.
Nothing!

#

The only weird part for me was... in Eclipse I copied the stock pre2.6 project, renamed it, changed that 6 and 9, compiled, loaded, and upon connecting to CLI it still read SG2.5, and status showed 8MHZ? I verified the hex file was the correct date. The problem appears to have been fixed after I did a "clean" and "build". The recent removal of the "spektrum.c" file also caught me off guard when I copied 2.5 to make my 2.6 project in Eclipse.

Kev

timecop · Post by **timecop** » Mon Oct 21, 2013 9:03 am

You did something wrong, on rev5 w/12MHz xtal and * 7 pll you should be running at 84MHz

Truglodite · Post by **Truglodite** » Mon Oct 21, 2013 7:42 pm

Sorry, I should have specified I am working with a rev4 board, not rev5. Should I be doing something different?

The code seems to be working OK on my bench, but I haven't test flown it yet.

Kev

IceWind · Post by **IceWind** » Tue Oct 22, 2013 12:30 am

Hey, do you guys have the KV-OSD latest release r370 working fine with the latest Hrakiri version?

I get most of the stuff working, but for example it doesn't detect when the FC is armed as well as it doesn't some other details.
Like the active features, GPS HPS, HOLD, MAG,...

timecop · Post by **timecop** » Tue Oct 22, 2013 1:17 am

Truglodite wrote:Sorry, I should have specified I am working with a rev4 board, not rev5. Should I be doing something different?

The code seems to be working OK on my bench, but I haven't test flown it yet.

Kev

rev4 will be at 80, rev5 will be at 84.

hinkel · Post by **hinkel** » Tue Oct 22, 2013 7:21 am

IceWind wrote:Hey, do you guys have the KV-OSD latest release r370 working fine with the latest Hrakiri version?

I get most of the stuff working, but for example it doesn't detect when the FC is armed as well as it doesn't some other details.
Like the active features, GPS HPS, HOLD, MAG,...

http://www.multiwii.com/forum/viewtopic.php?f=8&t=2918&hilit=minimosd&start=640#p42328

http://fpv-treff.de/viewtopic.php?f=18&t=2202&p=47735&hilit=minimosd#p47726

DrEvil · Post by **DrEvil** » Tue Oct 22, 2013 10:43 am

Hi
I have been trying to set up a flying wing with SG2.5 on my ver.4 board.
I gotmost tings working, but can not arm the motor.
Servo's are working and all seems fine, all but motor.
Baseflight2 gui works, but somewhat unstable.
In gui all rc/servo show's but not motor in "live rc", throttel indicates proper link.

I have also flashed latest baseflight with the same error.
I have been several month's away from the Naze32 universe, :-)

so please bare with me :-)

I'm a little lost atm.

Kai

IceWind · Post by **IceWind** » Wed Oct 23, 2013 8:51 pm

hinkel wrote:
IceWind wrote:Hey, do you guys have the KV-OSD latest release r370 working fine with the latest Hrakiri version?

I get most of the stuff working, but for example it doesn't detect when the FC is armed as well as it doesn't some other details.
Like the active features, GPS HPS, HOLD, MAG,...

http://www.multiwii.com/forum/viewtopic.php?f=8&t=2918&hilit=minimosd&start=640#p42328

http://fpv-treff.de/viewtopic.php?f=18&t=2202&p=47735&hilit=minimosd#p47726

[vimeo] http://vimeo.com/76970479[/vimeo]

Thanks!
While I was searching I noticed that but thought it was just to control the display of the OSD data.

hinkel · Post by **hinkel** » Thu Oct 24, 2013 4:37 pm

Hi!

Because I use Harakiri SG2.5 on Naze32 rev4 and KVteamosd I change the Code from Harakiri SG2.5 and KVteamosd R370 to have an Indication of FAILSAFE issue in OSD ( no RSSI Signal with my crappy receiver ) the GPS Coordinates will be display always in this case. Also the Osdswitch disable 80% from display now !

If someone is interest ?

Regards
hinkel

Ramei · Post by **Ramei** » Thu Oct 24, 2013 11:39 pm

hinkel wrote:Hi!

Because I use Harakiri SG2.5 on Naze32 rev4 and KVteamosd I change the Code from Harakiri SG2.5 and KVteamosd R370 to have an Indication of FAILSAFE issue in OSD ( no RSSI Signal with my crappy receiver ) the GPS Coordinates will be display always in this case. Also the Osdswitch disable 80% from display now !
http://vimeo.com/77699275

If someone is interest ?

Regards
hinkel

Hi Hinkel,

realy great job.

I use the same configuration and I'm very interested in the osd-switch.

Can you share the osd-sketch and the harakiri-hex.

Thanks,
Ralf

Crashpilot1000 · Post by **Crashpilot1000** » Fri Oct 25, 2013 4:58 am

@hinkel: Sorry for not checking back your pm in the other forum, maybe you can attach your code here as a zip for all?
@disq: Thank you very much for your code suggestions! Yes, I am not so keen on the profiles stuff but if that missing byte from 2.2 will make life nicer I will add it. I have seen the jef78m idea but currently I am not planning to implement that.
@aBUGSworstnightmare: "Why should there be an issue with codesize? The device is a 128kB flash device."
Well my code compiles to 100K binary + 3K of storage.... and still have some ideas....
@Gaijin: The response to your sonar post in the openpilot forum was overwhelming :lol:

Speaking of that. I haven't been doing much recently codewise. But I've been farting around with sonar very much and hopefully can declare victory. The problem: Sometimes my maxbotix would work - and guess what sometimes not.
There are several problems with the current sonar driver in general.
1. Worst case: If the sonar stalls with a connection/electrical problem in flight within valid sonarrange the driver will stick to a fixed (valid but actually wrong) hight driving the rest of the code crazy and provoking a skyrocketing or falling copter. This is fixed now. A disconnect in flight is detected and sonar disabled for that complete session (reconnection ignored). You will have to have something like that in the driver because it's a real safety issue if your sonar (or connection) dies in flight and your copter *will* go crazy. Simply checking for equal hight reports in a row over time will not do it, because it can be achieved on the ground or during (sonar/baro/acc fusioned) althold.
2. Somehow the gcc compiler messes up the interrupt driver at will. I stumbled upon that info on a german site (link lost, was some introduction to discovery boards). The problem is that the setting back of the interrupt bit has to be done in the first line of the interrupt handler. So that line: https://code.google.com/p/afrodevices/s ... csr04.c#43 should the first line, otherwise gcc can optimize it to a fail. Really don't know whats behind that gcc magic but that info def. fixed my maxbotix issue. I attached the sonardriver for reference, maybe it is of some use for BF as well down the road. I think probably it could be done smarter but it works.

Cheers
Rob

P.s.: Currently implementing a new flightmode idea. Good or bad, I will see..,

Code: Select all

#include "board.h"
#include "mw.h"

#ifdef SONAR
/*
Currently supported Sonars: (the links are just examples, I didn't buy them there)
HC-SR04  *** Warning: HC-SR04 operates at +5V *** (google that, price around 5$ range about 2m)

DaddyWalross did an I2C "pimp" of the HC-SR04 with the idea in mind to connect several modules at once:
http://fpv-community.de/showthread.php?20988-I%B2C-Sonarplatinen

Maxbotics Sonars using PWM readout (expensive stuff, probably some people have them from APM)

ToDo?:
Other I2C Sonars: SRF02 SRF08 SRF10 SRC235 (all the same protocol)
http://www.shop.robotikhardware.de/shop/catalog/product_info.php?products_id=121

SOME INFO:

UncompDivisor:
==============
+35C 352,17 m/s = 56,79 is the divisor
+20C 343,46 m/s = 29,115 us/cm so we measure double time so: 58,23 is the divisor
-10C 325,35 m/s = 61,47 is the divisor

Error chart we measure 5823us:
+35 C  102 CM
+20 C  100 CM
-10 C   95 CM
So no Temp compensation and taking "58" as divisor seems sufficient to me.
But for the precise people, here is further info:

Temp. Compensation (taken from Maxbotics):
==========================================
(Source: http://www.maxbotix.com/documents/Temperature_Compensation.pdf)

40C to +65C (with limited operation to +85C).
Temperature Compensation that uses the time of flight in seconds, and temperature in degrees centigrade and yields the
distance in meters works for all of our products.

Dm = TOF *((20.05*SQRT(Tc+273.15))/2)
TOF is the measured Time Of Flight in seconds,
Tc is the ambient temperature in degrees C,
Dm is the distance in meters.

For 23 degrees C and 0.0058 seconds (or 5.8mS) the
distance calculates to 1.0006 meter.
If using the Serial output, first convert the distance reported by the sensor to TOF by using 147uS per inch
(TOF = inches * 1.47E-4) or 58uS per cm (TOF = cm * 5.8E-5) and then insert the TOF into the above formula.
*/

#define SONARDW_ADDRESS      0x20       // DaddyW I2C SONAR, Standard address 0x20 to 0x27  7bit!!!
#define SONARDW_DISTANCE_OUT 0x32       // NOT USED HERE #define SONARDW_ADC_OUT           0x33
#define SR04Cycle       60              // Cycletime in ms
#define MaxboticsCycle 100              // Cycletime in ms
#define DaddyWCycle     60              // Since DaddyW Sonar uses SR04 we assume that updaterate
#define UncompDivisor   58              // Temp Compensation currently not implemented

static uint16_t  trigger_pin;           // why not 8 bit ?
static uint16_t  echo_pin;
static uint32_t  exti_line;
static uint8_t   exti_pin_source;
static IRQn_Type exti_irqn;
static uint32_t  last_measurement;
static uint16_t  PulseLimitInUs;
static volatile  int32_t result;
static volatile  uint32_t calltime;

void ECHO_EXTI_IRQHandler(void)
{
    EXTI_ClearITPendingBit(exti_line);                                  // This must be done here, otherwise gcc will optimize it to being useless, dunno why, was mentioned on a website.
    static uint32_t timing_start = 0;
    int32_t pulse_duration;

    calltime = micros();
    if(GPIO_ReadInputDataBit(GPIOB, echo_pin)) timing_start = calltime; // Up flank detected
    else
    {                                                                   // Since interrupt is triggered by changes this is probably the downflank
        pulse_duration = (int32_t)(calltime - timing_start);
        if (pulse_duration > 174 && pulse_duration < PulseLimitInUs) result = pulse_duration; // something like 3 cm - X (X selected by sonartype)
        else result = 0;
    }
}

void EXTI1_IRQHandler(void)
{
    ECHO_EXTI_IRQHandler();
}

void EXTI9_5_IRQHandler(void)
{
    ECHO_EXTI_IRQHandler();
}

bool Snr_init(void)
{
     uint8_t          bufdaddy[2];                               // Dummy for i2c testread
    gpio_config_t    gpio;
    EXTI_InitTypeDef EXTIInit;

    // enable AFIO for EXTI support - already done is drv_system.c
    // RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO | RCC_APB2Periph, ENABLE); 
    // cfg.snr_type = X;  0 = PWM56, 1 = RC78, 2 = I2C (DaddyWalross), 3 = MBPWM56, 4 = MBRC78
    switch (cfg.snr_type)                                       // Switch according physical connection pins
    {
    case 0:                                                     // case sonar_pwm56
    case 3:
        if (NumberOfMotors > 4 || feature(FEATURE_SERVO_TILT)) return false; // End here, if PWM5/6 Sonar not possible
        trigger_pin     = Pin_8;                                // PWM5 (PB8) - 5v tolerant
        echo_pin        = Pin_9;                                // PWM6 (PB9) - 5v tolerant
        exti_line       = EXTI_Line9;
        exti_pin_source = GPIO_PinSource9;
        exti_irqn       = EXTI9_5_IRQn;
        break;
    case 1:                                                     // case sonar_rc78
    case 4:
        if (!feature(FEATURE_PPM)) return false;                // End here, if rc7/8 Sonar not possible, further motornumber checks missing
        trigger_pin     = Pin_0;                                // RX7 (PB0) - only 3.3v ( add a 1K Ohms resistor )
        echo_pin        = Pin_1;                                // RX8 (PB1) - only 3.3v ( add a 1K Ohms resistor )
        exti_line       = EXTI_Line1;
        exti_pin_source = GPIO_PinSource1;
        exti_irqn       = EXTI1_IRQn;
        break;
    case 2:                                                     // case sonar_i2cDW Deal with I2C daddy walross sonar
        delay(1000);                                            // sleep for 1000ms to startup sonar
        return i2cRead(SONARDW_ADDRESS, SONARDW_DISTANCE_OUT, 2, bufdaddy); // End this here
    }

    switch(cfg.snr_type)                                        // Switch according to sonar model
    {
    case 0:                                                     // Check for HC-SR04
    case 1:
        PulseLimitInUs = 24000;                                 // HC-SR04 Limit 413 cm
        break;
    case 3:                                                     // Check for Maxbotics
    case 4:
        PulseLimitInUs = 62000;                                 // Datasheet Limit 62ms
        break;
    }
    // tp - trigger pin
    gpio.pin   = trigger_pin;
    gpio.mode  = Mode_Out_PP;
    gpio.speed = Speed_2MHz;
    gpioInit(GPIOB, &gpio);
    // ep - echo pin
    gpio.pin   = echo_pin;
    gpio.mode  = Mode_IN_FLOATING;
    gpioInit(GPIOB, &gpio);
    // setup external interrupt on echo pin
    GPIO_EXTILineConfig(GPIO_PortSourceGPIOB, exti_pin_source);
    EXTI_ClearITPendingBit(exti_line);
    EXTIInit.EXTI_Line    = exti_line;
    EXTIInit.EXTI_Mode    = EXTI_Mode_Interrupt;
    EXTIInit.EXTI_Trigger = EXTI_Trigger_Rising_Falling;
    EXTIInit.EXTI_LineCmd = ENABLE;
    EXTI_Init(&EXTIInit);
    NVIC_EnableIRQ(exti_irqn);
    last_measurement = 0;                                       // Force 1st measurement in XXX_get_distance
    return true;
}

static void CheckDisconnect(void)                               // Important! Check for disconnect in flight to avoid stall value do a copter rocketjump
{
    if ((micros() - calltime) > 1000000)                        // Interrupt has stalled for 1 sec, disconnect error.
    {
        sensorsClear(SENSOR_SONAR);
        SonarStatus = 0;
    }
}

bool hcsr04_get_distancePWM(volatile int32_t *distance)         // HC-SR04
{
    uint32_t current_time = millis();
    static bool inidone = false;
    if(current_time < (last_measurement + SR04Cycle)) return false; // repeat interval should be greater 60ms. Avoid interference between measurements.
    last_measurement = current_time;
    *distance = result / UncompDivisor;
    GPIO_SetBits(GPIOB, trigger_pin);                           // Trigger new "Ping"
    delayMicroseconds(11);                                      // The width of trig signal must be greater than 10us
    GPIO_ResetBits(GPIOB, trigger_pin);
    if (inidone) CheckDisconnect();                             // Skip first trigger/read cycle for disconnect test
    else inidone = true;
    return true;                                                // Always return true when time is up, even with errorvalue of 0
}

bool MaxBotix_get_distancePWM(volatile int32_t *distance)       // Maxbotics PWM support. Tested on MB1200 XL-MaxSonar-EZ0.
{                                                               // Just Connect Echopin!!
    uint32_t current_time = millis();
    if(current_time < (last_measurement + MaxboticsCycle)) return false;// MaxBtx needs min 99 ms here
    last_measurement = current_time;
    *distance = result / UncompDivisor;
    CheckDisconnect();                                          // We can check directly, because no triggering is needed and interrupt is running for seconds already (sonar blocked during groundaltini)
    return true;                                                // Always return true when time is up, even with errorvalue of 0
}

bool DaddyW_get_i2c_distance(int32_t *distance)
{
    uint8_t  buf[2];
    int16_t  temp;
    uint32_t current_time = millis();
    if(current_time < (last_measurement + DaddyWCycle)) return false; // Hopefully DaddyW Sonar works with that timing
    last_measurement = current_time;
    if(i2cRead(SONARDW_ADDRESS, SONARDW_DISTANCE_OUT, 2, buf))
    {
        temp = (int16_t)((buf[1] << 8) | buf[0]);
        *distance = (int32_t)(temp / UncompDivisor);
     }
    else *distance = 0;                                         // Error, Sonar not responding
    return true;                                                // Always return true when time is up, even with errorvalue of 0
}
#endif

Not shure if that "pulse_duration = (int32_t)(calltime - timing_start);" followed by the positive limit test should be better changed back to if(calltime > timing_start) stuff. I think I will change that.
EDIT: Changed to that:

Code: Select all

void ECHO_EXTI_IRQHandler(void)
{
    EXTI_ClearITPendingBit(exti_line);                                  // This must be done here, otherwise gcc will optimize it to being useless, dunno why, was mentioned on a website.
    static uint32_t timing_start = 0;
    uint32_t pulse_duration;

    calltime = micros();
    if(GPIO_ReadInputDataBit(GPIOB, echo_pin)) timing_start = calltime; // Up flank detected
    else
    {
        pulse_duration = calltime - timing_start;
        if (pulse_duration > 174 && pulse_duration < PulseLimitInUs && calltime > timing_start) result = pulse_duration; // something like 3 cm - X (X selected by sonartype)
        else result = 0;
    }
}

EDIT: EDIT: Here is the actual good working version: https://github.com/Crashpilot1000/SGTod ... rv_sonar.c

Gaijin · Post by **Gaijin** » Fri Oct 25, 2013 8:24 am

@Gaijin: The response to your sonar post in the openpilot forum was overwhelming

Yeah, The OP forums are kinda quiet on the surface, I think all the really interesting dev stuff takes place in closed channels

Ah well, I tried! :roll:

subaru4wd · Post by **subaru4wd** » Fri Oct 25, 2013 4:59 pm

Hey Rob, Can you give us some details on how Return to Home is supposed to work? Does it include baro readings? Compass? or do we have to select Baro & Mag seperately in the GUI along with RTH for those readings to take effect?

Reason I ask, is i did a RTH test the other day. After a couple batteries, and flying around with 10 sat's all day. As soon as I flipped the RTH switch, it was as if nothing happened. My OSD shows the quadcopter still in Angle Mode, but then a few seconds later it switches into GPS HOLD and begins to drift around. I was in a huge vacant area, so I just let it do its thing while I watched my FPV screen. After maybe 20-30 seconds of GPS HOLD, it then switched into HOME mode. It looks like it tried to rotate to face home, but instead it just starts flying sideways. It was flying towards home, however the quadcopter was downwind, so the wind could have been blowing it back home. After a few seconds of traveling, the quadcopter began to descend rapidly. This is when I turned off RTH and regained control.

Im not sure why it began to descend like it did, maybe I was falling asleep and reduced throttle on my own. I plan to do some more tuning to the NAV PID's, and then perform some more tests. I am just not sure what I should expect. I have used the RTH function with MultiWii 2.2 on 8bit boards, and it performs differently than what I am experiencing with Harakiri.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Oct 25, 2013 6:57 pm

Well, when RTL is activated the other needed boxes are turned on automatically. It sounds like magnetometer problems with your setup. When it flies in the wrong direction, (nearly) no matter what your pids are its a mag/declination problem. The bearing calculation is much more precise than in mwii (arduino gets into time trouble when doing that the correct way - I was taught by a major apm moneybloke, after posting a suggestion to correct that awful bad calculation) - it will look directly in your eye (if that is activated, and if you are standing at the arming spot)...
NEVER CALIBRATE MAG WITH A COMPUTER WIRED TO IT (MAYBE BT IS A DIFFERENT STORY - I DON't HAVE THAT)!!!!! Power up the copter in the field and apply the mag calibration stick command!!! Without the lipo the mag offsets must be off (no matter what tarducopter videos suggest, their mag calibration IS def. inferior to harakiri and MUST fail), when wired to a computer running a gui besides that the usb/computer/cable/building/car or wherever the computer sits in - will disturb. A clean working mag is a must.
You can set mag_gain = 1 (0 is default) to lower sensitivity of mag to make it a little bit more resilient (with pre2.6, don't forget to recalibrate after changing that)
EDIT: YOU WILL ALWAYS HAVE AUTHORITY WITH YOUR STICKS IN ANY GPS MODE. IT WILL NEVER PUT YOU OUT OF CONTROL - IT WILL BAIL OUT A GPS FUNCTION - THAT'S MY SAFETY PHILOSOPHY (if a sunstorm or some pentagon guy decides to suddenly disturb the gps, besides that there has always been a spikefilter at play when the reception suddenly drops... "glitches" is the unword 2013 for me, not introduced by me... just to cover a major design/program failure). That's why there is a special TX deadband for GPS functions (rc_dbgps) that will add up to the "normal" rc_db.
Cheers mate.