Closed tr0043t closed 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.
2 things:
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
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.
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
Also fuck android dev, always the same shit. lol
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.
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)
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.
For me its the opposite. No video stream at all works on develop :/
(before the codec change). I guess you can try using sw decoding again...
I wonder if we're looking at some issue between the 2 chips Samsung is using. Which branch for the sw decoding? Thanks.
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)
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.
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.
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.
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.
Looks like it's initialized in: app/src/main/java/sq/rogue/rosettadrone/DroneModel.java
AND in preferences.xml.
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.
I should add that this is all with the develop branch, which works best for me.
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
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).
Mission do work, I tested them throughout already So only thing preventing it would be the safety switch or not-being-in-the-air.
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
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?
Exynos or Qualcomm chip? Both my tablet and phone are Qualcomm.
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.
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
OK, so if you drop a csv mission onto /sdcard, how do you actually start the csv mission from on-app?
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).
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.
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
I will really need a log tho. I plan to merge it sometime this week.
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.
just whatever android studio shows in the "Run" tab
throw me a paste at m4x (a) m4xw net
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).
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
and 12 wont be supported for a long time.
I'll rebuild changesurface again and see what happens.
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.
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
Also frankly no clue how long I am gonna support this project.
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.
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.
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.
change_outputsurface is causing so many problems here, there must be a fairly fundamental issue.
Sorry but thats a case of layer 8 :P
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.
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
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.
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.