Issue Regarding GoogleMaps DistanceMatrixApi - google-distancematrix-api

There is a glitch in the GoogleMaps DistanceMatrixApi.
For the origin pin code B3H and destination pin code B3J with Travel Mode = DRIVING, the distance returned from the GoogleMaps DistanceMatrixApi is null.
There are also some other cases when the origin pin code R4G and destination pin codes in (R3J , R2J, R3W, R3M) with Travel Mode = DRIVING ,the distance returned from GoogleMaps DistanceMatrixApi is null.

I have send the request according to your requirement and it is giving me result
also travel mode is driving by default for distance matrix api, By default, directions are calculated as driving directions.
https://maps.googleapis.com/maps/api/distancematrix/json?origins=B3H&destinations=B3J&mode=driving&key=YOUR_API_KEY

Related

Camera direction lacks vertical data

I can't find a way to get the actual camera direction neither in first person mode nor in third person: the vertical element of the data is missing, it's just constantly shows zero. I'v tried to get the camera data using PhysicsCast.instance.getRayFromCamera() and also by Camera.instance.rotation
None of them work. Also I found an older project, this one
https://github.com/NoahWarnke/DCLBlocks and within the new decentraland version it also doesn't work as it's supposed to be working. Is there a way to get the actual camera direction, pointer direction in the new Decentraland version?

Projecting negative coordinates inside display area

I am testing the RandomWaypointMobility with a constrained area minX=-3000m, maxX=3000m, minY=-3000m and maxY=3000m. The #displaystrings sets bgp=6000,6000. The result is that nodes in the negative part of the coordinate system are rendered outside the display/canvas area.
Are there some parameters I can use to tell OMNeT++/INET that origo for the coordinate system is at the center of the display/canvas? I have tried
*.visualizer.sceneVisualizer.sceneMaxX = 3000m
*.visualizer.sceneVisualizer.sceneMinX = -3000m
*.visualizer.sceneVisualizer.sceneMaxY = 3000m
*.visualizer.sceneVisualizer.sceneMinY = -3000m
*.visualizer.sceneVisualizer.sceneMaxZ = 3000m
*.visualizer.sceneVisualizer.sceneMinZ = -3000m
but it doesn't work as I hoped for.
I realize that for RandomWaypointMobility I can just use a constrained area with positive coordinates only, which would keep objects within the canvas. However, my next task is to pull in mobility traces that include negative coordinates. Do I need to manually shift all coordinates so they become positive and stay within the canvas/display, or is there a smarter way of doing things?
Any hints appreciated!
Thanks,
Dragos
What you set is in fact bgb=6000,6000 which sets the size of the module. There were indeed plans to add a tag called bgp directly into OMNeT++ which would introduce an offset, but at the end it was not implemented. The reason is that once you go down into that rabbit hole, you want to implement also scaling and then rotation etc. So the default display string based visualization left as simple as possible and all these transformation stuff was left for the model code.
So indeed, SceneCanvasVisualizer in INET has a viewScale and viewTranslation parameter that can be used for these purposes.

Can't match coordinates of NWD and POTREE on Forge Viewer

I'm testing the example https://github.com/petrbroz/forge-potree-demo trying to import a NWD and point cloud into the Forge Viewer but can't make them match the coordinates.
I confirmed on Navisworks that both PC and model are aligned at 0,0,0. But they are displaced more than 200' in the Viewer.
What we did tried
Point cloud was converter using Potree converted 1.6 and 1.7 https://github.com/potree/PotreeConverter/releases/tag/1.7
The point cloud is scaled from meters to feet using let scale = new THREE.Vector3(3.28084,3.28084,3.28084);.
The models are being inserted with a global offset of 0,0,0. globalOffset: {x:0,y:0,z:0}
We created a sphere at a know point directly in Threejs using coordinates in foots and it matches the location on the NWD.
We found that potree converter is not 100% compatible with the sample, a quick fix is needed on the line 464 to read categories created by the converter.
var pointAttributeName = pointAttributes[i].name.toUpperCase().replaceAll(' ','_');
Also we needed to add a new category around line 434
PointAttribute.RGBA = new PointAttribute(PointAttributeNames.COLOR_PACKED, PointAttributeTypes.DATA_TYPE_INT8, 4);
Without those two latest fixes we can't load the point cloud.
What are we missing?
We can override the location by hand but the final coordinates doesn't make sense with the project. Too arbitrary. Could the two fixes be the problem? What should be an alternative?
We found the problem, potree was using a bounding box based on absolute units from the actual point cloud bounding box.
This makes sense if you want the point cloud to be on the center of the scene. But not at our case.
So, if you override this feature by changing potree.js bounding box set from
boundingBox.min.sub(offset);
boundingBox.max.sub(offset);
tightBoundingBox.min.sub(offset);
tightBoundingBox.max.sub(offset);
to
tightBoundingBox.min.sub(offset);
tightBoundingBox.max.sub(offset);
boundingBox.copy(tightBoundingBox);
the point cloud will align with the model.
FYI: The fixes we made where actually making us able to run potree converter 1.7 instead of 1.6 as specified in the demo readme.

Vertical takeoff for a DJI Matrice 100

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.

DJI SDK Android - unwanted yaw motion on GoToAction in time line mission

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.

Resources