Much like the GPS Coordinates are displayed OSD, it would be extremely helpful to see which way the UAV is pointed (in degrees) while flying. A good spot might be in the Status Bar at the top of the screen, as it’s only 3 digits max.
Same request was posted from @aerovisao on Feb. 7 2022, but doesn’t look like it was addressed.
Please like/vote for this, thank you!
I find that seeing the visual heading as displayed in the map (see #5 below) to be much more useful than seeing a numerical heading value displayed in the OSD. I also configure one of the C1/C2 buttons to quickly swap between the camera view and map view.
Hi @wesbarris, Thanks for your thoughts, but I’m looking for the digital readout so that I can plug it in to Waypoints in the Mission Hub on my desktop between flights. I photograph and video buildings and construction sites, and it’s nice to have building lines even with the image frame. Right now it’s a guessing game when I review the footage to refine the waypoint headings. If the heading were displayed in the App, it would save a lot of review time (and battery) when flying over & over again just to figure out the best [looking] heading in Mission Hub for any given waypoint.
Ahhh. I see. Have you looked into the EXIF data in your images? I have not tried but I’m pretty sure all of that data in stored in each photo. If you want to pursue this you can check out either ExifTool or Picture Information Extractor.
Good idea. I looked at an image with ExifTool [thanks for the suggestion] and was able to determine a good looking heading from a photo I manually lined up. However, that would require a preliminary mission with stopping at each waypoint to manually choose an optimal heading, then going back to the desktop to review each photo with the ExifTool, then enter that data into a revised mission, and flying again… hoping I got it right. It would be much easier to just make a note of exactly what the App sees while in the air, so if there are any discrepancies, the data entered into the Mission Hub would correspond to what the camera saw during flight. But for now, I think that’s a good workaround.
I’m still not really understanding your workflow but that’s ok. I just wanted to make one more suggestion.
Did you know that you can configure your C1/C2 buttons to place a waypoint at the drone’s current location? By doing so, you can fly your drone, frame your subject, press the C1 (or C2) button to store the waypoint, then repeat. This will eliminate the need for writing anything down (if that’s what you do).
I just thought I’d throw this out there in case it might help.
It’s too cumbersome to modify missions with the App while on site and so I choose to make any corrections in the Mission Hub while at my computer desktop, then go out and fly the mission to see if it needs any changes. Marking a waypoint with a C1/C2 button is another great suggestion. That would probably solve the whole heading issue too I suppose! 
Thank you!
Hi there,
I am having the same problem as you. I already have a route plan to monitor restoration in a mine. As I am having more areas restored, I want to add new waypoints to my route plan. I have firstly compared the app data of the firsts waypoints with its exifdata and, surprise, always headind parameter is not very precise as it varies +/- 2º (exifdata compared with app data). I wanted to know what is the exact heading to add new waypoints defininng, among other parameters, this one.
Do you have any idea?
Cheers.
Hi @Gonzalo, I agree, the exifdata isn’t as accurate as it could be. I’ll fly a mission, review the exifdata on my desktop, and make a heading correction in the Mission Hub by a degree, then go back out and see if it looks good. This often takes several tries (and flights) before getting it spot on.
So I have still been struggling with this for a while, and remember that @wesbarris suggestion of creating a mission ‘on the fly’ using [assigned] C1 and/or C2 buttons should alleviate any [major] corrections in the Mission Hub down the road. I will (finally) be re-creating one of my missions this week with this method, using the C2 button. I tried it with a dummy mission, mapping the C2 button to ‘Add Waypoint’ (and hopefully heading and gimbal degrees are included), and the C 1 button to ‘Do Nothing’ (as I often hit it by accident and the App pops up a screen asking to unlock the mission- very distracting). Seems promising.
Since my last post, I have just been [lazy and…] stopping photo missions at the improperly headed waypoint, adjusting the heading and taking a photo, then resuming the mission from that waypoint. But then stopping it again at the next improperly aligned heading, which eats up time & battery. Doing this even 2 or 3 times during a 15 point mission probably eats up 5 minutes of battery. Video is a whole ‘nuther story. Can’t just stop the mission, so it’s been back & forth to the desktop (Mission Hub). The only other alternative I see is to create a new mission on the fly with the C1 / C2 buttons.
So from what I understand with your situation, would be to fly your [unlocked] mission, and after the last waypoint have it ‘do nothing’. Then manually fly to where you want the next waypoint to be [at altitude, heading, and gimbal degree] and press C2 (as mapped above). Immediately save your mission as a new version, then when you get back to the Mission Hub on a desktop, you can analyze your new waypoint and make any corrections you may have noted during flight, then copy a newer version back to your App device for your next flight. Let me know if this helps.
Just as a side note: I always narrate in realtime my flights into my cell phone’s audio recorder, then on my desktop, line up the flight’s video and cell’s audio in Premiere Pro for the flight review. Works great for video reviews.
I will post back with any updates I have.
Happy Holidays!
What EXIF data are you using to determine the heading? I find the EXIF data to be pretty accurate but I find the EXIF naming to be confusing.
There are two “yaw” values available in the EXIF data:
One would think that “GimbalYawDegree” would contain the value where the camera is pointing but it doesn’t. I have found that “FlightYawDegree” very closely matches where the camera is pointing. “GimbalYawDegree” differs by up to a few degrees and does not match the flight.
Curiously, “XMP:GimbalPitchDegree” does reliably show the gimbal pitch angle.
