MultiWii

brm wrote:

Code: Select all

void setupTaskEntries()
{
   clearTaskEntries();

   setTaskEntry(eFrame_1Hz, 1, frame_Hartbeat);
   setTaskEntry(eFrame_10Hz, 10, frame_10Hz);
   setTaskEntry(eFrame_50Hz, 50, updateCommands);
   setTaskEntry(eFrame_Sensor_Fusion, 500, updateActuators);
   setTaskEntry(eFrame_Read_IMU, 1000, readImu);
}

a tasklet would look like:

Code: Select all

void updateActuators(float time)
{
    updateAttitude(time);
    stabilisation(time);
    mixTable();
    writeServos();
    writeMotors();
}

seperation of concerns ...
TC would say f*** it!

    setTaskEntry(EVENT_10Hz, EVERY_EVENT, updateHoTTTelemetry);

    ...

    void updateHoTTTelemetry() {
        static triggerCount = 0;

        respondToHOTTRequest();

        switch(triggerCount++ % 3) {
            case 1:
                updateHoTTGPSMessage();
            break;
            case 2:
                updateHoTTGPSMessage();
            break;  
        }
       
        ...
    }

   setTaskEntry(EVENT_10Hz, EVERY_EVENT, respondToHOTTRequest);
   setTaskEntry(EVENT_10Hz, EVERY_SECOND_EVENT, updateHoTTGPSMessage);
   setTaskEntry(EVENT_10Hz, EVERY_THIRD_EVENT, updateHoTTEAMMessage);

Crashpilot1000 wrote:Well, BRM you know I respect you as a someone with very good input (like Hinkel) and scientific background. I've seen TC turning down your calibration improvements (too fast for me to look at them further, or copy them onto my hddsk) but on the other hand your github repo (bubi-007) lacks all the achievments you have done - and is full of forked repos- why is it? I (and I think many others that don't like to admit it like TC and his pitbulls like fiendie - yes, fiendie you know that you are nothing more than that. - Don't believe that? Just look at your own posts and doings and you will know you *tink ) would like to see yor changes/improvements. I think you have the power and the knowledge to start something better. Maybe with D.C.
Ps.: Sorry, too much beer already.
Cheers
Rob

Pierre_A wrote:@doppler
don't know the yaw improvements you're thinking of but for me , with Cleanflight version june 3, Naze32 on Y4 config, default yaw PID , yaw rate=0 , align_board_yaw=-90 and no expo on the Tx, the yaw behaviour is quite precise, fast and smooth.

dominicclifton wrote:i'll add that to my list of things to look into. feel free to have a go at merging the code yourself and submit a pull request. Do you have any links to the specific code changes you're referring to in Multiwii? links/file/method/line numbers?

That would be most helpful.

Crashpilot1000 wrote:Well, BRM you know I respect you as a someone with very good input (like Hinkel) and scientific background. I've seen TC turning down your calibration improvements (too fast for me to look at them further, or copy them onto my hddsk) but on the other hand your github repo (bubi-007) lacks all the achievments you have done - and is full of forked repos- why is it? I (and I think many others that don't like to admit it like TC and his pitbulls like fiendie - yes, fiendie you know that you are nothing more than that. - Don't believe that? Just look at your own posts and doings and you will know you *tink ) would like to see yor changes/improvements. I think you have the power and the knowledge to start something better. Maybe with D.C.
Ps.: Sorry, too much beer already.
Cheers
Rob

dominicclifton wrote:I'm happy to announce support for Addressable RGB LED strips!
[...]
WS2811 LEDs are CRAZY bright.

Hydroculture wrote:Dear Dominic!

Thank you so much for this nice Firmware branch.
Installed it on my little h-quad
Installation went flawless, connection to your cleanflight configurator the same.
Quad flies great!

Hydroculture wrote:Whats im still unsure about is the format of your mag-declination input in the cleanflight fw.
How do I have to enter it?

failsafe wrote:We have seen issues with these boards , take a quick gander over at the openpilot forums and you will see many new threads the past couple of weeks due to the influx of these inexpensive boards.

To enable SerialRX use CLI and type:
"feature SERIALRX"
and then choose the type of receiver by typing one of the following lines
"set serialrx_type=0" for Spektrum 10bit (1024)
"set serialrx_type=1" for Spektrum 11bit (2048)
"set serialrx_type=2" for Futaba SBUS mode
"set serialrx_type=3" for for Graupner SUMD

feature RX_SERIAL

serialrx_provider = 1
serial_port_1_scenario = 1
serial_port_2_scenario = 2
serial_port_3_scenario = 0
serial_port_4_scenario = 0

Entering CLI Mode, type 'exit' to return, or 'help'

# feature RX_SERIAL
Enabled RX_SERIAL

# feature
Enabled features: VBAT RX_SERIAL RX_PARALLEL_PWM 

# feature -RX_PARALLEL_PWM
Disabled RX_PARALLEL_PWM

# feature
Enabled features: VBAT RX_SERIAL 

# save
Saving...
Rebooting...ÿ

Entering CLI Mode, type 'exit' to return, or 'help'

