Possible integration with Drone Sky Check

[iz0qwm]

#Proposal: integration with Drone Sky Check

Hi Arpan,

my name is Raffaello and I am the developer of Drone Sky Check, an Italian platform focused on UAS operational awareness, airspace information, NOTAMs, weather data and flight planning.

I am currently developing a new Pilot Workspace that will allow users to manage their pilot profile, operational locations and drone fleet.

While looking for a good open-source solution for flight-log and fleet management, I discovered Open DroneLog. I was very impressed by the project, particularly its local-first approach, flight-log analysis, battery monitoring, maintenance tracking and REST API.

I would be interested in exploring a possible integration between Drone Sky Check and Open DroneLog.

The initial idea would be to keep the two projects independent:

• Drone Sky Check would manage the pilot profile, drone fleet, operational planning and airspace context.
• Open DroneLog would manage flight-log import, telemetry analysis, batteries, statistics and maintenance.
• Drone Sky Check could retrieve summary information from a user’s Open DroneLog instance through its REST API and link flights to aircraft using their serial numbers.
• Detailed flight analysis would remain within Open DroneLog.

A future integration could also allow users to display a historical flight track inside Drone Sky Check and compare it with geographical and aeronautical information.

I noticed that Open DroneLog already provides REST endpoints such as /api/flights, /api/flight_data, /api/overview and /api/import.

Before experimenting further, I wanted to ask:

1. Are these REST endpoints intended to be used by third-party applications?
2. Do you expect the current API structure to remain reasonably stable?
3. Would you be interested in supporting an official integration with Drone Sky Check?
4. Could a dedicated API-token authentication mechanism be considered for server-to-server or external application access?
5. Is there an integration approach you would prefer, such as REST API access, plugins, deep links or another mechanism?

This is still an exploratory idea, and I would be happy to discuss the architecture and contribute changes upstream if they fit the project’s direction.

Drone Sky Check:

• https://droneskycheck.it/
• https://droneskycheck.it/api-overview
• https://docs.droneskycheck.it/

Thank you for creating and sharing Open DroneLog.

Best regards,
Raffaello Di Martino
Drone Sky Check

[arpanghosh8453]

Hey @iz0qwm, Thank you for opening this discussion thread.

1. Are these REST endpoints intended to be used by third-party applications?
For the Docker route, the react front end and rust back end works independently and they can indeed be used once you obtain the authentication token and refresh it periodically for the TTL. the token is verified server side with the TTL. as long as the auth token is valid, the request will go through and return the expected results as you might have seen already.

2. Do you expect the current API structure to remain reasonably stable?
I would say I consider the current releases stable and as long as you stay within the major versions, if I don't make a mistake, they will be at least backward compatible. very few changes were made in the API without backward compatibility so far, so you can rely on that if you want.

3. Would you be interested in supporting an official integration with Drone Sky Check?
I think it depends on you if you want to integrate your application with the mechanisms of ODL. As an open source enthusiast, I always appreciate 3rd-party integrations, but I don't think there is something I need to add on my end for this as we follow the open source standard access (like REST API) already. Let me know if there needs to be more discussions on this.

4. Could a dedicated API-token authentication mechanism be considered for server-to-server or external application access?
you may need to add allowed request sources to the nginx config to strengthen the access rules of your ODL server instance, but currently it accepts request from any source regardless of the origin as long as it carries a valid access token header.

5. Is there an integration approach you would prefer, such as REST API access, plugins, deep links or another mechanism?
I would say the REST API is preferred and it's more commonly used, standardized and easy to debug in case of any disputes. But if you think something else is better, that is open to discussion.

[iz0qwm]

Hi Arpan,

Thank you very much for the detailed reply.

This is exactly the information I was hoping to get. Knowing that the REST API is considered stable and can be used by third-party applications gives me confidence to start experimenting with an integration.

My plan is to begin with a simple proof of concept inside Drone Sky Check, connecting to an Open DroneLog instance through the REST API and displaying flight and fleet information within the Pilot Workspace. If everything goes well, I'll gradually expand the integration and I'll be happy to share my experience and any feedback that could help improve interoperability.

I also appreciate your open-source philosophy. I agree that keeping both projects independent while communicating through standard REST APIs is the cleanest approach.

Of course, whenever I present this feature, I'll make it clear that the flight log analysis is powered by Open DroneLog. I'll also be happy to mention and recommend the project on the Drone Sky Check website, in the documentation, and through our social media channels (including Facebook), so users know about the excellent work you've done.

Thanks again for your time, and I'll keep you updated as the integration progresses.

Best regards,

Raffaello
Developer of Drone Sky Check

[arpanghosh8453]

@iz0qwm

This sounds great! Let me know if you ever hit any problem and I will be happy to provide more documentation on something if necessary. There are a few current open issues which are worth looking at which may limit some functionality (applies to commercial drones features mostly)