Skip to main content

context.drone: Access to more nested properties



  • Jim McAndrew

    Those values aren't saved in the camera type right now because we are trying to keep the data foot print low:

    Having said that, even if we had them, the function is only running once at the start so you would just be getting a snapshot of the values (not continuously updating during the mission plan).

  • Rob Hunter

    Hi Jim,

    Thanks for the response. I understand your aim to keep the footprint small.

    Yep, I'd assumed that, if it were available, it would be just the state at mission plan time. That would have been fine for my purposes.

    The application is a function that generates a 360 sphere pano plan on the fly with user defined bracketing steps, from a dynamic input, around a fixed exposure. As DJI limits AEB to such a small value, and I want to be using far wider brackets, I'm setting my manual exposure settings before running the function (a visual scan with the drone camera to find the highest and lowest and picking something in between). Bracketing is achieved by indexing up and down the CameraShutterSpeed enum to get the shutter speed (e.g. index +/- 4 items to get a +/- 1.3EV bracket) although, given the enum covers all DJI shutter speeds, I have to use a filtered list of shutter speed values based on what the M2P has available.

    That's why the one off read of shutter speed at function run time is fine - I only need it once to populate the entire plan with 26 standard, 26 over-exposed and 26 under-exposed photos.

    (Supplemental question/thought - a filtered list/enum in the context containing only the available values for those enums would be useful (e.g. just listing M2P shutter speeds) and make the function generic across models, but obviously at the expense of footprint. Checks and balances.

    I'd looked at the ExposureCompensationCameraCommand with AE Lock in aperture priority but, apart from a worry that the drone will interpret the request by changing ISO instead of shutter speed in certain lighting conditions, it seems that AE Lock is turned off by the drone once exposure compensation is applied in this manner (my assumption is that that is an SDK/DJI "feature"). Then, when swivelling to a new pitch/heading, new exposure values are metered, which isn't what I want to do.

    At the end of the day I just read the shutter speed from the display and select it from a list as a dynamic input. Slower, possibly prone to error, but it works.

    If footprint were not a worry, and a plan framework supported embedding a function as a "live" component, it would be very cool to embed a function that metered various headings/pitches, established a best guess exposure, set that as the manual exposure and then passed the "ideal" shutter speed to the plan generating part of the function, which would generate the rest of the plan on the fly. But I expect that is probably at least a couple of epics and would really have footprint implications :-) 

    I'm not ignorant of the fact that Dronelink does a great job and will try and find creative ways of doing what I want, but a man can dream! So please keep up the great work.

  • Jim McAndrew

    What would you like to see added? Just ISO, Aperture, and Shutter speed?

    Have you tried using ExposureCompensationStepCameraCommand?

  • Rob Hunter

    wrt Exposure compensation, via DJI Go4 I placed the drone in Aperture Priority exposure mode and enabled AE Lock. I then altered the exposure compensation and AE Lock became disabled at the first adjustment. I also write a quick plan ( that did roughly the same thing and AE Lock became disabled after the first Camera Exposure Compensation command. Based on that it seemed AE lock was not a viable route and that it's a DJI/SDK issue, nothing to do with Dronelink, as the problem is repeatable in Go4.

    Via Go4 I placed the drone in Manual exposure mode and then attempted to alter exposure compensation. That isn't available in Manual exposure mode, just changing shutter/aperture/ISO is avaialable. So I've assumed that this is also a DJI feature and the SDK will carry the same limitation in that ExposureCompensationStepCameraCommand won't work in this scenario either.

    Hence going with the index up and down the available shutter values.

    If it was purely for my own selfish needs, shutter speed would be a must, aperture and ISO a like. But my instinct would be that it should be a complete implementation (reflecting Auto ISO enabled, exposure compensation applied, AE Lock state etc., which is starting to creep the scope) and not a partial one so ultimately I'd say I respect Dronelink's ideology wrt footprint vs functionality as this isn't a show stopper for me. I can still enter the shutter speed value as a dynamic input rather than retrieving it via the context. I'm willing to bet you have many competing feature requests which place additional demands on memory/cpu/bandwidth and you're in a better position to judge what would be a worthy spend than me, but thanks for taking this seriously! I also suspect you'd really like to be developing for a controller platform with unlimited compute resource as the level of control and functionality you could offer within this framework would be incredible.


Please sign in to leave a comment.