Changing tilt of aircraft

[notsolowki]

What is it going to take to achieve such a thing. im not sure that the mobile SDK will be able to accomplish this task. I'm sitting here looking at a binary with ida and have no clue what to do.

[notsolowki]

so then were are these real values stored at in the first place?

[mefistotelis]

In the place referenced by the 2nd pointer in ExportParam struct, ofc.

[notsolowki]

i just tested some of the followme and waypoint parameters it had no effect. updated both the app and the flight controller, with and without the android. if there was no phone plugged into the controller then it must be getting the parameters from the drone. do you think it might store them on the controller. because i just don't see how if in the firmware the variables are changed than why arnt they responding.

[notsolowki]

yesterday for testing i set the max height to 5000 meters, today i set it to 9999 in both phone and drone. the phone lets me choose between 20-9999 but when 9999 is entered it reverts back to 5000...

[notsolowki]

this looks promising?!?

.text:0808300C flt_808300C DCFS 0.017453 ; DATA XREF: .text:loc_8082C12r .text:08083010 flt_8083010 DCFS 6.2832 ; DATA XREF: sub_8082C70+4r .text:08083014 flt_8083014 DCFS 60.0 ; DATA XREF: sub_8082C70+Cr .text:08083014 ; sub_8082D54+24r .text:08083018 flt_8083018 DCFS 100.0 ; DATA XREF: sub_8082CAC+12r .text:08083018 ; sub_8082D54+34r .text:0808301C flt_808301C DCFS 0.0 ; DATA XREF: sub_8082D54+Cr .text:0808301C ; sub_8082E7C:loc_8082F9 .text:08083020 flt_8083020 DCFS 40.0 ; DATA XREF: sub_8082D54+1C .text:08083024 flt_8083024 DCFS 80.0 ; DATA XREF: sub_8082D54+2Cr .text:08083028 aWFLiftF DCB "w: %f, lift: %f",0 ; DATA XREF: sub_8082D54+8Ao .text:08083038 off_8083038 DCD dword_20001678 ; DATA XREF: sub_8082DFEr .text:08083038 ; .text:08082E74r .text:0808303C off_808303C DCD unk_2000314C ; DATA XREF: sub_8082E3Er .text:0808303C ; sub_8082E42+2r ... .text:08083040 flt_8083040 DCFS 0.0016667 ; DATA XREF: sub_8082E42+C .text:08083044 dbl_8083044 DCFD 0.0174532925 ; DATA XREF: sub_8082E7C+1A .text:0808304C dbl_808304C DCFD 3.14159265 ; DATA XREF: sub_8082E7C+8C .text:08083054 aCraftConfigura DCB "craft configuration motor coef",0xD,0xA,0 .text:08083054 ; DATA XREF: sub_8082FDC+C .text:08083075 DCB 0, 0, 0

[ferraript]

BudWalker's DatCon (DAT logs reader) has option to generate Config Log File it contains information about what values are assigned to all those params (regarding specific flight) I think it could help you when testing the changes of params

[notsolowki]

heres an example of what the inside of the generated config file looks like

11973 : [ 7.000000] => wp_setting.vel_cmd_range_0 11985 : [ 2.000000] => wp_setting.idle_vel_0 11997 : [ 4] => wp_setting.action_on_finish_0 12009 : [ 2] => wp_setting.mission_exec_num_0 12021 : [ 0] => wp_setting.yaw_mode_0 12034 : [ 1] => wp_setting.trace_mode_0 12045 : [ 0] => wp_setting.action_on_rc_lost_0 12057 : [ 536993992] => range.control.control_mode[0] 12069 : [ 536993992] => range.control.control_mode[1] 12081 : [ 536993992] => range.control.control_mode[2] 12093 : [ 536993992] => range.go_home.standby 12105 : [ 536993992] => range.go_home.start 12117 : [ 536993992] => range.ioc.mode[0] 12129 : [ 536993992] => range.ioc.mode[1] 12141 : [ 536993992] => range.ioc.mode[2] 12154 : [ 100.000000] => g_config.bat_limit.limit_delt_vol.min_0 12165 : [ 800.000000] => g_config.bat_limit.limit_delt_vol.max_0 12177 : [ 0.500000] => g_config.bat_limit.limit_delt_vol.weight_0 12189 : [ 3400.000000] => g_config.bat_limit.limit_vol.min_0 12201 : [ 3800.000000] => g_config.bat_limit.limit_vol.max_0 12213 : [ 1.500000] => g_config.bat_limit.limit_vol.weight_0 12225 : [ 200.000000] => g_config.bat_limit.limit_max_power.min_0 12237 : [ 350.000000] => g_config.bat_limit.limit_max_power.max_0 12249 : [ 1.500000] => g_config.bat_limit.limit_max_power.weight_0 12261 : [ -10.000000] => g_config.bat_limit.limit_temp.min_0 12274 : [ 20.000000] => g_config.bat_limit.limit_temp.max_0 12285 : [ 0.500000] => g_config.bat_limit.limit_temp.weight_0 12297 : [ 0.400000] => g_config.bat_limit.limit_scale.min_0 12309 : [ 2.200000] => g_config.bat_limit.limit_scale.max_0 12321 : [ 1.000000] => g_config.bat_limit.limit_scale.weight_0 12333 : [ 10.000000] => g_config.bat_limit.limit_power_rate_capacity.min_0 12345 : [ 100.000000] => g_config.bat_limit.limit_power_rate_capacity.max_0 12357 : [ 30.000000] => g_config.bat_limit.limit_power_rate_capacity.weight_0 12369 : [ -10.000000] => g_config.bat_limit.limit_power_rate_temp.min_0 12381 : [ 20.000000] => g_config.bat_limit.limit_power_rate_temp.max_0 12394 : [ 20.000000] => g_config.bat_limit.limit_power_rate_temp.weight_0 12405 : [ 35000.000000] => g_config.bat_limit.limit_bat_current_after_overflow_0 12417 : [ 0.500000] => g_config.bat_limit.limit_up_rate_0 12429 : [ 0.100000] => g_config.bat_limit.limit_down_rate_0

[notsolowki]

@mefistotelis did you have a look at ? .text:08083028 aWFLiftF DCB "w: %f, lift: %f",0 ; DATA XREF: sub_8082D54+8Ao. text:08083054 aCraftConfigura DCB "craft configuration motor coef",0xD,0xA,0 and has anyone had any successful attempts modifying the flights geometry ?

[mefistotelis]

@notsolowki such string may help in understanding what the function which uses it does, and what local variables mean. I'm not really interested in that right now.

[notsolowki]

what is it that your interested in. what can be done about the flight geometry. i mean it all boils down to prop speed. maybe you could write a tool to pull every string and their variables from the binary even the unknown ones? i dont mind testing/frying my esc's and im not afraid of catastrophic failures.

[mefistotelis]

As I said before, to get further with these parameters we need a custom mobile app. The way of reading parameters suggested by @ferraript reads only selected variables, and we need a way of reading all of them, plus writing new values.

We could also check why modifying defaults not always affects the real values of parameters. Maybe there is a copy of these defaults within the firmware code. To check that, we'd have to select a parameter which behaves like the default does not affect it (ie. the battery warning param) and look at all functions which affect its value in IDA.

[notsolowki]

why would we need a custom mobile app. is it because its the only thing that can read the parameters. but then how would we know to tell it to read something that we dont know? i noticed inside the litchi app "classes3.dex theres a folder called flyc that contains alot of files.

[notsolowki]

looking in the mobile sdk, sub catagory flight controller. i came across this

DJIFlightControllerDataType.DJIVirtualStickFlightCoordinateSystem An enum class representing flight control coordinate system. DJIFlightControllerDataType.DJIVirtualStickRollPitchControlMode Defines how manual roll and pitch values are interpreted by the aircraft. DJIFlightControllerDataType.DJIVirtualStickVerticalControlMode Defines how vertical control values are interpreted by the aircraft. DJIFlightControllerDataType.DJIVirtualStickYawControlMode Defines how manual yaw values are interpreted by the aircraft.

https://developer.dji.com/iframe/mobile-sdk-doc/android/reference/dji/sdk/FlightController/package-summary.html

https://developer.dji.com/iframe/mobile-sdk-doc/android/reference/dji/sdk/flightcontroller/DJIFlightController.html

public abstract void getRemoteControllerFlightModeMappingWithCompletion (DJICompletionCallbackWith<DJIFlightControllerRemoteControllerFlightMode[]> callback)

Gets the mapping between the flight modes and the flight mode switch positions on the remote controller. Elements 0, 1 and 2 of the returning array to DJIRemoteControllerFlightModeSwitchPosition.One, DJIRemoteControllerFlightModeSwitchPosition.Two and DJIRemoteControllerFlightModeSwitchPosition.Three of the flightModeSwitch in DJIRCHardwareState. The value of each Enum item is representing the corresponding index of the DJIFlightControllerRemoteControllerFlightMode array representing the flight mode. The mapping is fixed for Phantom series, Inspire series, Mavic Pro and the M100. For N3, A3, Matrice 600, and Matrice 600 Pro the mapping is firmware dependent. With firmware version 3.2.11.0 or above, the mapping can be customized in DJI Assistant 2. Parameters callback Completion callback that receives the getter result. Each element of array is an instance with a value of DJIFlightControllerRemoteControllerFlightMode.

[mefistotelis]

Looking at the SDK might definitely help in understanding values of some parameters. For the specific APIs used for getting/setting them, they're most likely internal and not documented in these docs.

The interfaces are DJIFlycParamInfoManager (to read) and DataFlycSetParams (to write).

[mefistotelis]

how would we know to tell it to read something that we dont know?

There is no another set of hidden parameters. We already found the internal interface and all parameters in it. There likely are similar lists for camera/vps/ofdm boards, but that's it.

[notsolowki]

Maybe you can clear this up for me. If i flash the drone with the modded variables and dont connect the phone at any point then how can it still go by some other parameters. Im confused because if it didnt know to assced at 5 because i set it to 10, then how would 5 be an option in the first place?

[notsolowki]

To me it seems there 2 possibilities

1. The "real" parameters are somewhere else in the binary
2. The controllers firmware stores a copy of the parameters

[notsolowki]

this is from the console output from the drone

▒▒dfilter_rc_input_roll, butterworth first order▒-U7▒ ▒▒d --fc: 10.000000 hz, delay: 15.915494 ms▒▒U= ▒▒dfilter_rc_inp ut_pitch, butterworth first orderSU7▒ ▒▒d --fc: 10.000000 hz, delay: 15.915494 ms ▒▒U;▒ ▒▒dfilter_rc_input_yaw, butterworth first order2▒U7▒ ▒▒d --fc: 10.000000 hz, delay: 15.915494 ms▒▒U@! ▒▒dfilter_rc_input_throttle, butterworth first orde ▒▒dfitler-linear_acc, butterworth 2nd order$U7▒ ▒▒d --f c: 15.000000 hz, delay: 15.003007 ms׽U▒ ▒▒dmotor init coef0TUI▒ ▒▒d0 roll:-0.70710 7 pitch:0.707107 yaw:1.000000 lift:1.000000▒▒UI▒ ▒▒d1 roll:0.707107 pitch:0.70710 7 yaw:-1.000000 lift:1.000000'▒UI▒ ▒▒d2 roll:0.707107 pitch:-0.707107 yaw:1.00000 0 lift:1.000000▒▒UK ▒▒d3 roll:-0.707107 pitch:-0.707107 yaw:-1.000000 lift:1.0000 00IU/c ▒▒dcraft configuration motor coef ▒kUI▒ ▒▒d0 roll:-0.707107 pitch:0.707107 yaw:0.000000 lift:1.000000dsUI▒ ▒▒d1 roll :0.707107 pitch:0.707107 yaw:-0.000000 lift:1.000000▒;UI▒ ▒▒d2 roll:0.707UHW ▒▒d7 roll:0.000000 pitch:0.000000 yaw:0.000000 lift:0.000000U.▒ ▒▒dcraft configuration ccpm coef ▒QUI▒ ▒▒d0 roll:-0.353553 pitch:0.353553 yaw:0.000000 lift:0.250000▒OUI▒ ▒▒d1 roll :0.353553 pitch:0.353553 yaw:-0.000000 lift:0.250000▒CUI▒ ▒▒d2 roll:0.353553 pitc h:-0.353553 yaw:0.000000 lift:0.2500003JUK ▒▒d3 roll:-0.353553 pitch:-0.353553 ya w:-0.000000 lift:0.250000▒▒UHW ▒▒d4 roll:0.000000 pitch:0.000000 yaw:0.000000 lif t:0.000000▒UHW ▒▒d5 roll:0.000000U,6 ▒▒iw: 198.975159, lift: 0.356320▒cU,6 ▒▒iw: 38 5.479095, lift: 1.337347n{U,6 ▒▒iw: 561.598694, lift: 2.838538▒▒U,6 ▒▒iw: 728.8967 90, lift: 4.7816159GU,6 ▒▒iw: 888.579285, lift: 7.106159▒▒U5h

[mefistotelis]

Maybe you can clear this up for me. If i flash the drone with the modded variables and dont connect the phone at any point then how can it still go by some other parameters.

I think the conclusion is very simple. The drone must have the settings stored somewhere.

Im confused because if it didnt know to assced at 5 because i set it to 10, then how would 5 be an option in the first place?

If by "it" you mean defaultValue which is ignored - it also suggests that settings are stored somewhere on the drone. Existence of "defaultValue" parameter also suggests that there is some function to restore the parameters to defaults.

The "real" parameters are somewhere else in the binary

This is true before the "in the binary" part. We're only changing limits and defaults. Real parameters are set during startup (in the places pointed by 2nd pointer, as I mentioned before).

The controllers firmware stores a copy of the parameters

Possible, but firmware might not be the only place where something can be stored.

I hope you now understand how a mobile app would solve these problems.

[notsolowki]

Address Function Instruction

---

.text:08079764 sub_80796C6 ADR R1, aFilter_motor_p ; "filter_motor_pwm, butterworth first ord"... .text:080756FE sub_807563A ADR R1, aFilter_rc_in_0 ; "filter_rc_input_pitch, butterworth firs"... .text:08075754 sub_807563A ADR R1, aFilter_rc_in_1 ; "filter_rc_input_yaw, butterworth first "... .text:080757AA sub_807563A ADR R1, aFilter_rc_in_2 ; "filter_rc_input_throttle, butterworth f"... .text:080756A8 sub_807563A ADR R1, aFilter_rc_inpu ; "filter_rc_input_roll, butterworth first"... .text:08027E7E sub8027E2E ADR R1, aFitlerAngular ; "fitler-angular_vel, butterworth 2nd ord"... .text:08027FBC sub_8027E2E ADR R1, aFitlerLinear_a ; "fitler-linear_acc, butterworth 2nd orde"... .text:080A21E0 sub_80A2158 ADR R2, aFilter_rc_in_3 ; "filter_rc_input_roll, butterworth first"... .text:080A22BC sub_80A2158 ADR R2, aFilter_rc_in_4 ; "filter_rc_input_pitch, butterworth firs"... .text:080A232C sub_80A2158 ADR R2, aFilter_rc_in_5 ; "filter_rc_input_yaw, butterworth first "... .text:080A239C sub_80A2158 ADR R2, aFilter_rc_in_6 ; "filter_rc_input_throttle, butterworth f"... .text:08079A68 sub_8079978 aFilter_motor_p DCB "filter_motor_pwm, butterworth first order",0
.text:08075950 sub_80757E8 aFilter_rc_in_0 DCB "filter_rc_input_pitch, butterworth first order",0
.text:08075980 sub_80757E8 aFilter_rc_in_1 DCB "filter_rc_input_yaw, butterworth first order",0
.text:080759B0 sub_80757E8 aFilter_rc_in_2 DCB "filter_rc_input_throttle, butterworth first order",0
.text:080A2258 sub_80A2158 aFilter_rc_in_3 DCB "filter_rc_input_roll, butterworth first order",0
.text:080A26B0 sub_80A25F2 aFilter_rc_in_4 DCB "filter_rc_input_pitch, butterworth first order",0
.text:080A26E0 sub_80A25F2 aFilter_rc_in_5 DCB "filter_rc_input_yaw, butterworth first order",0
.text:080A2710 sub_80A25F2 aFilter_rc_in_6 DCB "filter_rc_input_throttle, butterworth first order",0
.text:08075904 sub_80757E8 aFilter_rc_inpu DCB "filter_rc_input_roll, butterworth first order",0
.text:08028170 sub802811C aFitlerAngular DCB "fitler-angular_vel, butterworth 2nd order",0
.text:08028224 sub_802811C aFitlerLinear_a DCB "fitler-linear_acc, butterworth 2nd order",0

[notsolowki]

the butterworth appears to be a frequency thats sent to the PWM controllers..

[mefistotelis]

butterworth is a kind of signal filtering function. see here.

[notsolowki]

when you said second pointer in exportparam i was looking at pt2 of flyc_param structure? excuse my assembly knowledge

[notsolowki]

the only place i can think that the settings could be store is the handheld controller right? i mean if you take the mobile app out of the picture entirely then how does it have effect??

[mefistotelis]

pointer, not point.

The ExportParam struct starts with 2 pointers; I mean the second.

[notsolowki]

can you use this to show me what you mean i would really like you to show me what you mean please. thankyou .data:080A6900 flyc_params ExportParam <aCfg_vartable, cfg_var_table_size, 4, 2, <0.0, 4.295e9,\ .data:080A6900 0.0>, <0, 4294967295, 0>, <0, 4294967295, 0>, 0, 0> .data:080A6900 ExportParam <aGlobal_status, global__status, 0x10, 0xA, <0>, <0>, <0>,\ .data:080A6900 0, 0> .data:080A6900 ExportParam <aFix_send_index, fix_send_index, 2, 1, <0.0, 32767.0, \ .data:080A6900 0.0>, <0, 32767, 0>, <0, 32767, 0>, 1, 0>

[mefistotelis]

the only place i can think that the settings could be store is the handheld controller right?

Every chip in the drone can be an additional storage space. But the simplest way to store such data would be to use a part of the firmware storage space which is not updated with the firmware. The question is - do we really care where it is?

can you use this to show me what you mean

Sure: cfg_var_table_size, global__status and fix_send_index.

[notsolowki]

yes we care right? i mean after all its the main configuration of the flight settings.

could you explain this a little further | global__status and fix_send_index. |

why are there so many fix_send_index what is their purpose. do you mean do we care as in modify them fanother way or as in you dont want to modify them at all? i seen this in flyc_param and change it but it did not effect the output from the console

i am most interested in this [smart_battery]this fireware calc gohme speed:7.800000 - land speed:2.500000

[mefistotelis]

yes we care right?

It would be nice, but I don't see much gain in that. We want to read and write them, and there already is a mobile interface for this.

could you explain this a little further

I don't know what the parameters mean. It would be easier to figure out if we could read their values - again, mobile interface.

[notsolowki]

okay now i understand the the modle app has direct access to these parameters, and could be possibly modified for the new parameters. but surely there has to be a away to address them at an instruction level. i mean dont get me wrong if i could develop apps i would be on it right away. maybe you can take whats already compiled and make it suitable for our needs.

[notsolowki]

can you help me change this

