Harakiri aka multiwii port to stm32

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

Re: Harakiri aka multiwii port to stm32

Post by timecop »

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
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

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

Last edited by hinkel on Fri Nov 29, 2013 9:56 pm, edited 1 time in total.

DrEvil
Posts: 17
Joined: Mon Sep 10, 2012 12:23 pm

Re: Harakiri aka multiwii port to stm32

Post by DrEvil »

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

User avatar
IceWind
Posts: 115
Joined: Fri Mar 25, 2011 2:11 am
Contact:

Re: Harakiri aka multiwii port to stm32

Post by IceWind »

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
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

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
Last edited by hinkel on Fri Nov 29, 2013 10:05 pm, edited 3 times in total.

Ramei
Posts: 2
Joined: Wed Apr 17, 2013 11:27 pm

Re: Harakiri aka multiwii port to stm32

Post by Ramei »

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

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@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
Last edited by Crashpilot1000 on Sun Oct 27, 2013 8:17 pm, edited 1 time in total.

User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: Harakiri aka multiwii port to stm32

Post by Gaijin »

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


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
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

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.

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

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.
Last edited by Crashpilot1000 on Fri Oct 25, 2013 7:29 pm, edited 1 time in total.

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

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

Okay, but why does it pause then enter GPS Hold??? Then stay in GPS Hold for a minute before going into GPS Home?

Would it be possible to make just a simple RTH mode, with no compass or baro or anything?? I don't care if the craft returns to home nose in, just so long as it starts to return home... and immediately. This is for my failsafe, which I will program in my Receiver so if there is a loss of signal, the quad starts to return. As soon as I regain radio control, i would leave RTH and resume my flight.

The way it is now, if I lose radio, my failsafe just applies 80% throttle and sits in Angle mode. This could cause it to drift farther out of range, and who know's where it would be by the time it entered RTH.

Next time I am out in the field and ready to RTH test, I will do a Mag Calibration before hand. Now that I remember, the last Mag Calibration I performed was on the bench, before I even installed the flight controller /facepalm

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

After engaging RTH in full flight, it will brake and do a PH & Althold (and gain some hight, if specified), if some requirements are fulfilled the RTH is engaged. So when your mag isn't working properly that stuff goes wrong in the first place. An RTH without MAG is possible on copters (easier on planes, naturally they always move according to the nose, besides from some wind crosstrack - so the very nice ublox gps heading resemble very good the actual plane heading) but I will not spend time on figuring that out (reason: 1st: Own stupidity/inability 2nd: Codesize is also some monster grinning at me). A failsafe function without baro seems like an idea from the 19th century today (sorry for those harsh words), since those parts (bmp085 will do) sell for less than 5$ and can guarantee a smooth landing without a predefined throttle and secure your investment (copter). Offering flightcontrols that are assumed to do a little more than a KK today without a baro is beyond my understanding. Everybody is bitching about the poor BMP085 (or the smaller BMP180) but if handled properly in code, it does a reasonably good job (of course can not rival to ms5611, but not shabby at all).
Cheers to you
Rob
Last edited by Crashpilot1000 on Fri Oct 25, 2013 8:02 pm, edited 1 time in total.

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

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

Ramei wrote: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


The code was test in short flight.
I am not a programmer no warranty of all this Code , test on your own risk !

