Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why there are two clamping function for control limits? #3

Closed
brilianputraa opened this issue Dec 13, 2023 · 4 comments
Closed

Why there are two clamping function for control limits? #3

brilianputraa opened this issue Dec 13, 2023 · 4 comments

Comments

@brilianputraa
Copy link

Hello, and thank you for making this amazing work available on GitHub.

I have a question regarding to the clamping of control inputs in the #mppi.py and also #barebone_mppi_numba.ipynb notebook

I understand from the paper of MPPI usually they clamp the control sequence before it passes through the dynamics, which is in the mppi.py code file, it is inside the #rollout_numba function

v_noisy = max(vrange_d[0], min(vrange_d[1], v_nom))
w_noisy = max(wrange_d[0], min(wrange_d[1], w_nom))

My confusion is why there is another clamping function again after we weight the control sequence inside of the #update_useq_numba function?,

# Blocks crop the control together
tgap = int(math.ceil(timesteps / num_threads))
starti = min(tid*tgap, timesteps)
endi = min(starti+tgap, timesteps)
for ti in range(starti, endi):
u_cur_d[ti, 0] = max(vrange_d[0], min(vrange_d[1], u_cur_d[ti, 0]))
u_cur_d[ti, 1] = max(wrange_d[0], min(wrange_d[1], u_cur_d[ti, 1]))

Isn't it enough to just clamp it inside the rollout function?, I am looking forward to hearing from you Thank you

@xiaoyi-cai-acl
Copy link
Collaborator

xiaoyi-cai-acl commented Dec 13, 2023

Hi @brilianputraa :

  • In the rollout_numba function, we crop the perturbed control sequence because we want the state rollouts to be consistent with the bounded control.
  • If you look at this code segment we crop again because the update to the current best control u_cur_d is based on the unmodified Gaussian noise values. Therefore, there is no guarantee that the updated control will satisfy the control bound without cropping again.

An alternative approach is probably to keep track of how each sampled Gaussian noise gets cropped and do a weighted sum of the cropped Gaussian noise directly, but I did not do that and I wasn't sure if one would see much performance difference

Hope this helps.

@brilianputraa
Copy link
Author

brilianputraa commented Dec 13, 2023

Thank you for your explanation @xiaoyi-cai-acl, I got it now. My other question is, if we add that kind of clamping function for the control rate (lets say angular velocity rate and linear velocity rate (acceleration)) as well in the u_cur_d does it affects the optimality of the control sequence?

@xiaoyi-cai-acl
Copy link
Collaborator

@brilianputraa I am not sure if the optimality is preserved due to clipping. Perhaps the simplest sanity check is to run MPPI on optimal controls problems with known solutions given bounded control inputs. Then see if the solution matches the optimal.

I do think it is an interesting direction to design an MPPI algorithm that has theoretical guarantees given control constraints (where the simplest one being the bounded norm).

@brilianputraa
Copy link
Author

@brilianputraa I am not sure if the optimality is preserved due to clipping. Perhaps the simplest sanity check is to run MPPI on optimal controls problems with known solutions given bounded control inputs. Then see if the solution matches the optimal.

I do think it is an interesting direction to design an MPPI algorithm that has theoretical guarantees given control constraints (where the simplest one being the bounded norm).

Okay I take your point, thank you for sharing your opinions on that. I will close the issues, thanks again for your detailed and super helpful answer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants