Updating and maintainng the Wiki

[careyer]

This thread is to collaborate and make decisions on parts of the wiki.

Please feel free to jump in for a topic here:
Topic Assignment:

Please track changes (and Quality Controls) in the EDIT field:

[careyer]

Added: https://github.com/bortek/EZ-WifiBroadcast/wiki/RC-:-RC-via-MAVlink May I ask some native speaker to do a Quality Ceck. Thanks

[RespawnDespair]

@careyer not a native speaker, quickly read it and fixed some minor spelling mistakes. Looks great! Well structured and clear!

[careyer]

@RespawnDespair : Merci! =)

Added: https://github.com/bortek/EZ-WifiBroadcast/wiki/RC-:-regular-RC-protocols Maybe also give that a try!

May I kindly ask to also add the "Quality control" to the changelog (see 1st post) - just for good practice Thanks!

[RespawnDespair]

@careyer Done, again very clear information.

[bortek]

Fixed a typo otherwise looks good, maybe history part is irrelevant but never mind.

[careyer]

Put together a neat wiring diagramm for the RC- and bi-directional telemetry Wiki section:

[careyer]

Here we go "FC Parameters"-Section finished: https://github.com/bortek/EZ-WifiBroadcast/wiki/RC-%3A-FC-Parameters/_edit

Would somebody please proofread? THX

[bortek]

corrected, good usage of abbreviation :O e.g. Flight Controller (FC)

[careyer]

Thank you very much... this has also been overhauled: https://github.com/bortek/EZ-WifiBroadcast/wiki/Expert-:-OSD-MAVLink-message-types

[htcohio]

I brought up a question on rcgroups about the SR1 parameter refreshing rate being set to "0" as per your instructions.

Correct me if I'm wrong but isn't that the mechanism by which parameters are sent to the ground station side for GCS mp or app?

Without it the parameters can't download and you cannot use the full function of the app.

Ot Am I wrong?

[careyer]

@htcohio : Let me quote the new Wiki page on this topic

In order not to transmit telemetry data too often over our radio link, we have to select just the necessary data (the right subsets of information) and at the same time find a good compromise on how often this data should be send and thus be updated. The following parameters have to be found working very reliably:

These settings are just for the proactive streaming (push) of the FC. The information subsets seleteced (SRx_Parameter/Buckets) just contain enough information to happily populate all the OSD elements. Also refer to here: OSD MAVlink message types. This can also be understood as a kind of news subscription that the OSD has to constantly get the right information without asking for it --> i.e. all SRx_Buckets that contain no relevant data for the OSD can be set to 0 and thus safe bandwidth.

These settings have nothing to do with the GCS requesting (pulling) parameters and settings from the FC. The FC will answer to any request the GCS sends. I hope this clears the fog a little.

[bortek]

Thank you very much... this has also been overhauled: https://github.com/bortek/EZ-WifiBroadcast/wiki/Expert-:-OSD-MAVLink-message-types

Done

[bortek]

@careyer you can write the comment in "Edit message" field when updating Wiki page instead of adding changelog text to the Excel file. I think it's easier so.

[careyer]

@bortek : Sure! Way easier. just wasn't sure if the edit message would be visible for regular users/vistors. Obviously it is not! One more thing learned :+1: (Will delete the changelog in 1st post then)

[pilotnbr1]

Added: https://github.com/bortek/EZ-WifiBroadcast/wiki/RC-:-RC-via-MAVlink May I ask some native speaker to do a Quality Ceck. Thanks

Read through it- looks good! I can help smooth a few grammar/spelling issues out this weekend. Your English is amazing, there is no way I could write anything like that in Deutsche!

[htcohio]

@Careyer,

When you have a chance, could you please check your SRx_Paramater to confirm my same results? I think you'll see that it automatically changed to 10 by itself.

SRx_PARAMATERS TEST

*This is been brought up several times and I myself was getting confused by the conflicting results. Assuming all of these results are verified, the ardupilot people should probably be notified as well to avoid confusion.