# feature
Enabled features: VBAT 

#

NOTE: These settings always describe LATEST firmware source release, and do not necessarily reflect features of pre-built firmware images.

serialrx_type

When feature SERIALRX is enabled, this allows connection to several receivers which output data via digital interface resembling serial. These include Spektrum Satellite, Futaba SBUS, and Graupner SUMD. Currently supported values for this setting are:
0 - Spektrum 10bit (1024)
1 - Spektrum 11bit (2048)
2 - Futaba SBUS
3 - Graupner SUMD
Note, that SBUS will require a signal inverter in order to connect.

...a fork of baseflight that attempts to improve the quality of the codebase by introducing tests, improving naming, code decoupling and other software development best practices...

// this exists so the user can reference scenarios by a number in the CLI instead of an unuser-friendly bitmask.
const serialPortFunctionScenario_e serialPortScenarios[SERIAL_PORT_SCENARIO_COUNT] = {
    SCENARIO_UNUSED,

    // common scenarios in order of importance
    SCENARIO_MSP_CLI_TELEMETRY_GPS_PASTHROUGH,
    SCENARIO_GPS_ONLY,
    SCENARIO_SERIAL_RX_ONLY,
    SCENARIO_TELEMETRY_ONLY,

    // other scenarios
    SCENARIO_MSP_CLI_GPS_PASTHROUGH,
    SCENARIO_CLI_ONLY,
    SCENARIO_GPS_PASSTHROUGH_ONLY,
    SCENARIO_MSP_ONLY
};

set serial_port_2_scenario = 3

dominicclifton wrote:My experience with the Flip32+ has been very positive so far - for my use the only thing missing is a built in inverter for the FrSky telemetry output. Really like having the +5V and GND next to the IO ports and RC inputs. My wiring for the Flip32+ was much tidier than on the Naze32 which has head pins all over the place.

wade.weppler wrote:It had highspeed oscillations, and kept trying to lean to one side drastically. I had to fight to get it back down in one piece, all the while it would move unpredictably. Landed on one arm, which I managed to break, but that was the only damage. Could have been much much worse!

So, I'm a bit paranoid and have gone back to baseflight. I know AutoTune is experimental, and the hex was flying nicely without it, so I probably shouldn't have fixed what wasn't broken in the first place.

Just thought I'd post my results.

dominicclifton wrote:Thanks for sharing that. If you had flipped the autotune switch again it would have in-flight reverted the changes back to the old pid settings. I specifically designed the feature that way so you could get out of such trouble

Did you by any chance record the pid settings that it produced?

... if the developer viewing or updating the code is named "dominic clifton", the modified "hydraIRC limited-use source license" (http://www.hydrairc.com/content/developers) applies, as below:

tungsten2k wrote:Is OSDSW (enable/disable OSD overlay) working for anyone else using CPPM receiver input on a minimosd (Witespy) board ?

-=dave

nebbian wrote:Is Cleanflight in contravention of this license? Is there a thread that explains what that license issue is all about? Or is BaseFlight in contravention of the GPL V3 license by trying to restrict the license terms despite being based on a GPL project itself (Multiwii).

Pierre_A wrote:- OSDsw defined as Aux2 in Cleanflight config.
I confirm that the OSDSW does not work (OSD overlay remains visible).
Can’t tell if this works with Baseflight but seems to work fine with Harakiri 2.5 : see post by hinkel at
[url]http://www.multiwii.com/forum/viewtopic.php?f=8&t=2918&sid=8f8faa7090697f0946a8a4a9a6f633b9&start=700
[/url]
PA

Gaijin wrote:Dominic,

Very interested in your WS2812 RGS Led support, a question and a request if you don't mind

Question - what is the default state of these leds, If I apply 5v to the pins and no control signal will they light at all, I'd like to default them as my forward / aft orientation lights with turn signals battery warning etc as secondary functions

Request - Would you be willing to add the configuration to CLI or GUI rather than direct into the code, I'm not anywhere near as smart as you in that respect

dominicclifton wrote:

nebbian wrote:Is Cleanflight in contravention of this license? Is there a thread that explains what that license issue is all about? Or is BaseFlight in contravention of the GPL V3 license by trying to restrict the license terms despite being based on a GPL project itself (Multiwii).

Baseflight is in contravention of the GPL v3. Timecop is attempting to troll me with it but I know better.

dominicclifton wrote:

Pierre_A wrote:Thanks for the feedback Pierre, can you raise an issue on the Cleanflight issue list? I'll look into it. It's probably broken in baseflight too since it's an area of code that I haven't touched.

nebbian wrote:I think I'm going to do all my development using CleanFlight as a starting point, rather than baseflight. I think my values as a developer align more closely with yours than with the developer of baseflight

dominicclifton wrote:I'm about to fly Cleanflight on my CC3D board - with WS2812 led's and updated PPM code:
https://www.youtube.com/watch?v=EViw4lBRa94

nebbian wrote:I think I'm going to do all my development using CleanFlight as a starting point, rather than baseflight. I think my values as a developer align more closely with yours than with the developer of baseflight