search

octarobotics / lci-rmf-adapter

RMF Lift and Door Adapter for LCI
MIT License
3 stars 1 forks source link

[Question] regarding destination_floor format in `lci_rmf_adapter` #1

Closed h-wata closed 1 month ago

h-wata commented 1 month ago

Thank you for the great project.

I have a question regarding the format of destination_floor in the code found here: https://github.com/octarobotics/lci-rmf-adapter/blob/dd2c45c78f9a4e37db250e67177df7e52de87364/lci_rmf_adapter/lci_rmf_adapter/lci_rmf_adapter.py#L282-L283

Currently, the destination_floor is specified as <origination>:<destination>, but OpenRMF's rmf_lift_supervisor sends it in the format of <destination>.

Should we modify the way destination_floor is specified? Is there a standard method in OpenRMF to handle this, or should we adjust the code to match either format?

For example, it is /adapter_lift_requests in my case,

---
lift_name: /lci/XXXXXXX/m/1
request_time:
  sec: 1721635460
  nanosec: 521667595
session_id: fleet_name/robot_name
request_type: 1
destination_floor: 27F
door_state: 2

Thanks for your help.

MikhailBertrand commented 1 month ago

@nabeshima 以下のような手順での簡易的な対策をしようとしていますが、想定されている利用方法と異なりますか？

  1. まず各ロボットごとに、自身の現在フロア（current_floor_id）を管理される何かしらの仕組みを用意する
  2. RMF Coreから/adapter_lift_requestsトピックが/adapter_lift_requests_destinationトピックとして吐かれるようにremapする
  3. /adapter_lift_requests_destinationトピックを受け取って内容をcurrent_floor_idと統合して/adapter_lift_requestsトピックとして投げてlci_rmf_adapterに渡すノードを用意する

We're considering a simple countermeasure with the following steps. Does this differ from the intended usage?

  1. First, for each robot, prepare some mechanism to manage its current floor (current_floor_id).
  2. Remap the /adapter_lift_requests topic from RMF Core to be emitted as the /adapter_lift_requests_destination topic.
  3. Prepare a node that receives the /adapter_lift_requests_destination topic, integrates its contents with current_floor_id, and then sends it out as the /adapter_lift_requests topic to be passed to lci_rmf_adapter.
nabeshima commented 1 month ago

@h-wata Thank you for your comment.

To support some backends API provided by lift vendors, the both origination and destination are required for each single session.

If RFM do not need to support them, it is easy to follow the original LiftRequest format. In this case,

Because I don't know the limitation of the RMF Core, I implemented the format as this code.

If you come up with any idea to solve it, please tell me!

nabeshima commented 1 month ago

@MikhailBertrand

RMF Coreから出てくる最初の LiftRequest.destination は、current_floor_id（origination; 出発階） を指しているのだと思うのですが、いかがでしょうか？

特定のエレベーター会社のバックエンドを使う場合、この段階で行先階の情報が必要なため、 そもそも LiftRequest の仕様を解決しない限り難しいのかもしれません。

当座、RMF Coreをそのまま使う場合は、そのようなエレベーターは利用できない、と制約を設けてしまうのも手ではあります。

: で区切られていない場合は、

という実装は可能ですので。

ご意見頂けると幸いです。

nabeshima commented 1 month ago

lci-rmf-adapter now accepts the default format of LiftRequest.destination of RMF Core.

Nevertheless, to use a lift whose backend API requires both of origination and destination at the 1st request, the "<origination>":"<destination>" format is still needed.

2

MikhailBertrand commented 1 month ago

RMF Coreから出てくる最初の LiftRequest.destination は、current_floor_id（origination; 出発階） を指しているのだと思うのですが、いかがでしょうか？

そうでしたね。では

Nevertheless, to use a lift whose backend API requires both of origination and destination at the 1st request, the "":"" format is still needed.

を踏まえて、現在利用しているエレベーターについては呼び出し時に目的階も必要となるので、目的階を別で見ておく必要があるということですね。

1をどう実現するか未定ですが、RMF Coreは変更せず、以下のように修正した内容を実現できないか試してみたいと思います。

  1. まず各ロボットごとに、ELV乗降車の際の目的階ID（destination_floor_id）を管理される何かしらの仕組みを用意する
  2. RMF Coreから/adapter_lift_requestsトピックが/adapter_lift_requests_destinationトピックとして吐かれるようにremapする
  3. /adapter_lift_requests_destinationトピックを受け取って内容をcurrent_floor_idと統合して/adapter_lift_requestsトピックとして投げてlci_rmf_adapterに渡すノードを用意する
nabeshima commented 1 month ago

@MikhailBertrand ご検討有難うございます。 まずはそのやり方をお試し頂ければ助かります。

h-wata commented 1 month ago

試したところまで情報共有します。 結果としては、乗車まではうまく行くのですが、降車ができておりません。

やったこと

lci_rmf_adapter周りのLogを添付いたします。参考になれば幸いです。 Logの内容としては、27F:29Fはうまく行っているのですが、29F:29Fでつまずいております。 log2.txt

nabeshima commented 1 month ago

情報共有有難うございます。

RMFの標準的な呼び方としてはELVの待機位置にて現在階、ELV内にて目的階を呼び出すためdestination_floorは、下記のようになっているのが気になっています。 ELV前 -> : ELV内 -> :

こちらについては、LCIとしては受け付けていますので、問題はないかと思います。

問題は、

また、Logからもわかりますが、ELV待機位置につくとOpenRMFからadapter_lift_requestsが定期的（1Hz)に連続して投げています。そのたびにlci_clientからPublishが起きているようなのですがこれは抑止したほうが良いのでしょうか？

こちらです。 弊社でもログを確認していたのですが、エレベーターが呼び出し階に到着する前に、RobotStatusの乗車完了と2回目のCallElevatorが呼ばれており、首を捻っておりました。

RMFからは、LiftRequest を 1秒間隔で送ってくるのですね…

今のlci-rmf-adapterの実装では、「出発階への呼び出し時」と、「乗車後の行先階の登録時」の2回のみ、LiftRequestが来ることを想定していました。

この1Hzのrequestを受け入れるとすると、 LiftRequestに情報がほとんどなく、乗車完了を推定する方法があまりないので、 LiftRequest.destination が変化したときを、「乗車後の行先階の登録時」と判定するほか無さそうです。

つまり、LiftRequest.destination は、

ELV前 -> <origination> 
ELV内 -> <destination>（!= <origination>）

または、

ELV前 -> <origination> : <destination>
ELV内 -> <destination>

である必要があります。

こちら、対応しようと思います。

ELV前 -> <origination> : <destination>
ELV内 -> <destination> : <destination>

でも、正しく動作するようにします。

lci_rmf_adapterがSubscribeするのはlift_requestsでは無いのでしょうか？adapter_lift_requestsはlift_supervisorがSubscribeしてlift_requestsをPublishするのでは無いでしょうか？

こちらですが、 https://osrf.github.io/ros2multirobotbook/integration_lifts.html を参照して決めました。

adapter_lift_requests は以下のように説明されています。

Requests to be sent to the lift adapter/supervisor to request safe operation of lifts

lci-rmf-adapterは、複数のリフトとドア、複数のクライアント（LiftRequest, DoorRequestのpublisher）を扱っているため、 adapter_lift_requests をSubscribeするようにしています。

nabeshima commented 1 month ago

3 で、1Hzで送られるLiftRequest に対応しました。

lift_statesのcurrent_floorが変わらない。 ELV内での呼び出しが不自然になっているため、完了されないのかcurrent_floorが変更されません。ただしdoor_stateはCloseからOpenに変更されます

LCI のバックエンドによっては、current_floorが、出発階または目的階にエレベーターが到着して、ドアが開ききったタイミングで、ようやく更新されるものがありますので、その影響かと思います。

h-wata commented 1 month ago

早速のご回答およびご対応ありがとうございます。再度試してみます。

またTopic名についても承知しました。理解が深まりました。

h-wata commented 1 month ago

おかげさまでエレベータの乗降できました。 本件Closeさせていただきます。