@Crashpilot1000
Feel free to do what you want with this crappy Code. This forum is a pain for me and my very bad English :( .


Regards
hinkel
Attachments
src SG25 R3750SG Harakiri MODIFIED FILES.rar
Modified Harakiri SG2.5 files
(44.39 KiB) Downloaded 206 times
SG25 KVOSD FAILSAFE HEX.rar
do not forget to change PID an other stuff in CLI. No Warranty on this code !
(105.11 KiB) Downloaded 206 times
KV_Team_OSD R370SG OSDSW FAILSAFE.rar
Code for Minimosd
(23.7 KiB) Downloaded 273 times

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

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

Crashpilot1000 wrote:After engaging RTH in full flight, it will brake and do a PH & Althold (and gain some hight, if specified), if some requirements are fulfilled the RTH is engaged. So when your mag isn't working properly that stuff goes wrong in the first place. An RTH without MAG is possible on copters (easier on planes, naturally they always move according to the nose, besides from some wind crosstrack - so the very nice ublox gps heading resemble very good the actual plane heading) but I will not spend time on figuring that out (reason: 1st: Own stupidity/inability 2nd: Codesize is also some monster grinning at me). A failsafe function without baro seems like an idea from the 19th century today (sorry for those harsh words), since those parts (bmp085 will do) sell for less than 5$ and can guarantee a smooth landing without a predefined throttle and secure your investment (copter). Offering flightcontrols that are assumed to do a little more than a KK today without a baro is beyond my understanding. Everybody is bitching about the poor BMP085 (or the smaller BMP180) but if handled properly in code, it does a reasonably good job (of course can not rival to ms5611, but not shabby at all).
Cheers to you
Rob


You are thinking of Failsafe: "Stop, return to home, auto-land"

I just need a "return to home". I have a 2nd board that is full acro, it does not have a Baro or Mag on it. I was hoping I could get a ublox and have return to home for it, but i guess maybe I will have to just get me a cheap 8bit board and use MW2.2 software for that.

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@Hinkel: Thank you very much for posting your changes here!! Very much appreciated! Cheers to you!!
@Subaru: Yes, do that and persuade the mwii2.2/2.3 code to do what you want. Don't forget to post that code, I will be very happy to implement that!
@lol:
Having another friday beer now.. the sixpack has *somehow* halfed it's capacity... stay away from guiness...veltins is my favourite... too keep it even: kilkenny is ok and budwiser is also good... *hicks*.....on german tv James Bond saving the world 197X.... without GPS and MAG or SONAR.... lol.... I wonder what you are drinking right now... if not some religion/believ/convincement keeps you away from that evil stuff.....I can not refrain on free weekends....
Cheers to all of you!
Greets
Rob

P.s.: I wonder what Japanese guys drink on fridays? Sake along with some karaoke?

Truglodite
Posts: 48
Joined: Sat Jun 22, 2013 2:37 am

Re: Harakiri aka multiwii port to stm32

Post by Truglodite »

Cheers Rob, ask if they have a 'Racer 5' IPA... one of my favorites at the local pub. I hope you feel OK tomorrow morning. ;)

timecop wrote:
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.


OK I tried testflying it, but I could never get it to calibrate compass or ACC using the stick commands. :?:

This is with "80mhz modified Harakiri SG2.6". Like I mentioned before, it did in fact show 80mhz in CLI. I triple checked everything in the latest Baseflight GUI; radio calibration, sensors, etc... AFAIK everything looks good to go. I fell back to flying 80mhz SG2.5 until I get this sorted. I have a feeling I need to change more than just those 2 numbers in the code. Any ideas why this happens? or what I should try next?

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

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

Kevin, make sure you arent trying to use stick commands with your dual rates set on the transmitter. I thought my stick commands weren't working for a while too, then i remembered to set rates back to 100% and they worked.

Truglodite
Posts: 48
Joined: Sat Jun 22, 2013 2:37 am

Re: Harakiri aka multiwii port to stm32

Post by Truglodite »

Brian, I don't have dual rates setup on my TX. I checked in baseflight GUI and all my channels are reaching 1000-2000 like they always have. To be complete, all the sensors were also responding appropriately in the GUI. I don't understand what is keeping it from entering the calibration routines, unless the 80mhz mod is not working properly.

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

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

I will check to see if the stick command for Mag Calib works on my setup and let you know Kevin.

Ramei
Posts: 2
Joined: Wed Apr 17, 2013 11:27 pm

Re: Harakiri aka multiwii port to stm32

Post by Ramei »

hinkel wrote:
Ramei wrote: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


The code was test in short flight.
I am not a programmer no warranty of all this Code , test on your own risk !

@Crashpilot1000
Feel free to do what you want with this crappy Code. This forum is a pain for me and my very bad English :( .


Regards
hinkel


Hi Hinkel,

thanks a lot for your files.

The harakiri.hex with the Osd-switch works perfekt with kv-osd r345 (unflown of course).

Only with the kv r370 I've problems. There was only displayed a black screen. But after a test with the original r370 it was the same. So the error must be on my side. I'll try it again next days.

Thanks and sorry for my bad English

Ralf

SecretSpy711
Posts: 14
Joined: Sat Oct 26, 2013 1:13 am

Re: Harakiri aka multiwii port to stm32

Post by SecretSpy711 »

hi, I have a rev5 Naze32 board (not the Acro) that I am trying to put Harakiri on, to experiment with position hold. But I'm having some trouble loading Harakiri on it.

I am using Source081513-2215Uhr (Harakiri Summer Games 2.5, baseflight_NAZE.hex) with the Carsten GUI. I've also tried it with the Flash Loader Demo. Both methods successfully update the firmware, but afterwards I can't connect to the board. Tried connecting using the Chrome app as well, without success. So I have to use the "recovery" method of shorting the bootloader pads to put Baseflight back on it.

Any ideas? What am I doing wrong?

Truglodite
Posts: 48
Joined: Sat Jun 22, 2013 2:37 am

Re: Harakiri aka multiwii port to stm32

Post by Truglodite »

The GUI has always acted buggy for me after firmware updates and CLI access... it rarely reconnects without first resetting the board and restarting the GUI.

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

Re: Harakiri aka multiwii port to stm32

Post by timecop »

SecretSpy711 wrote:hi, I have a rev5 Naze32 board (not the Acro) that I am trying to put Harakiri on, to experiment with position hold. But I'm having some trouble loading Harakiri on it.

I am using Source081513-2215Uhr (Harakiri Summer Games 2.5, baseflight_NAZE.hex) with the Carsten GUI. I've also tried it with the Flash Loader Demo. Both methods successfully update the firmware, but afterwards I can't connect to the board. Tried connecting using the Chrome app as well, without success. So I have to use the "recovery" method of shorting the bootloader pads to put Baseflight back on it.

Any ideas? What am I doing wrong?


You need newer build on rev5, it was posted somewhere in this thread.

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

So is this firmware working on Rev 5 board now? I hope so. Appreciate the work that has gone into this

SecretSpy711
Posts: 14
Joined: Sat Oct 26, 2013 1:13 am

Re: Harakiri aka multiwii port to stm32

Post by SecretSpy711 »

timecop wrote:You need newer build on rev5, it was posted somewhere in this thread.


maintainable codebase FTW!
*cough*, anyone got a link? Haven't found it yet.

Truglodite
Posts: 48
Joined: Sat Jun 22, 2013 2:37 am

Re: Harakiri aka multiwii port to stm32

Post by Truglodite »

Rob, I just had myself plenty of beer... Grolsch & Dos Equis... thought of you and checked the thread,

Maintainable what? Rob sometimes says github is good, sometimes not maintained, but hey... here you go my friend:

https://github.com/Crashpilot1000/SGTodaysSnapshot

That is where I got my pre2.6... now it's Friday night... someone else post something while drunk.

Cheers,
Kev

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

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

Hi !
Actually they are 2 PID controller in Harakiri , the first is optimal for all GPS an Angle stuff , the second Alex.K seems fine in acro mode but the PIDs are in most case different and the choice of witch controller is used must be done in CLI.
So why don't create a Alex.k PID always configurable (( eventually in Multiwiiconf also )) in CLI like this for exemple :
cfg.P8[AKROLL] = ;
cfg.I8[AKROLL] = ;
cfg.D8[AKROLL] = ;

cfg.P8[AKPITCH] = ;
cfg.I8[AKPITCH] = ;
cfg.D8[AKPITCH] = ;

cfg.P8[AKYAW] = ; //
cfg.I8[AKYAW] = ;

cfg.P8[AKPIDLEVEL] = ; //Angle
cfg.I8[AKPIDLEVEL] = ; //Horizon


The choice between first and second PID controller should be done with a switch on Radio and by use of GPS fonctions RTL and PH, the first PID controller always take the hand !

Regards
Hinkel

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

@Truglodite: I haven't tried "Racer 5", let's see where to find that canadian beer here... Really don't know why the stick commands don't work with your setup, maybe it's something with your overclocking. I don't have that barebone knowledge, I have to trust in the supplied libraries/drivers (mostly).
@SecretSpy711: I think the github version should be v5 compatible. Since I still have the arduino IDE, I mostly use the build in serial monitor (if no baudswitching is needed). You can copy paste commands etc, that makes the cli a breeze and I think it's very nice for pure cli work. Flashing with the (in the manual) recommended "Flash Loader Demo" is so simple, btw I always tick the option "global erase".
@Hinkel: I implemented the osd sw box now. Your proposal for another box for the alternative controller seems reasonable, but I am currently not up to that.
@brm: Sadly to see you go here: http://code.google.com/p/afrodevices/so ... tail?r=458 hopefully you keep up with impulses on some other googlecode/github repo. Don't let that TC bring you down. BTW: I also played around with normalization of the mag vector, like done in the baseflightplus branch, but got worsened practical results, hmm.. maybe I should try that again.
Cheers
Rob

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

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

Crashpilot1000 wrote:@Hinkel: I implemented the osd sw box now. Your proposal for another box for the alternative controller seems reasonable, but I am currently not up to that.


Thanks a lot for implement the osd sw box. I will try to add the alternative controller box for fun by myself just to feel the direct difference in
FPV flight . :)

