m4xw / rosettadrone_mini2

The Rosetta Drone 2 Project. Enable Mavlink and H.264 on DJI drones. Supports Mini 2 with Virt Stick Litchi CSV and DJI Waypoint class interpreters
BSD 3-Clause "New" or "Revised" License
28 stars 7 forks source link

No video on UDP 5600 #5

Closed tr0043t closed 3 years ago

tr0043t commented 3 years ago

In the project description it notes:

View drone video feeds in QGC or forward RTP to an IP address of your choice (currently Mavic Pro 2 only)

Does the Mavic Pro 2 restriction apply to both UDP 5600 video and RTP? So far using the Mini 2 (emulating Air 2) I can see video in the RD app itself, but have been unable to see any video at all on QGC (or any other UDP video app, either on the same device or an external device). Of course I've set the parameters in QGC properly for UDP video streams on 5600, and I do have the telemetry linkage to QGC -- just no video.

Is there something I'm missing or is this simply not supported yet? Thanks.

tr0043t commented 3 years ago

Not going very well. Tried your build twice alternating with a new build of the current develop. Each time I tried yours I'd get video on the app the first time I ran it, but couldn't get any at all on the app on subsequent tries (unless I rebooted the tablet). Toggling the photo/video made no difference. When I did get the video on the app on your build, I could not get video on remote QGC. I could get video on localhost QGC, but it was extremely laggy and freezing up. So I built the current develop again. It gets video on the app every time, tearing somewhat but not freezing up. But I could not get video on either the localhost or remote QGC with the current develop.

m4xw commented 3 years ago

2 things:

  1. maybe codec bugs out because i dont properly close it or because egl/gles stuff
  2. still sounds like a bitrate issue, i hardcoded it to 20mbit based on the 40mbit limit according to docs at 20hz ocusync, try uncommenting this: https://github.com/m4xw/rosettadrone_mini2/blob/change_outputsurface/app/src/main/java/sq/rogue/rosettadrone/DroneModel.java#L826-L828

It would have a stutter everytime it changes it tho. if it fixes the problems however, i can add some tolerances

Also worth stubbing this for the test https://github.com/m4xw/rosettadrone_mini2/blob/change_outputsurface/app/src/main/java/sq/rogue/rosettadrone/MainActivity.java#L285-L287

tr0043t commented 3 years ago

Before I do this, I'm going to test the current builds on my phone (which is a significantly faster device). I've lately been testing only on the tablet (since the larger display is more convenient), but I want to try eliminate the possibility that speed issues are fundamentally involved.

m4xw commented 3 years ago

in your case i'd probably use qgc on the tablet and connect to a wifi hotspot made by your phone for best connection at 5ghz and use rosetta on your phone

m4xw commented 3 years ago

Also fuck android dev, always the same shit. lol

tr0043t commented 3 years ago

I think I can mirror the phone to the tablet with Samsung Flow too. Or one of their apps, anyway. Setting up for the phone tests now.

m4xw commented 3 years ago

Eh its nice to make mission adjustments on the fly Currently you can only pause a non-csv waypoint mission through it (and resume) I really wanna kill the startup dialog, so annoying and i think its the issue why we have these video issues at the start until we do a action (i made it switch back and forth on start btw, but its meh)

tr0043t commented 3 years ago

So everything is much better on the phone. Develop is still definitely the best. With some restarts and fiddling I can get video on the app, and/or local/remote QGC. Usual latency but very little if any tearing. The surface branch is more problematic. I have trouble getting the video going in the app or remote/local QGC. Occasionally it works but not at all reliably, especially compared with develop. Develop is probably usable as is, assuming the mission stuff works.

m4xw commented 3 years ago

For me its the opposite. No video stream at all works on develop :/

m4xw commented 3 years ago

(before the codec change). I guess you can try using sw decoding again...

tr0043t commented 3 years ago

I wonder if we're looking at some issue between the 2 chips Samsung is using. Which branch for the sw decoding? Thanks.

m4xw commented 3 years ago

Try pasting this line (from develop) onto the change_outputsurface branch https://github.com/m4xw/rosettadrone_mini2/blob/develop/app/src/main/java/sq/rogue/rosettadrone/video/DJIVideoStreamDecoder.java#L276 (same spot)

tr0043t commented 3 years ago

With this change, on first start got a frozen video frame on the app. All subsequent starts, just black on the app, regardless of toggling photo/video.

tr0043t commented 3 years ago

I just tested again (on the phone) my latest build of develop. It really was quite good. After the usual fiddling around to get the video going in different configurations, it was really comparatively smooth, very little tearing, and was working on local and remote QGC as well as on the app. Split screen also worked on the phone (in fact, it perhaps seemed even more stable than QGC in the background). Low latency mode in QGC seems to actually reduce latency a little as well. I think this works well enough to start testing mission loads within the current waypoint actions implementation, and move on from static tests using this branch.

tr0043t commented 2 years ago

BTW, regarding waypoint headings .... AFAIK it's usual to turn toward the next waypoint when starting toward that waypoint from the current one. This is logical since you typically want to see where you're heading.

tr0043t commented 2 years ago

Continuing to test (develop branch). A couple of continuing oddities. On both of my devices, when I start RD, when I initially say OPEN it switches to landscape and then seems to require starting again (that is, I end up having to hear a couple more notifications and wait for it to register again before hitting open yet again). On that second try it usually goes into the app. This happens on both the tablet and the phone.

Also, I've had zero luck changing the location of the simulator. Presumably I could change it in the code, but when I attempt to enter lat/long (e.g. -100 long, +30 lat) in the drone settings in the SIM section, it never seems to take effect. In fact, I've been unable to get the simulator to start up anywhere in North America. Very strange.

tr0043t commented 2 years ago

Looks like it's initialized in: app/src/main/java/sq/rogue/rosettadrone/DroneModel.java

tr0043t commented 2 years ago

AND in preferences.xml.

tr0043t commented 2 years ago

OK, I'm now trying to test missions in the simulator. I can get the simulator to work fairly well manually from the controller (the craft icon doesn't rotate, and altitude changes don't affect the satellite map display, but the icon otherwise moves as it should).

However, I'm unable to get missions started -- I may simply be doing this wrong. I can upload missions from a remote QGC and I get a Done confirmation. However, I have been unable to actually start a mission in the simulator. I take off manually from the app, then choose Mission Start in QGC. Nothing happens. I've tried this in the default Stabilize QGC mode and in Guided mode. Is there a different procedure I should be using to upload/start missions in the simulator? Thanks.

tr0043t commented 2 years ago

I should add that this is all with the develop branch, which works best for me.

m4xw commented 2 years ago

BTW, regarding waypoint headings .... AFAIK it's usual to turn toward the next waypoint when starting toward that waypoint from the current one. This is logical since you typically want to see where you're heading.

iirc it passes 0, which is north. If it was NaN i could check for it, but so far its virtually indistinguishable.

On both of my devices, when I start RD, when I initially say OPEN it switches to landscape and then seems to require starting again (that is, I end up having to hear a couple more notifications and wait for it to register again before hitting open yet again). On that second try it usually goes into the app. This happens on both the tablet and the phone.

Not my bug.

Also, I've had zero luck changing the location of the simulator. Presumably I could change it in the code, but when I attempt to enter lat/long (e.g. -100 long, +30 lat) in the drone settings in the SIM section, it never seems to take effect. In fact, I've been unable to get the simulator to start up anywhere in North America. Very strange. OK, I'm now trying to test missions in the simulator. I can get the simulator to work fairly well manually from the controller (the craft icon doesn't rotate, and altitude changes don't affect the satellite map display, but the icon otherwise moves as it should).

However, I'm unable to get missions started -- I may simply be doing this wrong. I can upload missions from a remote QGC and I get a Done confirmation. However, I have been unable to actually start a mission in the simulator. I take off manually from the app, then choose Mission Start in QGC. Nothing happens. I've tried this in the default Stabilize QGC mode and in Guided mode. Is there a different procedure I should be using to upload/start missions in the simulator? Thanks.

For sim just hit the button and hit Open till u get in.

As for the missions, you need to "unlock" the Lock Icon as safety feature. It sets a second or so after start so if u quick connect it will enable it again, even if you lifted off.

can get the simulator to work fairly well manually from the controller (the craft icon doesn't rotate

Ah, use QGC for it. Yea the in-app view doesnt show orientation in rosetta. Thats how upstream did it.

Simulator location is specified here btw https://github.com/m4xw/rosettadrone_mini2/blob/develop/app/src/main/java/sq/rogue/rosettadrone/DroneModel.java#L328-L349

Using comma instead of dot or smth? Def works here, needs simulator restarted tho

tr0043t commented 2 years ago

That's really weird. I'm sure I've been unlocking the safety lock -- I have to do that before taking off before I try say Start Mission from QGC. But hmm, if it locked again right after takeoff I may not have noticed. I'll try this again, once again with Start Mission from QGC in Guided mode or Stabilize mode. The missions do seem to upload properly from QGC (at least as far as QGC is concerned).

m4xw commented 2 years ago

Mission do work, I tested them throughout already So only thing preventing it would be the safety switch or not-being-in-the-air.

m4xw commented 2 years ago

and yea the safetly lock is sneaky. Not sure why theres a timer to begin with.. If you are quick its easy to unlock & takeoff before the timer sets it on start. I might just kill it. Btw I had someone else test with a mavic air 2 on another device and video stream was fine for him too. Really wonder whats up with your hardware

tr0043t commented 2 years ago

How do you start a mission from the app itself, rather than from QGC? The commands in the Waypoint 1 and Waypoint 2 sections of settings don't seem relevant to this setup. Thanks. Can waypoints actually be entered in the in-app dialogue there, rather then uploading from QGC?

tr0043t commented 2 years ago

Exynos or Qualcomm chip? Both my tablet and phone are Qualcomm.

m4xw commented 2 years ago

How do you start a mission from the app itself, rather than from QGC? The commands in the Waypoint 1 and Waypoint 2 sections of settings don't seem relevant to this setup. Thanks. Can waypoints actually be entered in the in-app dialogue there, rather then uploading from QGC?

No, they can currently only be programmed and started/paused via QGC.

Only csv works in-app.

Exynos or Qualcomm chip? Both my tablet and phone are Qualcomm.

Don't think it was a Samsung, will ask tho.

m4xw commented 2 years ago

Btw make sure you don't use QGC from the Play store but get the latest APK on their page. Fwiw he tested some xiaomi device

tr0043t commented 2 years ago

OK, so if you drop a csv mission onto /sdcard, how do you actually start the csv mission from on-app?

tr0043t commented 2 years ago

I have been using the Play store QGC, but they have like a daily build. But most of my QGC tests have been from a remote system (Ubuntu).

m4xw commented 2 years ago

the bottom button on the left side (no confirmations or anything!) You can pass any export from https://flylitchi.com/hub (Make sure the 1st line, header, is commented or removed, file needs to use unix line endings \n)

File needs to be at /sdcard/waypoints.csv Currently that has the most complete feature-set as well but no way to pause/resume missions.

m4xw commented 2 years ago

Btw a shot in the dark but try removing https://github.com/m4xw/rosettadrone_mini2/blob/change_outputsurface/app/src/main/java/sq/rogue/rosettadrone/MainActivity.java#L947-L948

And see if you still have the issue of it only working once

m4xw commented 2 years ago

I will really need a log tho. I plan to merge it sometime this week.

tr0043t commented 2 years ago

Be glad to send you a log if you'll tell me the procedure you want me to use to capture it, I haven't really played with the logging options in there. Also, I'd prefer to move things like that around via email, rather than here.

m4xw commented 2 years ago

just whatever android studio shows in the "Run" tab

m4xw commented 2 years ago

throw me a paste at m4x (a) m4xw net

tr0043t commented 2 years ago

BTW, have we considered Android level issues? Both of my devices are on 11, and as we mentioned earlier whether or not the file access model will even work on 12 is a possible problem (and that's likely coming before the end of the year).

m4xw commented 2 years ago

BTW, have we considered Android level issues? Both of my devices are on 11, and as we mentioned earlier whether or not the file access model will even work on 12 is a possible problem (and that's likely coming before the end of the year).

Needs at least android-23 api level

m4xw commented 2 years ago

and 12 wont be supported for a long time.

tr0043t commented 2 years ago

I'll rebuild changesurface again and see what happens.

tr0043t commented 2 years ago

Google and Samsung will be pushing that out to pretty much everything even relatively recent in short order. They're under a lot of pressure from G due to security model changes, and it's impossible to avoid those updates for very long.

m4xw commented 2 years ago

Google and Samsung will be pushing that out to pretty much everything even relatively recent in short order. They're under a lot of pressure from G due to security model changes, and it's impossible to avoid those updates for very long.

I am sure the SDK and upstream rosetta will blow before my code even falls apart. Also I dont really care before it becomes a issue for myself. I will probably just use a older device even then. Depends on the effort. I am a C++ dev and no android dev, so u can hunt me with that lol

m4xw commented 2 years ago

Also frankly no clue how long I am gonna support this project.

tr0043t commented 2 years ago

I reverted my build of change_outputsurface to use the VIDEO_ENCODING_FORMAT codec rather than the googleh264 decoder. With the google decoder I got no video at all under any conditions, not even on the local app. I also pulled out the if clause with #L947-L948 in it. The result was the app won't start at all anymore. I get the initial screen but the CHOOSE AN APP FOR THE USB DEVICE panel keeps popping in over and over. I was seeing this sometimes even before this build on change_outputsurface. I'm going to pull a fresh copy of change_outputsurface and rebuild from scratch tomorrow.

tr0043t commented 2 years ago

Went ahead and pulled down a clean copy of the repo and rebuilt change_output surface from that. Won't run on tablet -- keeps getting the "choose app for this usb device" panel. Will start up without that problem on phone, but gets no video at all. Current develop is fine on both devices.

tr0043t commented 2 years ago

BTW, tried to get a log from Android Studio. It's refusing to run the built apk, complaining its unsigned even though it is signed. I've never had much luck getting apps to run in this version of Android Studio, and if I start to tamper with the configuration with updates it's likely to start failing building the apps at all. Since develop is running fine for me and change_outputsurface is causing so many problems here, there must be a fairly fundamental issue.

m4xw commented 2 years ago

change_outputsurface is causing so many problems here, there must be a fairly fundamental issue.

Sorry but thats a case of layer 8 :P

tr0043t commented 2 years ago

Seems unlikely to be a user-related issue given the same behavior on two different devices when the develop build works fine. I am going to set up a new source tree just for this branch in case the Android Studio build environment has become corrupted in some manner -- unfortunately a common issue with AS.

m4xw commented 2 years ago

Seems unlikely to be a user-related issue given the same behavior on two different devices when the develop build works fine.

And here I confirmed it works on 3 different devices, shrug

tr0043t commented 2 years ago

Do you have a current build of that branch that I can try? That would be a pretty definitive test for a local build issue.

On Tue, Oct 26, 2021 at 7:42 AM m4xw @.***> wrote:

Seems unlikely to be a user-related issue given the same behavior on two different devices when the develop build works fine.

And here I confirmed it works on 3 different devices, shrug

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/m4xw/rosettadrone_mini2/issues/5#issuecomment-952012079, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3AUECSJZTG6LGHLJFVPXLUI3EAHANCNFSM5FL6F56A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.