DJI Android SDK version: 4.11
Matrice 100 / Matrice 600
I am trying to take off the drone vertically.
I tried with GoToAction in a timeline, but that failed due to some bug in the SDK, (confirmed by your support team dev#dji.com #29496) I get STARTED for the GoToAction, but no PROGRESSED or FINISHED, and no errors logged at all.
Since I need to continue working, I tried a workaround by sending FlightControlData to the VirtualStick by calling the following function with the requested height 20 times a second:
VerticalControlMode.POSITION
FlightOrientationMode.AIRCRAFT_HEADING
VirtualStickModeEnabled = true
VirtualStickAdvancedModeEnabled = true
void sendHeightCommand(Float requestedAltitude) {
FlightControlData data = new FlightControlData(0f, 0f, 0f, requestedAltitude);
flightController.sendVirtualStickFlightControlData(data, djiError -> {
log.v(djiError.getDescription);
});
}
And it works (with the right amount of timeouts) but if there is wind, the drone drifts away, which is very dangerous for me as there is more than one drone in the field, and I don't want them to collide.
Is there another way to change the altitude of the drone, while maintaining its position?
Or is there a way to measure the wind, and push back against it?
[*] Take off drone vertically:
I always use the TakeOffAction in the timelineMission before the GoToAction to ascend to the desired height. However I'm using a Mavic Pro and the SDK may behave different with a matrice drone.
When using the FlightControlData with the VirtualSticks, I use the startPrecisionTakeoff() method in the FlightController class; after the takeoff, the drone ascends to the desired position when the flight control data is sent continuously.
[*] stable hovering:
For the hovering the only low cost solution I see is to enable the VisionAssistedPositioning in the FlightAssistant class, I don't know if the Matrice supports this feature as the documentation doesn't say anything on the supported aircrafts.
Ok so the solution was to use the function: setVirtualStickAdvancedModeEnabled(true)
The reason I didn't see any results was because in the simulator I was playing with 20.0 North Wind, which apparently is too much.
When I lowered it to 5.0 it works perfectly.
Related
I am trying to develop a mobile application using DJI Mobile Android SDK. The goal of the application is navigate a Mavic 2 Pro to a target GPS coordinates and automatically center a camera on a vehicle and take a snapshot. After taking off and flying to target altitude a new tracking mission in spotlight mode is called to find an object and center a camera on it.
The first process goes normally after an aircraft is turned on and the mobile application runs the missions. The aircraft is landed manually.
The second trial with the mobile application goes wrong. There is an additional yaw motion that is not in time line mission. I have missed some cleaning method that reset the aircraft to an initial clean state probably.
How to setup the aircraft to a clean state before the application starts the missions please?
I don't understand why there is a yaw 45° motion in a simple
time line mission:
missionControl.scheduleElement(new TakeOffAction());
missionControl.scheduleElement(new GoToAction(2.0f));
missionControl.startTimeline();
Why the aircraft yaw 45° after the takeoff while it is lifting to target
altitude? It's to see https://youtu.be/-gCWFXou-WI
You never share any other code. so below is my list of guess/checklist for a possible solution.
First, clear all other code, e.g disable drone yaw following or any other possible routing with the keyword of tracking/following etc from both code and remote controller screen
The easiest way to check if it caused by this is to call
elements.add(new GoToAction(new LocationCoordinate2D(homeLatitude+0.00001, homeLongitude+0.00001), 5));
elements.add(new GoToAction(new LocationCoordinate2D(homeLatitude-0.00001, homeLongitude-0.00001), 5));
if the camera still follows you while at a multiple location. Then sth at tracking is bothering you. If follow it could be caused by home lock also
Secondly, GoToAction never mentions about the orientation but only 3D position. Theoretically, they can do anything they want. so check API for all orientation method/setting e.g
Use setFlightOrientationMode to set course lock or home lock to get your desired behavior.
method setFlightOrientationMode
void setFlightOrientationMode(#NonNull FlightOrientationMode type,
#Nullable CompletionCallback callback)
Package: dji.sdk.flightcontroller
SDK Key: FlightControllerKey.ORIENTATION_MODE
Description:
Sets the aircraft flight orientation relative to the Aircraft Heading, Course Lock, or Home Lock. See the Flight Controller User Guide for more information about flight orientation.
Last I assume you removed all other possible following modes and it is still not behave according to your wish.
The api given is
GoToAction(LocationCoordinate2D coordinate)
GoToAction(float altitude)
float altitude Target altitude in meters.
GoToAction(LocationCoordinate2D coordinate, float altitude)
If the direct setting altitude has an issue. Can you try the full command to determine it is a bug in the source code or it is sth else
double homeLatitude = get your start gps lat;
double homeLongitude = get your start gps long;
elements.add(new GoToAction(new LocationCoordinate2D(homeLatitude, homeLongitude), 2));
If you are sure that you have no other routing that bothers the drone, and both GoToAction(float altitude) and GoToAction(LocationCoordinate2D coordinate, float altitude) has the same yaw problem. open a ticket in dev#dji.com.
Personally, I don't think it is DJI`s issue. Because you never post the full code so I have no idea what you have done or you haven't have done but should have done. So good luck in finding the solution to your unwanted behavior.
I'm using LWJGL 2.9.3 to create a window and retrieve mouse coordinates via LWJGLs Mouse.getX(),getY() methods. The results by those methods and by events via getEventX() are equal.
The coordinates I get back are correct using linux (ubuntu gnome, dm: i3) but aren't when using windows 8. (I considered wrong monitor settings due to second monitor but couldn't achieve anything by disconnecting/resetting/changing them)
Here are 2 images with estimations of the coordinates I get on both operating systems.
Correct, linux:
Incorrect, windows:
When activating fullscreen, I get data for both variables, the X coordinate seems to fit, the Y coordinate is somewhat off and changes for multiple clicks on the same location.
Here is the entire code I'm using for this example:
https://gist.github.com/Geosearchef/5889a13edd6b983959e837a8506170af
Does anyone have any idea what could be causing this? A bug with LWJGL? I was already using that exact version on Windows and was able to do it. A problem with my installation?
UPDATE: ((WindowsDisplay) Mouse.implementation).mouse.last_x has the correct value, ((WindowsDisplay) Mouse.implementation).mouse.last_y is correct if you set its origin at 1/3rd from the top. Below that it get's negative --> getting clamped. I don't know though why x gets set to -1.
UPDATE: The mouse implementation fails due to the Display class returning 0, 100 as width and height. This is ignored in the case of fullscreen. Width and height are set correctly in the beginning but are later overriden by an update (resize) call from the underlying implementation.
I've now figured out the problem. I used the natives of and old LWJGL implementation (2.9.1) which were stored in my project files.
even though the google nexus 6P isn't classified as "Daydream-Ready" it can be used as a development platform for Daydream. Has anyone tested Async Reprojection on the Nexus 6P and can confirm that it supports Front-Buffer bzw. Single-Buffer rendering, or supports the EGL_MUTABLE_RENDER_BUFFER_BIT_KHR Extension on Android 7 ?
confirmed it on 6P. the Async Reprojection is the Front-buffer rendering feature. the latency is about 20ms compare to 80+ms without it.
it will render with Timewrapping on a new thread.
I found this Site http://opengles.gpuinfo.org/gles_generatereport.php?reportID=932 which lists EGL extensions for most Phones. According to the Specs, EGL_MUTABLE_RENDER_BUFFER_BIT_KHR btw. EGL_KHR_mutable_render_buffer is supported on the Nexus 6P. The other Phones that support "Front Buffer Rendering" and so would be capable of "Async Reprojection" are: Nexus6P, Nexus 5X and Google Pixel. Surprisingly these are the only few Phones, even though as of 28.11.2016 the Moto Z is advertised as "daydream-ready". Probably the data base for the Moto Z hasn't been updated yet. So the HW of the Nexus6P is capable of async reprojection (and so sub-20ms-Motion to Photon Latency) and probably supports daydream async reprojection, even though not classified as daydream-ready.
I can now also confirm that both on the Nexus5X and Nexus6P it is possible to create a valid EGL Config that allows rendering to the front buffer. Ether by adding
EGL_SURFACE_TYPE,EGL_MUTABLE_RENDER_BUFFER_BIT_KHR
to the context attribute list and then toggeling between front and back buffer, or by simply adding
EGL_RENDER_BUFFER,EGL_SINGLE_BUFFER to the surfaceAttribs list.
This will create a surface that only works in single buffer mode,and may also work on all Android 7 devices, even devices without the "mutable" extension.
But I couldn't test the second approach on phones with android 7 but without "mutable" extension.
Of course, since google decided not to classify the Nexus5X as "Daydream-ready", Async reprojection is only working on the Nexus6P (and various other daydream-ready phones).
But achieving sub-20ms motion-to-photon latency by drawing directly into the front buffer and syncing the rendering of each eye with the display scan-out is also possible on the Nexus5X, as I figured out when I developed a method called "eye-alternating front buffer rendering with vertex displacement distortion correction".
XNA apps (WP7 or WP7.5 apps) that run on a WP8 720p device will get automatically letterboxed so the 480x800 BackBuffer size stays the same (for compatibility I presume).
This would be fine, except there appears to be a bug in the XNA compatibility layer. The TouchPanel reports touch locations that are off by the size of the top letterbox blank area.
This has two problems:
The user's touches will appear to be off making gameplay and menu navigation difficult.
Because it is off in the negative direction, the user will be unable to touch things at the very bottom of the screen at all.
I tried working around the issue by just factoring in 53 / 2 pixel offset (53 is the total amount of extra space in scaled coordinate, divide by two because it is only off by one letterbox bar - the one on the top). This does correct the touch location, but because TouchPanel internally clamps negative values to 0, it means that there is still a dead zone at the top of the game (because -22 through -1 should be translated to 0 through 22, but if all negative input values are clamped to 0 then information is lost and everything in the negative range will translate to 22 always).
Has anyone run into this and found a way to work around it?
I'v even tried resetting the TouchPanel.DisplayHeight/Width to the actual 720p values of the device and somehow it gets reset to 480x800 by the next frame update.
I just got this working, the TouchPanel.DisplayHeight needs to be set to 853 (if you detect you are on one of these 720p devices) very early. I do it at OnNavigatedTo from the main Silverlight page (this is SL/XNA actually).
Next, you have to offset every touch location and gesture location by + 53.0f / 2.0f.
I'm not sure why this didn't work before, as this is the solution I mentioned above that didn't seem to work because TouchPanel kept resetting to 800 height.
But, I got it working in both a reduced repro (new SL/XNA app) and my main game app.
I was working on a game a couple days ago.
It was packaged for 7.1, but worked fine on the 720p emulator.
I don't know much about the compatibility layer, if it gets effected by the size of images then here goes :
I created separate images for WVGA, WXGA and 720p. Used them and found out about the letterboxing and decided to use 720p images for all.
Probably doesn't help but there you go anyway.
This is great solutio what I found from here: http://developer.nokia.com
It's not just fixing issue with touch but it also remove black blocks from side. Of course depending about your programn this can cause some more issues since resolution and screen ratio will change.
if (Environment.OSVersion.Version.Major == 8)
{
int? scaleFactor = null;
var content = System.Windows.Application.Current.Host.Content;
var scaleFactorProperty = content.GetType().GetProperty("ScaleFactor");
if (scaleFactorProperty != null)
{
scaleFactor = scaleFactorProperty.GetValue(content, null) as int?;
}
if (scaleFactor == null)
scaleFactor = 100;
if (scaleFactor == 150)
{
SharedGraphicsDeviceManager sdm = SharedGraphicsDeviceManager.Current;
sdm.PreferredBackBufferHeight = 800;
sdm.PreferredBackBufferWidth = 450;
TouchPanel.DisplayHeight = 800;
TouchPanel.DisplayWidth = 450;
}
}
I am writing an app for Windows Phone 7 that uses the GPS to track how far and how fast the user is going. Using the Haversine formula according to Dr. Math. http://mathforum.org/library/drmath/view/51879.html I can figure out how far this device has moved since the GPS was started. I am trying to display the speed that the user is traveling in a textblock in miles per hour by using this code here This code is fired when the position is changed.
tblSpeed.Text == (((watcher.Position.Location.Speed * 60) * 60) / 1609.344).ToString()
When I run the app in the emulator and using the GPS emulator recipe found on the WP7 blog I only get 'NaN' in my speed text block. I have a timer that is timing how long the gps has been tracking and I have tried this code there too with the same result. Any ideas on what I could do to resolve this.
It seems that the GPS Recipe doesn't transmit the speed properly. However, check a comment by Morten Nielsen on the blog page as he explains how to manually calculate the speed.