EDIT: OMG Just have a quick look on the last SG2.6 mw.c .......lots of change in compare to SG2.5 :shock:
also my poor crappy failsafe hack for kvteamosd is not inside :mrgreen:

Regards
hinkel

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

Hi. I've been using Baseflight for a while but thought I would give Harakiri a go to try RTH and PH. Position Hold has been working quite well in Baseflight but I like the idea of RTH for video link failures. Anyway I have successfully loaded the SG Pre2.6 to a Ver5 Naze32 but I'm having issues from there on. In Baseflight Config GUI ver 2.11 it connects but that is all. In Baseflight GUI ver2.3.5.0 it connects and shows PID values. I can calibrate everything. It shows gyro, acc, baro but not GPS. In CLI I can set all variables but it doesn't seem to write to the board as it is cleared when I leave and return. I thought I was getting somewhere last night when I tried a test flight and it did 4 flips on take off until the props were broken lol. Maybe not that close after all. I'd like to make this work as it looks good on the videos. I the baseflight and Baseflight ver 2.11 CLI and PuTTy CLI It continually adds jibberish and I can make no changes and all GUI seem to crash after a short time. I thought I might be from the GPS so I disconnected it but it didn't make a difference.
This is the message I get when the GUI crashes....

BaseflightGUI
ProductVersion = 2.3.5.0
CurrentCulture
- DisplayName = English (United States)
- DateTimeFormat = yyyy'-'MM'-'dd HH':'mm':'ss'Z'
- NumberDecimalSeparator = .
- NumberGroupSeparator = ,

**** User Comment Start ****



**** Message ****
The operation has timed out.


**** Source ****
System


**** Helplink ****



**** Last Command ****
UnhandledException
****** StackTrace ******
at System.IO.Ports.SerialStream.ReadByte(Int32 timeout)
at System.IO.Ports.SerialPort.ReadOneChar(Int32 timeout)
at System.IO.Ports.SerialPort.ReadChar()
at BaseflightGUI.modCLI.startCLI()
at BaseflightGUI.frmMain.setTAB()
at BaseflightGUI.frmMain.tabMain_SelectedIndexChanged(Object sender, EventArgs e)
at System.Windows.Forms.TabControl.OnSelectedIndexChanged(EventArgs e)
at System.Windows.Forms.TabControl.WmSelChange()
at System.Windows.Forms.TabControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

And from the GUI ver 2.11 CLI I get this sort of message but it continues on and on and wont let me get a word in lol

