Unified communication (for telemetry, GUI, logging, etc)

[Sebbi]

Hi there,

current MultiWii software has only two ways to communicate with the outside world:
1) the GUI protocol over a serial port
2) LCD/Terminal over serial port

Now that the codebase is organized in cpp/h files, I'd like to start development on the communication layer. I want to get it to a point where a user can use defines in config.h to enable one or more of the following things (over any hardware or software serial port):
1) use Mavlink protocol instead of GUI protocol
2) log flight data to openlog based devices (they log serial data to an SD card)
3) send FrSky telemetry
4) send HoTT telemetry
5) be extensible to other telemetry options

Any interest? How likely is it that something like this would be included in _shared? I ask, because 2-4 have been done for ages, but people still need to patch MultiWii to make it work ...

[Sebbi]

Mavlink discussion: viewtopic.php?f=7&t=469 (and there is already a GUI 2 Mavlink translator: https://code.google.com/p/mwi-gc/)

Openlog: https://github.com/sebastianherp/multiw ... ee/logging (from 11 months ago) and a thread about data logging from last year viewtopic.php?f=7&t=1070&p=19199&hilit=openlog#p19199

FrSky: viewtopic.php?f=7&t=1929

HoTT: viewtopic.php?f=7&t=1284

[copterrichie]

FYI, it was suggested to add a heartbeat pulse with various telemetry data that can be activated via a MSP code but that idea was rejected. So what I have done is, wrote my own code and just add it to the serial.ino file.

[copterrichie]

P.S. I think this is where the power of the Arduino IDE comes into focus, it allows for a person with minimum programming skills to make modifications to the firmware without creating a major production of it.

[Crashpilot1000]

@Sebbi: That is a very good idea! Currently i am biting my teeth on the mavlink stuff. "Meister" has done a nice solution for Baseflight https://github.com/slashphotos/harakiri ... er-mavlink.

[timecop]

@Sebbi: That is a very good idea! Currently i am biting my teeth on the mavlink stuff. "Meister" has done a nice solution for Baseflight https://github.com/slashphotos/harakiri ... er-mavlink.

https://github.com/slashphotos/harakiri ... nk_param.c

Holy shit.

[Sebbi]

@Sebbi: That is a very good idea! Currently i am biting my teeth on the mavlink stuff. "Meister" has done a nice solution for Baseflight https://github.com/slashphotos/harakiri ... er-mavlink.

https://github.com/slashphotos/harakiri ... nk_param.c

Holy shit.

Indeed ... too bad there is no switch for char-arrays :/

[Crashpilot1000]

@TC: Yes that is actually the part i programmed away, so the CLI valueTable is taken directly for printing out and comparison of incoming data. The last part has still a bug i didn't find already. The mavlink without that "compare everything by hand part" is about 9KB shorter as well.

EDIT:

Here is actually the code that converts/prints out all BF CLI values to mavlink / Missionplaner. That code is probably rediculous for a real programmer, but works. It is not timecritical for the FC because it is only executed when disarmed, loading and setting all parameters is not reasonable in my opinion during flight.

Code: Select all

bool baseflight_mavlink_send_param(void)
{
    static  uint16_t i = 0;
    uint8_t StrLength;
    float   value = 0;
    char    buf[16];                                      // Always send 16 chars
    mavlink_message_t msg;

    StrLength = strlen(valueTable[i].name);
    if (StrLength >= 16)
    {
        memcpy (buf, valueTable[i].name, 16);             // Just take 16 Chars
    }
    else
    {
        memset (buf,' ',16);                              // Fill with <SPACE> before proceeding
        memcpy (buf, valueTable[i].name, StrLength);
    }
    switch(valueTable[i].type)
    {
    case VAR_UINT8:
        value = *(uint8_t *)valueTable[i].ptr;
        break;
    case VAR_INT8:
        value = *(int8_t *)valueTable[i].ptr;
        break;
    case VAR_UINT16:
        value = *(uint16_t *)valueTable[i].ptr;
        break;
    case VAR_INT16:
        value = *(int16_t *)valueTable[i].ptr;
        break;
    case VAR_UINT32:
        value = *(uint32_t *)valueTable[i].ptr;
        break;
    case VAR_FLOAT:
        value = *(float *)valueTable[i].ptr;
        break;
    }
    mavlink_msg_param_value_pack(1, 200, &msg, buf, value, i + 1, VALUE_COUNT, i);
      baseflight_mavlink_send_message(&msg);
    i++;
    if (i == VALUE_COUNT)
    {
        i = 0;
        return true;
    }
    else return false;
}

Call this like that:

Code: Select all

...

            static bool mavlink_send_paralist = false;
...
...
// .... other stuff ...   

            if (mavlink_send_paralist)
            {
                mavlink_send_paralist = !baseflight_mavlink_send_param();       // baseflight_mavlink_send_param_lst is true when done
// .... other stuff ...               
            }

Sending the data too fast will kill the Missionplaner 20Hz seems the limit for it. GCS tilts out at 20Hz with those parameters, probably 10Hz is ok - i will have to test and learn more about mavlink. I will have to check for some "ACK" or something for the right datarate. But mavlink has different incarantions and packages depending on the "type".

EDIT: The next thing i tried was a protocol autosensing. Well it works, but only the fallback to mwii. Mwii is sending enough data while requesting stuff, it will also work with GCS and send heartbeatpackages enabled but missionplaner does some other stuff. Perhaps keeping mavlink as primary protocol is a solution and switch to multiwii after some faulty bytes. But that is also not practical with BF when entering cli console or flashmodus because a "#" or 'R" will trigger that. Perhaps going with "#####" and "RRRRR" for cli or flash would solve that.

EDITEDIT: Autosensing works now! It could be a little bit more fluent but works. Now you can connect to MwiiGUI or GCS or Missionplaner or fire up the cli in BF.
Still a lot of work, but a small step.
Here is how it is done:
There is a bytevar that stores the current protocoll (0=unknown 1=mwii 2=mavlink) and a timestamp of last valid decoded package of current active protocol.

When disarmed and the last valid received dataset is older than 2 seconds it sets protocol to unknown. In that case it will also emit a mavlink heartbeat at 1Hz to signalize a potential program that there is something alive. In that state "not armed and no active protocol" extra strings are parsed like "5x#" for cli or "5xR" for flashmode. In your terminal you will see the 1Hz heartbeatgarbage until you entered 5x#. So far for the cli - back to the protocols.
If protocoll unknown and unarmed mwii and mavlink are decoded simultaneously the first correctly decoded package is the winner and sets the type and timestamp. That is still not perfect because Missionplaner just seems to sit and listen while data are incoming so the parametertransmission is interrupted every 2 secs and then proceed. So switching has to be disabled in that case.
During flight a preselected protocol is used (currently mwii, because mavlink is pre alpha...). I will release the code when it is somehow working and useable, even if nobody wants it and someone will bitch loudly about the codingstyle and having no github.....

EDIT EDIT EDIT: Mavlink mainly DONE, you can see it in next Harakiri .
Cheers
Kraut Rob

[Sebbi]

I had a few spare hours to get used to the current code again and so the first thing I did was split Serial.cpp/.h and separate the GUI code into another file Comm_GUI.cpp/.h. This even resulted in some savings in the binary size (292 bytes in quadx/freeimu43 configuration wohooooo!). It's just a start!

Question: would you rather have one communication type per file (Comm_GUI.cpp, Comm_LCD.cpp, Comm_FrSky.cpp, Comm_Logger.cpp, etc) or everything in ONE big file?

Code:
https://github.com/sebastianherp/multiw ... munication

[NikTheGreek]

I'm not a developer but i think that splitting the code in smaller parts is better for us(non programmers).
Thank you

[Hamburger]

I'm not a developer but i think that splitting the code in smaller parts is better for us(non programmers).

Really? Care to explain the advantage of having a larger number of files for a non-programmer?

[NikTheGreek]

IMHO i think that is more readable for us , that we dont have advanced programming skills , to have split the code in smaller parts.
For example when i want to "study" the gui related part of code i will not lost in lines of code not related to it.

I ll repeat once again...i'm not a programmer , but a guy that trying to understand how this code works.

[Sebbi]

I'm not a developer but i think that splitting the code in smaller parts is better for us(non programmers).

Really? Care to explain the advantage of having a larger number of files for a non-programmer?

The number of files and codebase is already too large to "work" with them in the Arduino IDE. I think at this point it really doesn't matter how many more files there are besides the config.h when all that usually needs editing is this one file.

The Arduino-style way would have been to put everything hardware related in libraries and have clean, understandable and well structured code in just a few (ideally just one) .ino files ... that's what draws non-programmers to this plattform or am I wrong?

[NikTheGreek]

I understand that in order this "project" to go forward it doesn't matter what the non-programmers believe about the structure.
The experts know better than us.
After all they have made a wonderful platform so far ..and thank you for that.
I cant suggest the way that this project will go on..i can only make a wish.
It would me nice..i can speak only for myself .. if the code was more understandable for us.

Thank you.

[Crashpilot1000]

Hi, Sebbi. I did a basic mavlink support for BF. Maybe you are interested, since it's not too far away from mwii. MinimOSD can cope with that data.
viewtopic.php?f=23&t=3524&p=38753#p38753
It is based on Meisters implementation and idea! Hopefully TC will not have to say "holy sh**" in that context because that part is completely gone now.
BTW I see you are looking for Frsky stuff (viewtopic.php?f=7&t=1929&start=140#p38754). TC already implemented it in BF under telemetry.c https://github.com/multiwii/baseflight/ ... elemetry.c .

Greetings
Rob

[Alexinparis]

Hi there,

current MultiWii software has only two ways to communicate with the outside world:
1) the GUI protocol over a serial port
2) LCD/Terminal over serial port

You forgot RC, GPS, OSDs and I2C devices

Now that the codebase is organized in cpp/h files, I'd like to start development on the communication layer. I want to get it to a point where a user can use defines in config.h to enable one or more of the following things (over any hardware or software serial port):
1) use Mavlink protocol instead of GUI protocol
2) log flight data to openlog based devices (they log serial data to an SD card)
3) send FrSky telemetry
4) send HoTT telemetry
5) be extensible to other telemetry options

Any interest? How likely is it that something like this would be included in _shared? I ask, because 2-4 have been done for ages, but people still need to patch MultiWii to make it work ...

To be clear, I will probably never use any of those options as I'm more focus on developing MSP interaction.
MSP is now used by OSDs and serial RC TX that's why I would not use the term GUI protocol to describe it.

At the beginning of MSP I thought about Mavlink. It was not considered because not really compatible with 328p proc requirement (memory concern) and because of bit wire efficiency <- this is the most important point for telemetry apps.
About FrSky and HoTT, it would have been better if the protocols were officially published (open) and not reversed via hobbyist analysis.
But I understand the need for those that have already some hardware.

So if you want to take the lead on this and provide a reasonable abstraction layer, fell free.
Be sure it will be included if it doesn't induce a growing code size when functions deactivated.

About files: you know I'm not a fan a multiple files. C++/h organization is not an argument and a high level IDE should be able to cope also with this.
de correlate Serial file (buffer management & PORT stuff) from one single Protocol file (including MSP, Mavlink, FrSky, ...) seems however ok

[Sebbi]

Hi Alex,

I didn't forget them, but since they are more or less inputs it's no way of communicating to the outside world

MavLink implementation would just be an exercise and be of course be optional to use (and probably only be usable on Megas) ... and I agree, it's not really efficient, but apparently some folks are using it.

I don't know about HoTT (i think it was reverse engineered), but FrSky have documented their protocol: http://frsky-rc.com/uploadfile/201211/2 ... 905895.pdf and the hardware is cheap and works over large distances

I know you despise a growing number of files, but those protocols are all pretty extensive and mixing them in one cpp file would be a nightmare to develop, I think. My "Comm_GUI.cpp" has 583 lines of code and "Comm_FrSky.cpp" 329 lines already. Serial.ccp shrinked to 474 lines however

[Hamburger]

you going to take care of the serial lcd telemetry stuff as well?

[Sebbi]

Of course ... the LCD code is already pretty separate from Serial.cpp (same as RC code that uses the serial port)

[Nickman1200]

Any news on this Sebbi ?

[Sebbi]

Any news on this Sebbi ?

Not much has happened, because of brain melting temperatures ... but August seems like a good month to get a simple implementation going.

[Alexinparis]

Hi,

I did some split in the code yesterday to ease the task.