Thread Tools
Apr 17, 2019, 11:07 AM
Htcohio
Htcohio's Avatar
Thread OP
@All,

Thank you for all the recent testing and feedback.

I need to ask all of you to please try and open issues on this GitHub page for any problems or issues that you find with the system. It really helps us keep track of everything. we are working on it handful of small bugs and optimizing the wiki right now so, I just don't want any relative issues to be lost on RC groups here.

if you're not familiar with GitHub or don't understand how to open an issue let me know, I was a little confused at first but it's pretty straightforward once you figure it out and it's also easier to navigate GitHub from a web browser as opposed to mobile.

https://github.com/HD-Fpv/Open.HD/issues

Thanks!

Sent from my SM-G975U using Tapatalk
Sign up now
to remove ads between posts
Apr 17, 2019, 12:24 PM
Registered User
Quote:
Originally Posted by FlyingW
Yes, Mission Planner comes up fine, collects the parameters and displays the video in the HUD. I just tried it again with the April 14 build and it tests ok (barometric altitude in either imperial or metric still not showing in the OSD). Mission Planner failed to connect when I turned up the airpi first and then turned on the groundpi. The reliable sequence is:

1. Turn on groundpi
2. Add joystick controller to groundpi
3. Turn on airpi
4. Verify that groundpi and airpi connect and video and telemetry come up on the OSD
5. Verify that the Mission Planner PC is connected to the groundpi's hotspot (wait for secondary display message on the OSD)
6. Open Mission Planner - it usually connects automatically by way of udp port 14550 after the first time

I have a Pi 3 Model B+ with its 5.8GHz internal wifi module as the wifi hotspot. When the PC connects to the hotspot the OSD says that the secondary display is in effect.

Kept the wifi hotspot at its default value of "auto" and all other settings concerning the wifi at the default values in the apconfig and openhd-settings files.

The system first comes up on another frequency, I think 2412 MHz, then switches to 2472 MHz. I suppose this is to perform the smart sync.
But you do get a working altitude display after your gps gets a 3d position, right?

Assuming Mavlink1 protocol we are reading mavlink message- mavlink_msg_global_position_int_get_relative_alt
I believe this is the same as EZ. There are quite a few different possibilities for reading altitude as you know. I am not sure why this was originally chosen but it may have been because we are trying to support as many flight controllers as possible.

You can take a look and change it to something else if you like on your image
https://github.com/HD-Fpv/Open.HD/bl...-osd/mavlink.c
Keep in mind the osd gets built at runtime every time so there is no need for you to clean and make manually
Apr 17, 2019, 12:42 PM
Build more, websurf less
FlyingW's Avatar
I am using MAVLink 2. Should I be using MAVLink 1?
Apr 17, 2019, 02:17 PM
Registered User
Quote:
Originally Posted by FlyingW
I am using MAVLink 2. Should I be using MAVLink 1?
Could you explain how to check what version of mavlink is installed please.?????
Apr 17, 2019, 02:24 PM
Build more, websurf less
FlyingW's Avatar
I've only set the Ardupilot parameter called: SERIALn_PROTOCOL= 1 or 2, for MAVLink 1 or 2.
Last edited by FlyingW; Apr 17, 2019 at 02:49 PM.
Apr 17, 2019, 05:11 PM
Htcohio
Htcohio's Avatar
Thread OP
Quote:
Originally Posted by flierman1945
Could you explain how to check what version of mavlink is installed please.?????
Hey, it's nothing that needs to be installed it's simply a parameter for the serial Port your telemetry is connected to.

you have a standard pixhawk correct?

if so, you're probably connecting telemetry to your raspberry Pi through serial 1 or serial 2.

so, on Mission planner or qgroundcontrol, go to parameters, then search "SERIAL"

next, you should see a bunch of options come up, one of them should be telemetry protocol then in the drop-down you'll see mavlink V1 and mavlink V2.

V1 is older and, only allows 8 RC channels but works with the fpv VR app (in addition to a few changes in the app).

V2 is newer and has additional functions you may or may not need and allows 16-24 RC channels but at the moment does not work with fpv VR.

I hope that helps.