þ È@ÏÁþ È@%¿þ È@È@ñBþ È@v2þ È@œLþ È@¢Ïþ È@H±þ È@Ä]þ !È@.#þ "È@&nbsp;þ #È@úÞþ $È@}®þ %È@—Ðþ &amp;È@©Sþ 'È@C-þ (È@§²þ )È@MÌþ *È@sOþ +È@™1þ ,È@Aþ -È@ô?þ .È@ʼþ /È@ Âþ 0È@‹þ 1È@ùõþ 2È@Çvþ 3È@-þ 4È@ªxþ 5È@@þ 6È@~…þ 7È@”ûþ 8È@pdþ 9È@šþ :È@¤™þ ;È@Nçþ &lt;È@ɗþ =È@#éþ &gt;È@jþ ?È@÷þ @È@»þ AÈ@þÅþ BÈ@ÀFþ CÈ@*8þ DÈ@­Hþ EÈ@G6þ FÈ@yµþ GÈ@“Ëþ HÈ@wTþ IÈ@*þ JÈ@£©þ KÈ@I×þ LÈ@Χþ MÈ@$Ùþ NÈ@Zþ OÈ@ð$þ PÈ@Ãmþ QÈ@)þ RÈ@þ SÈ@ýî

Any Ideas where to start??

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

It all seems to work in MultiWii Config ver 2.11 but I can change anything via the CLI. This might be why it smashed the props as I thought it had camtilt programmed when it wasn't but I had motors and servos connected as though it was.

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

The other problem is I can map the rx channels correctly

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Have not tested camtilt or altered rx channels, that is unchanged from older orig. BF so i expect that to work. Reading the readme.txt is not your business ????????????????????????????????????????????????????????????? I will not comment on stuff that is already in the readme. Using some gui instead of the mwii2.1 Gui is your problem as well......

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

Sorry. I've read so much I'm overloaded. I'll go back to the read me file again. If I can't see how to access the CLI I guess I'll go back to BF. Thanks for you help.

jingej
Posts: 29
Joined: Sat Oct 27, 2012 11:56 am

Re: Harakiri aka multiwii port to stm32

Post by jingej »

alistairr wrote:Hi. I've been using Baseflight for a while but thought I would give Harakiri a go to try RTH and PH. Position Hold has been working quite well in Baseflight but I like the idea of RTH for video link failures. Anyway I have successfully loaded the SG Pre2.6 to a Ver5 Naze32 but I'm having issues from there on. In Baseflight Config GUI ver 2.11 it connects but that is all. In Baseflight GUI ver2.3.5.0 it connects and shows PID values. I can calibrate everything. It shows gyro, acc, baro but not GPS. In CLI I can set all variables but it doesn't seem to write to the board as it is cleared when I leave and return. I thought I was getting somewhere last night when I tried a test flight and it did 4 flips on take off until the props were broken lol. Maybe not that close after all. I'd like to make this work as it looks good on the videos. I the baseflight and Baseflight ver 2.11 CLI and PuTTy CLI It continually adds jibberish and I can make no changes and all GUI seem to crash after a short time. I thought I might be from the GPS so I disconnected it but it didn't make a difference.
This is the message I get when the GUI crashes....

BaseflightGUI
ProductVersion = 2.3.5.0
CurrentCulture
- DisplayName = English (United States)
- DateTimeFormat = yyyy'-'MM'-'dd HH':'mm':'ss'Z'
- NumberDecimalSeparator = .
- NumberGroupSeparator = ,

**** User Comment Start ****



**** Message ****
The operation has timed out.


**** Source ****
System


**** Helplink ****



**** Last Command ****
UnhandledException
****** StackTrace ******
at System.IO.Ports.SerialStream.ReadByte(Int32 timeout)
at System.IO.Ports.SerialPort.ReadOneChar(Int32 timeout)
at System.IO.Ports.SerialPort.ReadChar()
at BaseflightGUI.modCLI.startCLI()
at BaseflightGUI.frmMain.setTAB()
at BaseflightGUI.frmMain.tabMain_SelectedIndexChanged(Object sender, EventArgs e)
at System.Windows.Forms.TabControl.OnSelectedIndexChanged(EventArgs e)
at System.Windows.Forms.TabControl.WmSelChange()
at System.Windows.Forms.TabControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

And from the GUI ver 2.11 CLI I get this sort of message but it continues on and on and wont let me get a word in lol

þ È@ÏÁþ È@%¿þ È@È@ñBþ È@v2þ È@œLþ È@¢Ïþ È@H±þ È@Ä]þ !È@.#þ "È@&nbsp;þ #È@úÞþ $È@}®þ %È@—Ðþ &amp;È@©Sþ 'È@C-þ (È@§²þ )È@MÌþ *È@sOþ +È@™1þ ,È@Aþ -È@ô?þ .È@ʼþ /È@ Âþ 0È@‹þ 1È@ùõþ 2È@Çvþ 3È@-þ 4È@ªxþ 5È@@þ 6È@~…þ 7È@”ûþ 8È@pdþ 9È@šþ :È@¤™þ ;È@Nçþ &lt;È@ɗþ =È@#éþ &gt;È@jþ ?È@÷þ @È@»þ AÈ@þÅþ BÈ@ÀFþ CÈ@*8þ DÈ@­Hþ EÈ@G6þ FÈ@yµþ GÈ@“Ëþ HÈ@wTþ IÈ@*þ JÈ@£©þ KÈ@I×þ LÈ@Χþ MÈ@$Ùþ NÈ@Zþ OÈ@ð$þ PÈ@Ãmþ QÈ@)þ RÈ@þ SÈ@ýî

Any Ideas where to start??

detach your OSD

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

Thanks for the suggestion. I don't have an OSD attached but I did try plugging the GPS back into the 5v and earth and it stopped so now I can use the Cli. Shit Hot!
A question about the GUI. As you read earlier I have about 5 different versions on my laptop. I only use Naze32 boards with Baseflight and now Harakiri. I need to change that to just 2 to simplify things.
I'm on a steep learning curve but I'm enjoying it. My past experience has been with Eagletree fixed wing FPV which is plug and play. Thanks for your work

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

WooHoo!! I'm flying. Only a quick flight on the front lawn in the dark at midnight.

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

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

Hi !
Just a stupid noob question in Harakiri in config.c the parameter cfg.D8[YAW] is not define for eeprom write, but in mw.c the parameter cfg.D8[axis] is
use for the PID Controller, axis is going from 1 to 3 so is there not a possible bug if the cfg.D8[3] is reading value from cfg.D8[PIDALT] in eeprom ?
cfg.D8[YAW] = 0; // not exist in config.c ???
Excuse me if i don't understanding this ?

Regards
hinkel

Truglodite
Posts: 48
Joined: Sat Jun 22, 2013 2:37 am

Re: Harakiri aka multiwii port to stm32

Post by Truglodite »

Crashpilot1000 wrote:@Truglodite: I haven't tried "Racer 5", let's see where to find that canadian beer here... Really don't know why the stick commands don't work with your setup, maybe it's something with your overclocking. I don't have that barebone knowledge, I have to trust in the supplied libraries/drivers (mostly).

...//

Cheers
Rob


It's a local brew, but it is very popular:

http://bearrepublic.com/

Maybe your local pub or beer store can order some? It is well worth the trouble if you like IPA... or if you just want less bottles to accomplish the same task. ;)

You're probably right it has to do with overclocking, and I too lack knowledge in that area... and many other areas too. :D Oh well, 80mhz did help a little bit, but if Harakiri progresses too far I may have to drop it in favor of other features or performance improvements. Hopefully by then TC or someone with adequate knowledge will figure out how to get with the latest code base running 80mhz on pre-v5 boards. I wonder if the v5 boards work at 84mhz, or have the same problems?

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

Re: Harakiri aka multiwii port to stm32

Post by timecop »

overclocking works fine in baseflight, the version you forked drivers from is probably way too old, look at commit history and see what changed (I left a comment something about 80mhz) to fix it.

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

hinkel wrote:Hi !
Just a stupid noob question in Harakiri in config.c the parameter cfg.D8[YAW] is not define for eeprom write, but in mw.c the parameter cfg.D8[axis] is
use for the PID Controller, axis is going from 1 to 3 so is there not a possible bug if the cfg.D8[3] is reading value from cfg.D8[PIDALT] in eeprom ?
cfg.D8[YAW] = 0; // not exist in config.c ???
Excuse me if i don't understanding this ?

Regards
hinkel