.text:08068FA6 ADR R0, aBatteryResetDe ; "[BATTERY]:reset default smart cfg - L1:"... .text:08068FA8 BL printf_sub_806E08A .text:08068FAC VLDR D0, =2.5 .text:08068FB0 LDR R0, =aSmart_batteryT ; "[smart_battery]this fireware calc gohme"... .text:08068FB2 VSTR D0, [SP,#0x10+var_10] .text:08068FB6 VLDR D0, =7.80000019 .text:08068FBA VMOV R2, R3, D0 .text:08068FBE BL printf_sub_806E08A

and does this mean anything to you ▒ 155 CTRL reset all by rc mode switch▒U= ▒ 155 [Ctrl<1>] REQ_RC_NORM AL ATTI ctrl_atti▒U0▒ ▒ 162 Eeprom write offset:1d0 &U-▒

[mefistotelis]

Everything is possible, but not everything is worth the effort. If you feel like doing that by modifying binary code, then sure, you can.

First you have to find a place where you want to inject the code, then a place where you can put your new instructions, then put the new commands in place.

[notsolowki]

you are the firmware wizard. i know this is something you could do in 20 minutes. just think when you 5000 ft away on a windy day and your rth is just sitting there fighting against the wind you would want to at least turn it up a little bit. i am going to assume that 7.8 is in mps i would like to change it to 14.80000019

[mefistotelis]

Having knowledge doesn't make anything effortless.

I'm not interested in such solution.

[notsolowki]

well do you have any ideas how to get a custom app? i imagine it would take a long time to develop. i wonder if the only the API could be developed for modifying or would it have to be the whole fpv and all

[mefistotelis]

DJI provides tutorials on how to use their API. I think the best way to start is to follow one of these tutorials.

[notsolowki]

Is this whats of intrest?

Applications using the DJI Mobile SDK can communicate with DJI Onboard SDK applications deployed on the aircraft over the Lightbridge wireless communication link. The DJI Mobile SDK gives developers the ability to detect if an Onboard SDK application is connected to the flight controller, and both send and receive data to it. The size of the data cannot be greater than 100 bytes, and will be sent in 40 byte increments every 14ms.

[notsolowki]

And

The above diagram shows the aircraft from the side. Pitch measures an object's rotation about the lateral (Y, pitch) axis. Adjusting the pitch will tilt the aircraft forwards or backwards. To pitch forward, the back propellors spin faster and have more thrust than the front propellors. The flight controller automatically balances the thrust on each propellor and so the DJI Mobile SDK simply provides APIs to adjust the velocity along the X axis, or the pitch angle and throttle.

[mefistotelis]

Which specific demo you will select doesn't make much difference, as long as it uses "dji-sdk.jar". The demo which I looked at to learn that there is such interface was Panorama Demo.

[notsolowki]

Okay, but do we have any thoughts about how it handles the parameters when the mobile isnt present?

[mefistotelis]

We know nothing besides what we've previously established. Why are you asking?

[notsolowki]

Because id just like to set a static value within the fw. Id like to know where its default values are so i can change a few of them. The rth speed is catostrophicly slow. And it wouldnt hurt to have a tad bit more pitch. I dobt know how to bytepatch the fw to change the 7.8 rth speed

[notsolowki]

I think everyone could benifit from a script to patch the rth speed, and maybe even the thrust,pitch. I bet theres room for a 10-15 percent increase

[notsolowki]

and have you been able to define more of the binary?

[mefistotelis]

No, I didn't worked much on the flight controller firmware.

[notsolowki]

whats of interest to you

[mefistotelis]

I'm now focusing on RC firmware, looking for the tx power control code.

Flight controller config would be nice to tweak, but I don't really need it.

[notsolowki]

hey thats a good idea too. is your drone fcc or ce

[mefistotelis]

The drone detects region automatically; I'm not even sure which sticker is on it. It should be possible to increase the power output beyond both FCC and CE. I'm not sure what the exact limit is, but I'd say it's very likely that the transmitter supports 300 or even 500 mW.

[notsolowki]

i guess im going to try to use an sdk and try to get teh camera to display, i guess thats step one. but i notice that the panorama demo uses 2.1.1 and they ahave a new 3.1.1. which one do you think would be best to start with?