セル生産方式におけるロボットの活用には様々な問題があるが,その一つとして 3 体以上の物体の組み立てが挙げられる.一般に,複数物体を同時に組み立てる際は,対象の部品をそれぞれロボットアームまたは治具でそれぞれ独立に保持することで組み立てを遂行すると考えられる.ただし,この方法ではロボットアームや治具を部品数と同じ数だけ必要とし,部品数が多いほどコスト面や設置スペースの関係で無駄が多くなる.この課題に対して音𣷓らは組み立て対象物に働く接触力等の解析により,治具等で固定されていない対象物が組み立て作業中に運動しにくい状態となる条件を求めた.すなわち,環境中の非把持対象物のロバスト性を考慮して,組み立て作業条件を検討している.本研究ではこの方策に基づいて,複数物体の組み立て作業を単腕マニピュレータで実行することを目的とする.このとき,対象物のロバスト性を考慮することで,仮組状態の複数物体を同時に扱う手法を提案する.作業対象としてパイプジョイントの組み立てを挙げ,簡易な道具を用いることで単腕マニピュレータで複数物体を同時に把持できることを示す.さらに,作業成功率の向上のために RGB-D カメラを用いた物体の位置検出に基づくロボット制御及び動作計画を実装する.
This paper discusses assembly operations using a single manipulator and a parallel gripper to simultaneously
grasp multiple objects and hold the group of temporarily assembled objects. Multiple robots and jigs generally operate
assembly tasks by constraining the target objects mechanically or geometrically to prevent them from moving. It is
necessary to analyze the physical interaction between the objects for such constraints to achieve the tasks with a single
gripper. In this paper, we focus on assembling pipe joints as an example and discuss constraining the motion of the
objects. Our demonstration shows that a simple tool can facilitate holding multiple objects with a single gripper.
【DLゼミ】XFeat: Accelerated Features for Lightweight Image Matchingharmonylab
公開URL:https://arxiv.org/pdf/2404.19174
出典:Guilherme Potje, Felipe Cadar, Andre Araujo, Renato Martins, Erickson R. ascimento: XFeat: Accelerated Features for Lightweight Image Matching, Proceedings of the 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2023)
概要:リソース効率に優れた特徴点マッチングのための軽量なアーキテクチャ「XFeat(Accelerated Features)」を提案します。手法は、局所的な特徴点の検出、抽出、マッチングのための畳み込みニューラルネットワークの基本的な設計を再検討します。特に、リソースが限られたデバイス向けに迅速かつ堅牢なアルゴリズムが必要とされるため、解像度を可能な限り高く保ちながら、ネットワークのチャネル数を制限します。さらに、スパース下でのマッチングを選択できる設計となっており、ナビゲーションやARなどのアプリケーションに適しています。XFeatは、高速かつ同等以上の精度を実現し、一般的なラップトップのCPU上でリアルタイムで動作します。
13. トラフィックの負荷分散
GKE (k8s) の Service リソースを使う
Type は LoadBalancer を指定
● 外部 LB として、GCP の External TCP/UDP
Network Load Balancing が利用される
● Proxy はせず、送信元 IP アドレスが
維持される
● 送信元 IP とポートと、宛先 IP とポート、
プロトコルのハッシュに基づいて
バランシングを行う
External Traffic
14. Pod
kube-proxy(iptables)
Pod Pod Pod Pod Pod
NIC NIC NIC
① : External TCP/UDP Network Load
Balancing がトラフィックを受信
② : 宛先 IP / Port は変えずにNode の
いずれかにバランシングしつつ転送
③ : kube-proxy(iptables) に転送
④ : kube-proxy(iptables) から 青 Pod
のいずれかにバランシングしつつ転送
①
②
③
④
Nodes
:8080 :8080 :8080
トラフィックの負荷分散イメージ
34.69.XX.XX:80External TCP/UDP Network
Load Balancing
External Traffic
LB からの Health Check は
各ノードのkube-proxy の
/healthz に対して
TCP 10256 で行っている
iptables のバランシング
アルゴリズムはRandom
18. トラフィックの負荷分散イメージ
Pod
kube-proxy(iptables)
Pod Pod Pod Pod Pod
NIC NIC NIC
Health check は
各 NodePort 宛に
行われる
:50000 :50000
NodePort: *:30080
① : External HTTP(S) Load Balancing が
トラフィックを受信
② : Path 毎に指定されたService の NodePort
に転送
③ : NodePort から kube-proxy(iptables) へ
転送
④ : kube-proxy(iptables) から
各 Pod にバランシングして転送
②
③
④
NodePort: *:30180
:8080:8080:8080
kube-proxy(iptables)
Nodes
①
:50000
/* : “my-products” service
/discounted “my-discounted-products” service
External HTTP(S)
Load Balancing
External Traffic
34.69.XX.XX:443
iptables のバランシング
アルゴリズムはRandom
27. と を使った負荷分散イメージ
Pod Pod Pod Pod Pod Pod
NIC NIC NIC
:50000 :50000
① : External HTTP(S) Load Balancing が
トラフィックを受信
② : Path 毎に指定されたService の Pod に
直接転送
②
:8080:8080:8080
Nodes
①
:50000
35.244.**.**
/* : “my-products” service
/discounted “my-discounted-products” service
External Traffic
Health check は
各 Endpoint ( Pod ) の
target port に
対して行われる
External HTTP(S)
Load Balancing
37. コントロールプレーンはGoogle 管理
Istio の各コントローラは
Google の Proprietary に置き換え
● Istio Pilot >> Traffic Director
● Istio Citadel >> Mesh CA
● Istio Mixer >> Managed backends
概要 External Traffic
Traffic Director
Config to
Envoys
(xDSv2 APIs)
TLS certs to
Envoys
Telemetry
Mesh CA
HTTP, gRPC, TCP
mTLS
Managed
backends
GA BetaAlpha
Anthos GKE Single Cluster
Data Plane
Control Plane managed by Google
App A
Envoy
App B
Envoy
51. Pod
kube-proxy(iptables)
Pod Pod Pod Pod Pod
NIC NIC NIC
① : Internal TCP/UDP Load Balancing が
VPC内のホストからトラフィックを受信
② : Node のいずれかに宛先IP/Port は
変えずにバランシングしつつ転送
③ : kube-proxy(iptables) に転送
④ : kube-proxy(iptables) から青 Pod の
いずれかにバランシングしつつ転送
①
②
③
④
Nodes
:8080 :8080 :8080
トラフィックのイメージ
192.168.2.14:80Internal TCP/UDP
Load Balancing
Internal Traffic
LB からの Health Check は
各ノードのkube-proxy の
/healthz に対して
TCP 10256 で行っている
iptables のバランシング
アルゴリズムはRandom
56. トラフィックの負荷分散イメージ
Pod Pod Pod Pod Pod Pod
NIC NIC NIC
:50000 :50000
① : Internal HTTP(S) Load Balancing が
トラフィックを受信
② : Path 毎に指定されたService の Pod に
直接転送
②
:8080:8080:8080 :50000
10.254..**.**
/* : “my-products” service
/discounted “my-discounted-products” service
Health check は
各 Endpoint ( Pod ) の
target port に
対して行われる
Internal HTTP(S)
Load Balancing
Internal Traffic