As for the parameter setting being "0" or "10", I believe that the link to the official ardupilot page is intended for people who are using a Serial port to stream live Telemetry data for a purpose other than bi-directional communication or other use that does not actually request the parameter list.

I made a 12-minute extremely boring video where I tested the following:

1. I set srx_pramater to "0" and rebooted..

Result>> Parameters loaded on the ground side just fine but, when I went back to check those changed values, to my surprise, it had automatically reverted back to a value of "10". I tried this twice with the same result.

2. I set srx_pramater to "1" and rebooted to see if it made any difference.

Result>> Yes, the initial parameter download process took roughly 10 times as long as it did when it was set to 10.

3. Finally I set SRx_param to "5" and by this point as expected, it took about twice as long when compared to a setting of "10".

So, in conclusion, "assuming that these results would be the same between all recent versions of Ardupilot" a setting of "0" Hz automatically and permanently changes back to 10 once it is called upon.

This particular setting does not send continuous data to any device, it is only sent during initialization of your GCS program on the ground i.e. (Tower, qgroundcontrol, Mission planner.....)

I hope this helps get us one step closer to Borg perfection 😀

Video test https://youtu.be/P38TBPq0QK4

On Oct 18, 2018 4:26 PM, "careyer" notifications@github.com wrote:

@htcohio https://github.com/htcohio : Let me quote the new Wiki page on this topic

In order not to transmit telemetry data too often over our radio link, we have to select just the necessary data (the right subsets of information) and at the same time find a good compromise on how often this data should be send and thus be updated. The following parameters have to be found working very reliably:

These settings are just for the proactive streaming (push) of the FC. The information subsets seleteced just contain enough information to happily populate all the OSD elements. Also refer to here: OSD MAVlink message types https://github.com/bortek/EZ-WifiBroadcast/wiki/Expert-:-OSD-MAVLink-message-types

These settings have nothing to do with the GCS asking (pulling) parameters and settings from the FC. The FC will answer to any request the GCS sends. Does this become clearer now?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/bortek/EZ-WifiBroadcast/issues/165#issuecomment-431148233, or mute the thread https://github.com/notifications/unsubscribe-auth/AcSp0jkK-0Q9Zx1NLmiPAPg0Yy4b-MJ9ks5umOPdgaJpZM4Xs6eY .

[careyer]

@htcohio : Thank you for the video... it wasn't boring at all! :+1: Because of your first hint on this (not long ago in RCgroups) I have tested this of course thourougly ;-) It works flawlessly and as intendent. There is no bug with Ardupilot/Mission Planner software writing the SRx_Parameters. (so to say: whatever value I set it stays the way it is supposed to be)

You must please(!!!) stick to my tutortial word by word:

• Use Mission Planner (not QGroundControl, APM Planner or something else)...
• Use direct USB Connection PC<->Pixhawk (not WiFi or Ethernet through WBC or something else).

In your video you are connecting via EZ-WiFiBroadcast and such through MAVlilnk v1. Forgive me for stressing this again:

MAVlink v1 does not contain all command extensions and message types to reliably change settings on the drone!

You cannot even just download all parameters. Nor does it respond to a simple "LAND" flight-mode change from the GCS. So the failure in persistently uploading/changing parameters is not surprising me at all. :hankey: I hope this impressively illustrates what unnecessary and confusing error situations we are prone to see all day long when we release this to the wild. It is absolutely necessary to fix this by getting rid of the old legacy protocol and switch to it's latest incarnation v2.3 :-)

All the world is talking MAVlink 2 nowadays just we sit in between "Lost in Translation" ;-) This depicts your exact situation here:

Connecting the GCS and FC directly via USB both are talking plain MAVLink v2 without loss in conversions and hickups due to missing message types.

[htcohio]

Hey, I fully understand that and all of those test results were verified with USB Mission planner and PC with mav v1 and v2.