Sent from my SM-G975U using Tapatalk
Apr 17, 2019, 08:20 PM
Build more, websurf less
FlyingW's Avatar
Quote:
Originally Posted by pilotnbr1
But you do get a working altitude display after your gps gets a 3d position, right?
Pilotnbr1,

I do not know. I have always used barometric altitude as it is more accurate and better for my needs.

Paul
Apr 18, 2019, 08:03 AM
Registered User
Quote:
Originally Posted by FlyingW
Pilotnbr1,

I do not know. I have always used barometric altitude as it is more accurate and better for my needs.

Paul
So with EZ being the base it has mostly been that your speed and altitude displays do not come alive until you get a gps fix as that particular Mavlink message is derived from gps data. At one time if memory serves the speed and altitude displays would not even display until you got a 3d gps fix- but so many ppl kept complaining that their osd was broken, the default became the present solution.

For some time I also believe that mavlink vfr hud altitude messages were used as the altitude source but again this was changed to the present use of gps altitude. After I type this I am going to search the ez thread (or maybe even the original wbc thread) for some of the history on this switch as there were reasons I can’t remember.

In my mind we should try to support as many users without too much fiddling so that drives us to what is available in the mavlink common message stack https://mavlink.io/en/messages/common.html
The other thought I have is that I would like to see whatever altitude my flight controller is seeing as it’s basis for control and stability.

All that aside I think you are more interested in the sensor that is providing the data not so much a particular derived altitude (unless you have a really unique application). I think you are absolutely right that gps altitude can be a really bad source for altitude data. So which source is better on our flight controllers? Does it blend it all together to derive an altitude solution? Which specific mavlink message will provide the altitude number you want to see?

It is always interesting to see all the data log sensor overlay altitude real-time on a graph- such a big divergence in sources sometimes.

Edit sorry to confuse anybody with my reference to Mavlink1- Htcohio addressed that nicely, thanks!
Last edited by pilotnbr1; Apr 18, 2019 at 08:11 AM.
Apr 18, 2019, 09:34 AM
Registered User
Quote:
Originally Posted by Htcohio
Sure!

I am still putting together the full instructional videos it's just taking time.

on another note anyone interested in fpv VR I was able to get it running. I've attached a couple screenshots of the VR app and you also must enable Mavlink V1 on Pixhawk.

Please us. take a look at the VR app settings that worked for me.

Sent from my SM-G975U using Tapatalk
Got the VR app working at long last, I checked, and my Telem 2 protocol was set to Auto, changed to Mav1 and that has given me telemetry on my nexus 10 working somewhat. My video is fine on its own, but with video and OSD data together the data works but the video is breaking up. Seems there is some thing killing the video stream.
It might be ok for a few seconds then I see video tearing.
I'm now on port 5000 UDP video port and mavlink port 5004 for OSD. Is this the same as your setup and are you experiencing any video breakup when viewing picture and OSD telemetry?.
Settings 1 txt says this below:-
Set this to "raw" to forward a raw h264 stream to 2nd display devices (for FPV_VR app)
# Set to "rtp" to forward RTP h264 stream (for Tower app and gstreamer etc.)
FORWARD_STREAM=rt

but your short how to has rtp circled
I think you may have circled the wrong tab. I think it should be "Raw"
Any thoughts?????
Last edited by flierman1945; Apr 18, 2019 at 10:04 AM.
Apr 18, 2019, 10:57 AM
Build more, websurf less
FlyingW's Avatar
Quote:
Originally Posted by pilotnbr1

All that aside I think you are more interested in the sensor that is providing the data not so much a particular derived altitude (unless you have a really unique application). I think you are absolutely right that gps altitude can be a really bad source for altitude data. So which source is better on our flight controllers? Does it blend it all together to derive an altitude solution? Which specific mavlink message will provide the altitude number you want to see?

It is always interesting to see all the data log sensor overlay altitude real-time on a graph- such a big divergence in sources sometimes.
pilotnbr,

Below I placed log excerpts for a recent flight. The first one shows the barometric altitude and the GPS-derived altitude. The barometric at the highest point was 47 meters about 150 feet. The GPS-derived was 250 meters higher overall.

The second chart is what Arducopter EKF2 decided to use for the altitude estimate - it was much closer to the barometric altitude which is what really happened.

