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

Update st transition bugs #1102

Merged
merged 2 commits into from
Mar 6, 2017

Conversation

snozawa
Copy link
Contributor

@snozawa snozawa commented Mar 6, 2017

#1098
のSTがきれないバグを修正しました。
直し方は
#1098 (comment)
で、STのモード遷移を行ったスレッドかどうかに関わらず遷移をwaitするようにしました。

よろしくお願いします。

…f whether the client program is mode changer or not (fkanehiro#1098)
…DE_IDLE=>MODE_ST) because the coordinates for ref_cog differs among st algorithms.
@snozawa
Copy link
Contributor Author

snozawa commented Mar 6, 2017

また、issueとは別にref_cogvelが遷移開始時にとんでしまうバグがあったので直しました。

@k-okada
Copy link
Contributor

k-okada commented Mar 6, 2017

Refer to this link for build results (access rights to CI server needed):
http://jenkins.jsk.imi.i.u-tokyo.ac.jp:8080/job/hrpsys-qnx/2783/
Test PASSed.

@fkanehiro fkanehiro merged commit 231c0bf into fkanehiro:master Mar 6, 2017
@snozawa snozawa deleted the update_st_transition_bugs branch March 6, 2017 14:15
Copy link
Contributor

@YoheiKakiuchi YoheiKakiuchi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

マージされちゃいましたが、waitはif文の前でないと効果が無いように思います。

Guard guard(m_mutex);
if ( transition_count == 0 && (control_mode == MODE_ST || control_mode == MODE_AIR) ) {
std::cerr << "[" << m_profile.instance_name << "] " << "Stop ST" << std::endl;
control_mode = MODE_SYNC_TO_IDLE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

これだと、transition != 0 のときに、やはりstopされないと思うのだけどもどうだろうか?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waitはできるので問題ないと思うのですが、僕がそもそも問題を勘違いしてますか?
再現コードが2端末にわかれるのでかきにくいですが
start-stされてる状態で

  • 端末1
(send *ri* :stop-st)

を実行してすかさず(遷移時間である2秒いない)

  • 端末2
(send *ri* :stop-st)

をすると、

  • このPR前:端末2のstop-stがSTが止まるのをwaitせずにすぐreturnしてしまう
  • このPR後:ちゃんとwaitしてくれる

となります(テスト自体はpythonのコードでためしました)

上記ようなものが問題だと思ってましたが違うでしょうか。
再現コードを教えてください。

@YoheiKakiuchi
Copy link
Contributor

問題は、2回目のstop-stではなくて、airへの遷移で起こっていて、
この時は、1回目のstop-stの時から、説明されている2回目のstop-stと同じように何もせずに返って来てしまう。

違うのは、airへの遷移の場合、stop-stが一回も有効になっていないのでstが切れないこと。
この、PRで即座に帰ってくることがなくなったので、連続2回送ると必ず切れるようになってはいると思います。

以下、テストコードです。

(progn
(print 'start-st)
(send *ri* :start-st)
(print (send *ri* :get-st-controller-mode))

(print 'go-to-air)
(send *ri* :set-st-param :contact-decision-threshold 10000)
(unix::usleep (* 100 1000))

(print 'stop-st)
(send *ri* :stop-st)

(dotimes (i 14)
 (print (send *ri* :get-st-controller-mode))
 (unix::usleep (* 500 1000)))

;;(print 'stop-st2)
;;(send *ri* :stop-st) ;; stop-st can work here

(print 'go-to-ground)
(send *ri* :set-st-param :contact-decision-threshold 50)
(unix::usleep (* 100 1000))

(dotimes (i 14)
 (print (send *ri* :get-st-controller-mode))
 (unix::usleep (* 500 1000)))
)

snozawa added a commit to snozawa/hrpsys-base that referenced this pull request Mar 7, 2017
@snozawa
Copy link
Contributor Author

snozawa commented Mar 7, 2017

ありがとうございます、ようやくじょうきょうがわかりました。

snozawa added a commit to snozawa/hrpsys-base that referenced this pull request Mar 7, 2017
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

Successfully merging this pull request may close these issues.

4 participants