I simply used qgroundcontrol because it was easier to visualize everything on the video.

I also discovered yesterday that, if I set "0" on my pixhawk (arducopter) with laptop on Tarot Hexacopter, it does not automatically change it back to 10 like it did in my video. And nothing loads or works with either Tower or Mission planner...

I just want to make sure that we have it right.

[careyer]

Sure! I will have a look into it again... but I have it on two of my copters and it works without problems.

[careyer]

Another page for the wiki... could someone proofread please.? Pictures can be clicked to view in bigger size. https://github.com/bortek/EZ-WifiBroadcast/wiki/RC-:-Reliable-Setups

Any other known WBC RC-Controllers, maybe?

[Yes21]

@ALL In the "Ground Stations" section (QGroundControl and Tower), I can read that the UDP video stream port has to be set to 5000. But in the wbc config file it is set by default to 5600 !! 5600 is working for me ...

[bortek]

@careyer corrected. What a neat and sexy controller you have built :) I like it.

[pilotnbr1]

@careyer I read your latest page. Proof read and one minor correction. Well written and nicely presented! We definitely need some more builds added in the basic category. Your build is perhaps the ultimate wbc build and thus unattainable for most.

@Yes21 yes there was some back and forth with ports at one time. I believe Rodizio did some coordinating with Consti of the Fpv vr app. Pretty sure for the most part Consti followed Rodizio’s lead. https://www.rcgroups.com/forums/showthread.php?2873827-FPV_VR-Ultra-low-latency-for-FPV-Virtual-Reality-Android-App/page3

[careyer]

@bortek : Thank you very much... I am sorry for the many typos. This just happens when you fill the sections like a madman. ;-)

@pilotnbr1 : Thanks. The controller is basically just a Pi, a Pi display and two gimbals thrown together into a enclosure! Makes the preparations to go flying and the actual flight a breeze. :+1:

[careyer]

@Yes21 / @All Once I played arround with displaying the Video in the Mission Planner HUD. As far as I can remember Mission Planner has a fixed port which cannot be changed (whereass QGroundControl etc. have settings that can be modified). Maybe we should stick to the MP port so that all GCS are compapatible? I don't remember the port anymore and how I managed to get this working... though

Update: Regarding to this MP is listening to 5600. I think that was why rodizio changed it from 5000 to 5600 as far as I can remember. I talked with him about that (I believe)

[careyer]

@htcohio : I have tested the Serial Parameter thing again with two insights:

1. SRx_Params and SDx_ADSB must not be 0 in order to allow for full bidirectional telemetry. These parameters are not needed for OSD-Telemetry or RC but they are needed to successfully connect the GCS. (Good values are SRx_Params=10 and SDx_ADSB=5 - I will edit the Wiki accordingly) So in this regard you were right. :-)

2. The problem that your modified parameters were not saved and almost every time reset to default is definetly a MAVlink version inconsitency problem. I did a full-featured testseries with both "genuie 1.6rc6 (MAV1)" and "dino.de 1.6rc6 (MAV2)" image. Here are the results: I also noticed that with MAV2 it almost does not matter at all how much telemetry data is being sent. Whereas MAV1 would likely suffer hickups when transfering too much telem data - there seems to be no more problem at all. All is as fast and reliable as via a USB cable directly plugged in. So in this regard I was right ;-) This is a big deal. Absolutely all GCS functions work :100:% flawlessly with MAVlink 2.3. This is so much fun and no longer a pain in the ass.

BTW: I was also able to figure out how to get the Video stream right into Mission Planner and have it overlayed with the HUD. Took me about 3hours so figure that out. It needs a bit of playing arround with GStreamer on the command line and only then start Mission Planner. This is sooo cool! :+1:

[pilotnbr1]

@careyer I noticed an oversight in the FAQ I wrote regarding supported rc protocol. I had left out MSP. Thought I would give you a reminder since you are writing the rc docs.

