The old app has always been like this, Custom without a linked POI is a transition, Custom with linked POI = POI. We will rename the mode to Custom/POI.
Would it be possible to display the Photo Interval for Mapping Missions?
When creating mapping missions, the Front Overlap only affects the interval between photos. It would be helpful to know the calculated interval, in order to NOT try to take photos faster than the drone and SD card can store them.
For example: My Mavic 2 Pro can store images every 2.5 seconds apart with a quality card.
It would be helpful to know just how far to ‘push’ the Front Overlap percentage without losing any images. By displaying the calculated Photo Interval, users could fine-tune the Front Overlap easier and maximize coverage.
I’m guessing the information to calculate it is already available for missions. Distance between Photo capture points and the speed chosen by the pilot.
It’s already a front overlap vs flight speed calc. It will tell you when you are exceeding your cameras capabilities based on your model. I set the overlaps I want, dial the speed up until I get the warning and then back it off a couple of digits. If you set your camera to interval rather than auto it will tell you when you adjust your frontlap.
Of course you are correct. However, the new hub explicitly lists “Point of Interest” and “Custom” for newer drones. Someone who is unaware my incorrectly think there is no POI heading option for older drones.
FEATURE REQUEST: Import polygon for mapping area as JSON or SHP
I’m working on helping small NGO’s in Ghana monitor deforestation from the Global Forest Watch Forest Watcher app - it allows you to see recent deforestation events and then draw a polygon of an area to investigate, but only exports as a .csv, JSON, or SHP format. It would be very handy to not have to convert to KML in QGIS or using an online tool. This should be a pretty easy functionality to add. Let me know if I can help!
The JSON format is made up of key/value pairs where the keys (and values) can be anything you want. As a result, the keys would have to be specified. It would make sense to use an array of hashes where two of the hash values were “longitude” and “latitude”. However, I have no idea how the data might be arranged in a JSON export from your app. Litchi could specify an uploadable JSON format but there is little chance that it would happen to match what your app exports.
Shapefiles are somewhat standardized. However, a shapefile is made up of three or more files (.shp, .shx, .dbf, .pro, etc.). Uploading a shapefile really involves uploading multiple files. While it could be done, this would only accommodate a very specific purpose, that many (most?) users would not use.
Hi Wes, Thanks for your response. I should have been more clear and said GeoJSON, which is very well standardized for spatial data, and arguably more widely used/supported than kml at this point being the standard format for most web mapping and api’s. In many ways it would be a superior format for this as it’s much smaller file sizes and Litchi doesn’t use any of the embedded styling and time series support that KML has. It would be easy enough for me to develop a conversion app to be used offline in the field, but I guarantee it would be useful to a wider audience.
Hi, thanks for the updates, Transform is a godsend!!
One thing that would make it even better: when rotating via Transform, the locked CameraRotate values should rotate with it.
Example: if one waypoint is at 90° and another at 120°, and I rotate the whole path by +10°, those values should become 100° and 130°.
So basically the locked direction rotates together with the path.
That way I could reuse my paths much better. Before this update I had to redraw everything, now I still have to reset all the rotation values manually.
So yeah, would be a really nice improvement. Thanks again
Issue: When simulating a mission that contains multiple waypoints and POIs, the drone’s heading always progresses in the clockwise/positive direction as it transitions from one waypoint/POI combination to the next waypoint/POI combination.
Expected behavior: During a simulation, as the drone transitions from one waypoint/POI combination to the next waypoint/POI combination, the drone’s heading should always interpolate in the shorter of the two possible rotational directions as the drone actually does when flying the mission.
Here is a simple mission that demonstrates the error. Click on “Simulation”. Note that this is most easily observed in the normal 2D view.
Curiously, if the Mini 5 Pro drone is selected, the simulation is displayed properly.
Yes, it is working for me today too. Yesterday I was working on a larger mission and I know what I saw. I was also able to recreate the problem with that smaller mission too. I tried changing a number of things. It wasn’t until I changed to a Mini 5 Pro drone that the rotations began to occur in the expected direction. I’ll have to do more testing to see if I can repeat it again.
I am able to reproduce the problem I described yesterday. Evidently, the act of sharing the mission eliminates the problem. Also, if I re-open the mission, the problem is eliminated. So, here are the steps to reproduce the problem and a screen recording: