search

ntnu-arl / colpred_nmpc

This repository contains the software and data for the ICRA2023 submitted article "NMPC for Deep Neural Network-Based Collision Avoidance exploiting Depth Images"
17 stars 1 forks source link

Question on control and simulation sampling times/rates #2

Closed CheeGY closed 4 months ago

CheeGY commented 4 months ago

Thanks again for sharing this repository, the weights and the data!

I have two questions regarding some of the parameters in the config file, ros_params.yaml.

  1. It is given that N, which is the number of steps in the prediction horizon, is 10, and T, the length of horizon, is 3s. The control_loop_time is given as 20ms or 0.02s. According to Acados, T = N*sampling_time. Shouldn't this control_loop_time be the sampling_time? If not, what sampling time/rate should the control loop, i.e., the nmpc module, be running at?

  2. If I use a simulator that is independent of ROS, what sampling time/rate should I run this simulator so that it is compatible with the nmpc module?

sedith commented 4 months ago

Hi,

  1. The control_loop_time parameter is the minimum control period, ie the minimum control period at which the nmpc solver will be called. I.e., the main control loop will pause if the solving time is faster than this. If it's slower, it won't pause, but the resulting control frequency will decrease (hence the minimum). The sampling time T/N does not necessarily need to match the control time, since we apply the system inputs in a receding horizon fashion, that is, the first input computed by the nmpc is applied and the solver is called again to produce the next input to be applied, etc. This is a common control scheme in particular with RTI MPC where we don't let the solver fully converge to a solution.
  2. The simulation rate could be selected to match the actual control time (ie, control_loop_time). However, it is common for simulator to run faster than that, by applying the last computed inputs to the system until a new one is computed by the mpc controller (this is what happens in ROS/Gazebo).
CheeGY commented 4 months ago

Hi, thanks for the prompt reply!

Thanks for your answer to 2 - that makes sense.

For 1., the answer you gave provides an interesting and unusual perspective. I don't think any of the examples given in the acados repository (https://github.com/acados/acados/tree/master/examples/) use a sampling time T/N that differs from the control loop time (let me know if you find any).

In this configuration, since T/N=3/10=0.3s, it would mean that the dynamics within the optimization problem, $\mathbf{x}_{k+1} = \mathbf{f}(\mathbf{x}_k,\,\mathbf{u}_k)$, (Eq. (12c) in the paper) have been propagated for 0.3s for each of the time steps in the prediction horizon, i.e., $\forall\, k \in \{0,N-1\}$, when finding a solution for the optimization problem. Although I'm using the word "propagated", what's actually being done is a multiple shooting approach. Nonetheless, the predicted dynamics at each time step would be consistent with a set of dynamics that are 0.3s into the future, starting from the previous time step.

Hence, upon solving the optimization problem, the first control input obtained, i.e., $\mathbf{u}_0^{\star}$ , would then be applicable for a set of predicted dynamics that is 0.3s into the future. If the dynamics within the optimization problem matches the true system dynamics, then this control input $\mathbf{u}_0^{\star}$ would not be consistent with the true system dynamics at this point in time, as it will either be over-compensating and under-compensating for the true system, since the state measurements are obtained at a control_loop_time=0.02, and not 0.3s.

This above description about control inputs being not consistent with the true dynamics is not related to the fact that whether (i) a receding horizon approach is used, or (ii) the solver/approach SQP-RTI is used. The same thing can be said if the optimization problem is formulated and solved only once, and/or if you used a different solver, e.g., SQP or an interior-point method.

The receding horizon approach may provide some robustness in the context of such inconsistencies, but I think it definitely makes more sense to get control inputs that are consistent, and it is difficult to imagine any use cases in which one would proceed otherwise.

Would like to hear if you have any follow-up thoughts on this. Thanks!

sedith commented 4 months ago

If the modeled dynamics match the true system dynamics, applying u0* from state x0 for T/N secs would bring the system to state x1. If a new state becomes x0' available after t < T/N, I don't see what prevents you for re-planning a new control input (which should be close to u0* if t is small). This has to do with RTI because you only compute a suboptimal input u0 ~ u0* and will in general not end in the predicted state anyway, thus high-frequency replanning adds robustness to the system, by updating the initial state and refining the previous solution used as warm start. While having a longer sampling time allows for maintaining a longer horizon with a low number of shooting nodes, thus a low solving time. If anything, this would likely render the system more conservative, but would not create inconsistencies. The "cleaner" way would likely be to use a non-uniform sampling time, but I haven't looked into this.