Paul
Apr 18, 2019, 11:54 AM
Htcohio
Htcohio's Avatar
Thread OP
Hey guys, just sharing a video of a short flight. (S500 quadcopter).

Also tested out the new custom qgc app.

All stock settings and the drone antenna was actually very poor I tested it the vswr and it was really off.

overall, great control no issues from what I could tell. CPU was happy around 50%.

flight videos after this one it was getting darker out so the video was crummy.

This was a V1 camera, USB RC, AR9271 Cards and Only little rubber ducky pickle 5db antennas

Quick Flight testing Open.HD & New Custom Qgroundcontrol App (9 min 25 sec)


Sent from my SM-G975U using Tapatalk
Apr 18, 2019, 12:01 PM
Htcohio
Htcohio's Avatar
Thread OP
Quote:
Originally Posted by flierman1945
Got the VR app working at long last, I checked, and my Telem 2 protocol was set to Auto, changed to Mav1 and that has given me telemetry on my nexus 10 working somewhat. My video is fine on its own, but with video and OSD data together the data works but the video is breaking up. Seems there is some thing killing the video stream.
It might be ok for a few seconds then I see video tearing.
I'm now on port 5000 UDP video port and mavlink port 5004 for OSD. Is this the same as your setup and are you experiencing any video breakup when viewing picture and OSD telemetry?.
Settings 1 txt says this below:-
Set this to "raw" to forward a raw h264 stream to 2nd display devices (for FPV_VR app)
# Set to "rtp" to forward RTP h264 stream (for Tower app and gstreamer etc.)
FORWARD_STREAM=rt

but your short how to has rtp circled
I think you may have circled the wrong tab. I think it should be "Raw"
Any thoughts?????
Hi,

My setup just has RTP and 5600 (all default settings) I just had 5600 set on VR app.

you may suck raw on the config.txt and also in the VR app. I do not notice much difference between the two if any, I also prefer to use RTP so that I can switch between the VR app and qgc.

Sent from my SM-G975U using Tapatalk
Apr 18, 2019, 02:15 PM
Registered User
Just had another S036AC arrive, have now 2 wifi dongles on the Gnd Pi. Going flying the Drone tomorrow, so will try and get some video. I will have to use my phone with a screen recording app , so I should get video, but not sure about telem.
Is your video on the VR app good, ie no loss of video frames ???????
Apr 19, 2019, 07:39 AM
Registered User
Quote:
Originally Posted by flierman1945
Just had another S036AC arrive, have now 2 wifi dongles on the Gnd Pi. Going flying the Drone tomorrow, so will try and get some video. I will have to use my phone with a screen recording app , so I should get video, but not sure about telem.
Is your video on the VR app good, ie no loss of video frames ???????
Using the S036AC you are perhaps making life more difficult on yourself... I applaud experimentation but for your first build you might consider a card that is recommended, Htcohio has tons of recommended cards! I suspect your card outputs less power than other options. At any rate 2 on the GroundPi will be much better than 1

My old galaxy s4 Phone I use exclusively for openhd seems to run the fpvr app better when connected directly to the GroundPi via usb cable.. just food for thought

Thanks for experimenting and good luck!
Last edited by pilotnbr1; Apr 19, 2019 at 07:44 AM.
Apr 20, 2019, 07:37 AM
Registered User
Quote:
Originally Posted by Htcohio
This was a V1 camera
Video quality is very bad, most analog cameras provide best image.
May be focus is lost?


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Open 3D Flight Assistant discussion and creation thread racermark DIY Electronics 5 Apr 07, 2018 11:54 PM
New Product <Discussion thread>Hubsan H111C&H111D 720P HD Camera Quadcopter RTF BG Well Mini Multirotor Drones 62 Sep 06, 2016 08:59 PM
New Product Discussion thread---FQ777-124C MINI With 2.0MP HD &Switchable Controller BG Well Micro Multirotor Drones 41 Aug 11, 2016 05:51 PM
Discussion An open discussion about Model Aviation, the FAA, and the AMA dag214 Model Aircraft & Drone Advocacy 46 Dec 24, 2015 11:07 AM
New Product HeadPlay HD FPV Headset w/ 32ch 5.8GHz Receiver - Pre-Order open at GetFPV.com GetFPV FPV Equipment 41 Dec 13, 2015 03:33 PM