Hi, Hinkel!
Thanks for staying sharp and rechecking! Well, actually the whole config specified in the struct config_t (mw.h https://github.com/Crashpilot1000/SGTod ... /mw.h#L202) is saved in eeprom and there is a complete PID for every piditem. The section you refer to (static void resetConf(void)) does not explicitly set a value for cfg.D8[YAW] but it is assigned with a zero along with the "writeParams" call and its' erasing the eeprom before writing (https://github.com/Crashpilot1000/SGTod ... nfig.c#L74). So if no value for cfg.D8[YAW] specified in "resetConf", it will be set to zero. I list all of my new/altered variables there even if they are by default zero, but that is not necessary.
EDIT: Have you checked the Autostart function, it's such a nice plaything, I can autostart and autoland all day.. lol...
@Turgolite: Well, if your rc channels are reported back correctly in the gui, the triggering of stick commands should work as well. Please recheck if you haven't sitll some trim on you yaw on your tx left, that spoiled it once for me.

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

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

Crashpilot1000 wrote:EDIT: Have you checked the Autostart function, it's such a nice plaything, I can autostart and autoland all day.. lol...
.


Thanks to clear my noob questions ! :)
I have not try yet the SG2.6 , because I had issues to download the code from Github http://github.com/Crashpilot1000/SGTodaysSnapshot/blob/master/baseflight_NAZE.hex
and I was not sure If it was just a testcode for Naze32 rev5 ! But ASAP I will try this SG2.6 and report when weather will be better !

Regards
hinkel

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

Hi again.....
I think I have read somewhere about someone having issues setting RC Control Settings in MultiWii 2.1. When I choose RTH or PH and then check on Real Time Data page when I switch to either RTH or PH it highlights Camstab and Level. I have tried all the other options individually and none of them highlight RTH or PH.
Thanks Alistair

alistairr
Posts: 51
Joined: Thu Sep 26, 2013 10:30 am

Re: Harakiri aka multiwii port to stm32

Post by alistairr »

Did I miss something with auxset. Could you give an example of a CLI command for channel set

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

Re: Harakiri aka multiwii port to stm32

Post by Crashpilot1000 »

Like always in mwii the boxes turn green when the function could be activated. Probably not enough sats in your room??
Cli command auxset is described (with example) in the cli. That original was non human readable and just an awful waste - probably still present in BF.

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

Re: Harakiri aka multiwii port to stm32

Post by hinkel »

short fly test with SG2.6 version 17 oktober :
* the bug from arming motor in baro mode is now fixed , :)
* the autostart is working fine :) test with 2m
* the (( cfg.nav_rtl_lastturn = 1; // 1 = when copter gets to home position it rotates it's head to takeoff direction independend of nav_controls_heading )) is not working , I was just 1 or 2 meter in hight for the test, no head rotate !

Regards
hinkel

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

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

alistairr wrote:Hi again.....
I think I have read somewhere about someone having issues setting RC Control Settings in MultiWii 2.1. When I choose RTH or PH and then check on Real Time Data page when I switch to either RTH or PH it highlights Camstab and Level. I have tried all the other options individually and none of them highlight RTH or PH.
Thanks Alistair



Make sure you are using a MW2.2 gui, and not a GUI for MW2.1

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

Re: Harakiri aka multiwii port to stm32

Post by subaru4wd »

alistairr wrote:Hi again.....
I think I have read somewhere about someone having issues setting RC Control Settings in MultiWii 2.1. When I choose RTH or PH and then check on Real Time Data page when I switch to either RTH or PH it highlights Camstab and Level. I have tried all the other options individually and none of them highlight RTH or PH.
Thanks Alistair



Make sure you are using a MW2.2 gui, and not a GUI for MW2.1

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Harakiri aka multiwii port to stm32

Post by scrat »

alistairr wrote:WooHoo!! I'm flying. Only a quick flight on the front lawn in the dark at midnight.


What did you do?

User avatar
IceWind
Posts: 115
Joined: Fri Mar 25, 2011 2:11 am
Contact:

Re: Harakiri aka multiwii port to stm32

Post by IceWind »

For the autoland/autostart does it requires sonar?

Now I want to test that as well... ;)

Post Reply