Embedded Files
4/6
1. Cite our ICUAS 19 paper.
2. Check the references.
3. Revise Fig. 9(c).
4/2
1. proofread Sec. 3 & 4.
3/30
1. Revise the paper.
3/26
1. revise the two algorithms.
3/23
1. Revise the paper.
3/12
1. Revise the paper.
2. Read the new paper. Try to find the major differences between their and our papers.
3/9
1. revise the paper.
3/6
1. revise the paper.
3/2
1. Revise the proof of Proposition 1.
2. Revise the paper.
2/26
1. revise the paper.
2/23
1. reconstruct the paper following Prof. Duan's idea.
2/19
1. (UTAustin paper) FInd out how they did the simulation (Matlab?) and Field Demonstration
2. (UTAustin paper) Conclude the differences between our paper and UTAustin paper and send them to Profs. Dong and Duan
2/16
1. read the UTAustin paper.
2/12
1. revise the paper.
2/9
1. use previous data for table 3,4,5
2. For pDPM simulation, add some noise to the drone's real position information.
2/5
1. revise the paper.
2/2
1. proofread the whole paper.
2. improve the simulation code.
1/26
1. For Table 4,5,9,10. Run the simulation again with setting CD=100 m.
2. Fix the issues of fig 9,10.
1/22
1. add some content about countermeasures in the conclusion section.
2. discuss two papers (acsac19, CCS18_control_invariants) in the related wrok section.
3. revise the system model.
1/19
1. revise the two feasible scope figs: a): connect the dots for each scope b): remove the caption; enlarge the size of the legend.
2. decrease the font size of the tables in the evaluation section.
3. add more explanation for each table and fig in the evaluation section.
4. relocate the first paragraph of Section V - A
5. merge the two evaluation sections.
12/29
We deepened our understanding of why we should set the constant term of the Injection rate I =C^I+V^I*k in practical DPM as -\frac{CD}{n\cdot K^{attack,pr}} \cdot \frac{K^{attack,pr}}{K^{attack,id}} = -\frac{V^{r}_{drift}}{K^{attack,id}}. In fact, this is the same situation as the Ideal DPM case. We want a constant difference between GPS and EKF position, which can result in a drift velocity V^{r}_{drift}, so the difference should be \frac{V^{r}_{drift}}{K^{attack,id}}. If we add this constant term at the starting of the attacking cycle, the attack will enter the stable state instantly.
Next step:
1. run the simulations for practical DPM.
12/22
We have figured out how to prepare the Injection rate I =C^I+V^I*k, where C^I= V^I * K^attack_prac/K^attack_ideal. Here the C^I is optional for I; however, if there is no C^I in I, it will take several seconds for the attack to enter the stable state. During the process of stabilization, the distance between GPS and EKF position will gradually increase to V_drift * K^attack_ideal =V^I * K^attack_prac/K^attack_ideal, then stabilize at this value. In the case that we add the C^I= V^I * K^attack_prac/K^attack_ideal to I, at the starting attack cycle, the distance between GPS and EKF position will be V^I * K^attack_prac/K^attack_ideal, and the attack has entered the stable state instantly. In this case, the drift distance will be proportional to V^I*k.
Next step:
1. revise the practical DPM section accordingly.
2. Plot two figures that trace the real position & EKF postion for ideal and practical DPMs
3. run more simulations to validate the above explanations.
12/11
I have finished the code for practical DPM and got some simulation results. The results show a little different from the theoretical analysis; we can outline them as: V_drift= K_attack*V_I+ C. Here C is a constant that we did not include in the theoretical analysis, and its size is related to V_I.
12/08
Finish the simulation code for practical DPM.
12/01
I just solved the issue of east drift when we attack north or south. By investigation, I find the problem lies in the GPS reading adjustment part: previously we prepare the same adjustment for the two directions (inc_metres = -float(math.sqrt(velocity_n*velocity_n+velocity_n*velocity_n)/ freq)), which is not working for all size of adjustment. Now I choose to deal with it separately (inc_metres_north = -0.914*vehicle.velocity[0]/ freq ; inc_metres_east = -1.05*vehicle.velocity[1]/ freq). With the proper adjustment for the two directions, the simulation error can be very small. I have verify the new code for different attack directions and get very good results for all. I also create another code for north track direction, and get similar results.
9/21
I put my comments on revision of the paper in the folder named attackingDroneControl - Wenxin . Please check it.
9/17
1. Think about how to write the section of Case 2.
2. Why K_1 keeps unchanged during the flight? A):Kalman Gain is unchanged B); Waypoint navigation algorithm
3. Factor that may affect the value of K_1: A): GPS pos accuracy
9/14
1. Log the data:
https://sites.google.com/a/hawaii.edu/uh-uas-projects/research/2020-spring-sensor-attacks/wnexin-s-progress/how-to-log-data
2. New findings: injection upper bounds are determined by GPS pos accuracy and P matrix. We can increase the injection upper bounds by enlarging the GPS pos accuracy. In this case, however, K will decrease. How to get the largest drift speed by choosing the appropriate GPS pos accuracy will be an interesting problem.
3. Attack west, Injection rate = 2.5 m/cycle, 400cycles:
Atttack west, Injection rate = 2.5 m/cycle, 4000cycles:
9/4
EKF-based estimated position over time (GPS:10HZ)
attack west, 400 cycles
attack west, 4000 cycles
no attack, 4000 cycles
EKF-based estimated position over time (GPS:20HZ)
attack west, 400 cycles
attack west, 4000 cycles
04/21
To Do:
1. Print the values of pos/vel Kalman gain
2. show both drift velocities are proportional to the size of the position injection rate.
3. show in case B: getting GPS position from SIMPOS, the difference between the GPS measurement and position estimation (innovation) will converge to 0, and the difference between the simpos and EKF position will converge to a constant.
Future work
1. Case A 2): why The SIMSTATE velocity Vsim is not necessarily related to the position injection rate ∆, but the GPS velocity VGPS is determined by the position injection rate.
2. Develop an attack algorithm for Case B.
3. If we can predict or measure the coefficients K1 and K2, and track a drone’s actual position (simpos) real-time, maybe we do not need to access the state of a drone’s navigation system. In this case, our work will be more practical.
4. Why kalman gain will converge?
Problems:
1. The rates of GPS and EKF are different. We apply an injection on every GPS cycle, but in every EKF cycle does every observation get an injection?
2. What will happen if we perform the attack in the middle of the flight?
04/14
Now that we have fixed the problem of the simpos, the next goal is to figure out a detailed algorithm of manipulating the GPS reading given the compromised destination. In paticular, the control loop of drone's navigation system is:
WPNav -> EKF based position estimation -> GPS, IMU measurements,
then what we need to do is to backtrace the GPS measurements based on the given compromised destination. We should consider the implementation details in the simulation, such as
1):different rate for GPS, EKF, and WPNav update
2):out of syne between GPS, EKF, and WPNav update
04/10
We tried to revised the attack code by getting the GPS velocity from the simstate. The default simstate message does not include the velocity information. Then we revised the simstate message sending function in SITL.cpp (see attached) such that it contains them. Next we pass the simstate velocity information to the GPS INPUT message in the attack code test_module_alt_0409.py (see attached) as follows (line 211 -219):
@vehicle.on_message('SIMSTATE')
def listener(self, name, message):
print(message)
global velocity_n
global velocity_e
global velocity_d
velocity_n = message.xacc
velocity_e = message.yacc
velocity_d = message.zacc
Under this setting, we run the attack code. In particular, we can see that the simpos and EKF-based position estimation are close. However, the difference between them (position_wenxin_diff in the console) increases over time. I blame this increasing differences to the delay of GPS location information: the location information here comes from the EKF-based position estimation in last cycle (0.1s ago). To fix the delay problem, we estimate the GPS location in the current time with the code (line 189)
inc_metres = float(math.sqrt(velocity_n*velocity_n+velocity_e*velocity_e)/ freq)
However, under this setting, we can see that the difference between the simpos and EKF-based position estimation increases more rapidly (approximately 2X). Then In the third try, rather than reducing the delay, I increase the delay to 0.2s by the following code(line 189)
:
inc_metres = - float(math.sqrt(velocity_n*velocity_n+velocity_e*velocity_e)/ freq)
Now we can see the simpos and EKF-based position estimation are very close, and the difference between them does not change too much.
04/07
1. continue to trace 1. simstate 2. AP_InertialSensor_SITL 3. IMU data for EKF
2.Try to send GPS from SIMSTATE
04/03
1. Try to figure out where the IMU readings for EKF come from.
2. Create another simpos variable that is calculated based on EKF velocity, and see what happens to 1): itself 2): EKF-based position estimation.
03/31
There seem to be some issues about the source of the EKF velocity:
we use to get the EKF velocity from outputDataDelayed.velocity of the function NavEKF2_core::calcOutputStates(), but it leads to incorrect result. After discussion, we believe the EKF velocity should come from the stateStruct.velocity of function NavEKF2_core::StoreOutputReset() or NavEKF2_core::UpdateStrapdownEquationsNED() , or vel of function NavEKF2::getVelNED in the file AP_NavEKF2.cpp. We will try them next.
++++++++++++++++++++++++++++++++++++++
updates:
I have successfully passed the EKF velocities to the sim velocities via a third party variable. However, the behavior of the simstate and EKF estimation is strange.. I am trying to figure it out. Please replace the code with the attached files to see it. You can locate the revised part by searching "wenxin" in the code.
libraries\AP_NavEKF2\ AP_NavEKF2_core.cpp
libraries\AP_NavEKF2\ AP_NavEKF2_core.h
libraries\SITL\SIM_Aircraft.cpp
ArduCopter\Copter.cpp
03/13
We currently trace how the simpos is calculated. The following is what we know for now:
1. sim_aircraft.cpp/Aircraft::update_dynamics
position <- velocity_ef <-accel_earth<-rot_accel, accel_body
2. sim_muilticopter.cpp/MultiCopter::calculate_forces
rot_accel, accel_body<- input
3. SITL_STATE.cpp/SITL_State::_simulator_servos
input<-pwm_output
4. AP_motorsmulticopter.cpp/AP_MotorsMulticopter::output_to_pwm
pwm_output <- actuator
5. AP_motorsmatrix.cpp/AP_MotorsMatrix::output_to_motors
_actuator <-_thrust_rpyt_out (set_actuator_with_slew(_actuator[i], thrust_to_actuator(_thrust_rpyt_out[i])))
6. AP_motorsmatrix.cpp/AP_MotorsMatrix::output_armed_stabilizing
_thrust_rpyt_out <-roll_thrust, pitch_thrust, yaw_thrust,throttle_thrust_best_rpy+ thr_adj , rpy_scale<- _roll_in, _pitch_in, _yaw_in, compensation_gain, throttle_thrust , rpy_scale
7.1 AP_motorsmatrix.cpp/AP_MotorsMatrix::output_armed_stabilizing, AP_motorsmulticopter.cpp/AP_MotorsMulticopter::get_compensation_gain,
AP_motorsmulticopter.cpp/AP_MotorsMulticopter::update_lift_max_from_batt_voltage
compensation_gain< - get_compensation_gain() <- _lift_max <- batt_voltage_filt*(1-thrust_curve_expo) + thrust_curve_expo*batt_voltage_filt*batt_voltage_filt; (to be continued)
7.2 AP_motorsmatrix.cpp/AP_MotorsMatrix::output_armed_stabilizing, AP_motors_class.h, LowPassFilter.cpp
throttle_thrust <- get_throttle() <- _throttle_filter.get() (to be continued)
7.3 AP_motorsmatrix.cpp/AP_MotorsMatrix::output_armed_stabilizing
rpy_scale (to be continued)
7.4 AP_motorsmatrix.cpp/AP_MotorsMatrix::output_armed_stabilizing
_roll_in, _pitch_in, _yaw_in (to be continued)
02/28
In my latest code below, I limit the velocity_n and velocity_e up to 2.7 m/s (with the preset airspeed =4 m/s). In addition, I set the three parameters ( AP_GROUPINFO("GPS_HDG", 43, SITL, gps_hdg_enabled, 1), AP_GROUPINFO("DRIFT_TIME", 6, SITL, drift_time, 0) , AP_GROUPINFO("GPS_TYPE", 12, SITL, gps_type, SITL::GPS_TYPE_NMEA), ) in the SITL.cpp. Now we can hardly see the heading drift under this setting. In addition, we found the heading drift is related to the velocity_n and velocity_e. The GPS heading actually calculated based on them. If we choose not to limit the velocity sent in the GPS Input message, the heading drift will occur. However, the simstate's position still drifts. Next, we will try to read the velocity information from the simstate and send them via GPS INPUT message.
Page updated
Report abuse