[careyer]

Luke, Thank you for pointing this out. Does 1.6rc6 still support MSP? I think I remember someone saying it was deactivated for some reason?

Btw: I never worked with MSP? What exactly is it? Telemetry or RC protocol or both? All I know is that it is somewhat related to MultiWii. Is that right?

Cheers

Von meinem iPhone gesendet

Am 20.10.2018 um 02:06 schrieb Luke notifications@github.com:

@careyer I noticed an oversight in the FAQ I wrote regarding supported rc protocol. I had left out MSP. Thought I would give you a reminder since you are writing the rc docs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Yes21]

@careyer For the OSD section, do you remember this post from you on rcgroups ? It could be nice to use it ... ?

[pilotnbr1]

@careyer all very good questions. I have many of the same. I’ll tell you everything I think I know which isn’t much. MSP stands for message send protocol, and is also known as Multiwii. Apparently it is both a telemetry protocol and radio control protocol. MSP is the native language of INav. From what I remember talking to Rodizio, wbc only supports msp v1 and currently msp is on v2 (not 100 percent sure). Looking at the .profile code here on github, is what made me remember msp. The rc function does recognize msp as an option. Not sure if it works though. I think this needs to be escalated and investigated...

[careyer]

@pilotnbr1 : Yes we should verify first if MSP (i think it was "MultiWii Serial Protocol") still is supported before we add any information to the Wiki about it. I also remember that it caused some weird problems due to the old MSP v1 version. (very similar to the Mavlink stuff).

[careyer]

@Yes21 : Sure! please go ahead and add that to the according Wiki section.... I could really need some helping hands with the Wiki.

[careyer]

@All : I cleaned up the mess under EZ-WifiBroadcast/wiki-content/ .

Please keep some order and if not yet existent create new folders according to the wiki structure for your content.

[bortek]

👍

[Yes21]

Sure! please go ahead and add that to the according Wiki section.... I could really need some helping hands with the Wiki.

@careyer I've added up to 26 numbers on your rcgroups snapshot, and have began to fill the number explanations with your text.

@ALL Could you please help to explain all the OSD informations I've identified on the snapshot ?

[RespawnDespair]

@careyer

2. I did a full-featured testseries with both "genuie 1.6rc6 (MAV1)" and "dino.de 1.6rc6 (MAV2)" image.

Where can i find this image? I want to try to merge this with the builder now the basics seem to work. No sense in publishing an image if we know mavlink is this broken...

[careyer]

@RespawnDespair : I linked it several days ago for you guys here: https://github.com/bortek/EZ-WifiBroadcast/issues/155#issuecomment-429423820

It basically is a 1.6rc6 plus added features:

• Mavlink 2,3 instead of the outdated Mav1
• GroundPi actions triggered by Joystick, e.g. OSD on/off or switch OSD screens (search for "switches" in .profile)
• AirPi actions (GPIO) triggered by Joystick (search for "airswitch" in .profile)
• Flir1 Thermal camera support (search for "###" in the .profile - multiple ocurrences) also there are some driver things needed ... can be found in /root/flir.... and /root/v4l2loop....

In case of any quetsions... you are welcome!

[bortek]

@Yes21 you have number 12 used twice on the image, check right side corner. Other than that:

5 RSSI signal? 14 GPS Direction in degrees 15 GPS Speed 16 GPS height (MSL) 17 Vertical speed (lift/sink) 20 Distance to Home/Starting point 21 Latitude 22 Longitude 24 Aircraft's Batt voltage 25 Aircraft's Batt consumption

[careyer]

12 AirPi CPU load and Temperature 13 GroundPi CPU load and Temeprature 23 Fligthmode

[pilotnbr1]

I went through the whole wiki and applied the AirPi and GroundPi terms. I did little to the configuration options page as it reflects the current variables in the project which still use rx and tx as names.

Additionally I am going to cleanup the WiFi adapter page with a table. The proposed columns are-

Name / frequency range / output power / range / notes

[careyer]

@Yes21 : very well done. Your help is much appreciated:-)

Von meinem iPhone gesendet

Am 21.10.2018 um 21:18 schrieb Luke notifications@github.com:

I went through the whole wiki and applied the AirPi and GroundPi terms. I did little to the configuration options page as it reflects the current variables in the project which still use rx and tx as names.

Additionally I am going to cleanup the WiFi adapter page with a table. The proposed columns are-

Name / frequency range / output power / range / notes

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Yes21]

@careyer : Thanks. I will correct the image, and add the explanations you and @bortek gave. Thanks in return for your help ...

[pilotnbr1]

Added a table to the supported WiFi adapter page. Double check me for accuracy, I was going cross eyed with the markup.

I left all of Rodizio’s original page and notes for now, but I propose the rest of the page be condensed so as not to be too redundant.

Personally I like tables because it organizes information and makes comparisons easier. I would like to add more tables to other parts of the wiki to further organize. Thoughts?

I think a big goal is to remember this is EZ so let’s keep it simple and approachable.

[careyer]

@pilotnbr1 : Very nice... I like the idea of the table... I added a collum "RC" since only the Atheros chipsets are afaik capable of doing RC uplink. (I am not sure what is the technical reason for that)... I also added the WifiStation EXT

[pilotnbr1]

@careyer added aw nu-137 afaik it works. Cant find details on it as no sellers I find post complete specs. Yes RC is a good idea. Some content from that wiki page would be applicable to the new antenna page. What other WiFi are we missing?

[Yes21]

@careyer

I added a collum "RC" since only the Atheros chipsets are afaik capable of doing RC uplink

I didn't knew that.

Big question : is this also true for telemetry uplink (because RC=mavlink as to be set for up telemetry) ? I can't make it work with RT5572.

[careyer]

@Yes21 : That might verry well be the case. I am not sure though. All I know is that the RaLink cards are not capable to be used for RC. Since RC is just part of the Uplink-telemetry stream.... yeah well possible.

@ALL : Here you go with the new Mission Planner and inject HD-Video directly to the HUD page: https://github.com/bortek/EZ-WifiBroadcast/wiki/GCS-:-Mission-Planner It was a real pain in the ass figuring this HUD part out. Please proofread and tell me your thoughts...

Please let me emphasize again that anybody is welcome to overhaul and contribute to the Wiki. This is so much work we can only do it together. @htcohio : Maybe you can make a go for the QGroundControl section... for all plattforms (PC / MAC / Adroid / iOS) in a similar style?

[Yes21]

@careyer

That might verry well be the case. I am not sure though. All I know is that the RaLink cards are not capable to be used for RC. Since RC is just part of the Uplink-telemetry stream.... yeah well possible.

If it works only with old atheros chipset, the scope of this project is becoming very reduced !

I could see the uplink telemetry work only one time : with the last "russian image", and my rtl8812/14au boards ...

[Yes21]

@pilotnbr1 Thanks, that's great.

Perhaps could you also add a column to inform users if the board is always manufactured or not ... ? This is a very useful information for new users.

[careyer]

@Yes21 : Totally agree... I have no idea what causes this limitation and it would be great to get rid of it. Is something missing from the driver maybe? Or was Rodizio just not able to make it work? We should investigate into this further. It will be a much bigger leap forward than supporting the RPi3B+ ... which is also a must as we all agree upon. However this will really bring more features with it. Right now only the Atheros cards can do RC-control and (very likely) your observation refering to Uplink telemetry not working on your RaLink cards is related to this as well, i.e. RaLink cards are very limited right now.

Maybe this has something to do with it? There is a file called. EZ-WifiBroadcast/wifibroadcast/rcrx.c.ignore-ralink

So bottomline for now is: Atheros AR9271 is by far the most capable chipset at the moment. Highest TX power, 2,GHz good penetration and range, and all features of an AIO system working.