セル生産方式におけるロボットの活用には様々な問題があるが,その一つとして 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上でリアルタイムで動作します。
1. Shimadzu Business Systems
株式会社 島津ビジネスシステムズ 赤羽根 州晴
MySQL勉強会 in 大阪 #5 2013年11月7日
Copyright (c) Shimadzu Business Systems All Rights Reserved.
Redmine + MySQL
応答性能の調査結果と対策
~ 200万チケット、画面応答100ms/req
を想定したチューニング~
24. Shimadzu Business Systems
24
1. 応答性能低下の回避
・画面応答時間の基準とは?
参考文献
#1 Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
#2 Miller, R. B. (1968). Response time in man-computer conversational transactions.
http://theixdlibrary.com/pdf/Miller1968.pdf
100ms 直接操作している一体感
1000ms 遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
[*7]
25. Shimadzu Business Systems
25
1. 応答性能低下の回避
・画面応答時間の基準とは?
参考文献
#1 Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
#2 Miller, R. B. (1968). Response time in man-computer conversational transactions.
http://theixdlibrary.com/pdf/Miller1968.pdf
100ms 直接操作している一体感
1000ms 遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
ITSは「文房具」
[*7]
32. Shimadzu Business Systems
32
1. 応答性能低下の回避
対策③ 再処理回避
Server
Pass
enger
RAID
OS FS NW
Ruby
Rails
Redmine
DBMS
HTTP
Reverse
Proxy
Client
OS FS NW
Browser
JavaScript / DOM
33. Shimadzu Business Systems
33
1. 応答性能低下の回避
対策③ 再処理回避
Server
Pass
enger
RAID
OS FS NW
Ruby
Rails
Redmine
DBMS
HTTP
Reverse
Proxy
Client
OS FS NW
Browser
JavaScript / DOM
㋖㋖
㋖㋖
㋖
㋖
㋖
㋖
㋖
㋖
潤沢なメモリ
キャッシュ
34. Shimadzu Business Systems
34
1. 応答性能低下の回避
サーバー構成: 対象領域
Passenger4
OOBW
GC
RAID5
+20GB
OS CentOS6 (64bit)
Ruby 2.0.0
Rails3.2
Redmine2.3
DBMS
MySQL
5.6
HTTP
Apache
2.2
メモリ 4~16GBCPU 2~4コア
VMware (運用円滑化)
VCS
Subversion
1.7
HTTP
Reverse
Proxy
---
:5 Key Point
44. Shimadzu Business Systems
ITSの耐用検証(応答基準)
44
0 ms
300 ms
600 ms
900 ms
1,200 ms
6万 10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
※計測諸条件→巻末注記1
BP:4G
LogFile:1G
45. Shimadzu Business Systems
ITSの耐用検証(応答基準)
45
0 ms
300 ms
600 ms
900 ms
1,200 ms
6万 10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
全文検索 20秒
対策必須
DB始動時の
暖機運転5分
2012年末リリースの
MySQL 5.6に対策有り
(巻末注記2-1)
(BufferPool Dump/Restore)
BufferPool
4GBでの結果
→ 8GB必須
※計測諸条件→巻末注記1
47. Shimadzu Business Systems
ITSの耐用検証(応答基準)
47
0 ms
300 ms
600 ms
900 ms
1,200 ms
10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
※計測諸条件→巻末注記1
BP:8G
LogFile:2G
48. Shimadzu Business Systems
ITSの耐用検証(応答基準)
48
0 ms
300 ms
600 ms
900 ms
1,200 ms
10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
※計測諸条件→巻末注記1
全文検索 20秒
対策必須
DB始動時の
暖機運転1~3分
52. Shimadzu Business Systems
ITSの耐用検証(応答基準)
52
0 ms
1,250 ms
2,500 ms
3,750 ms
5,000 ms
10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
※計測諸条件→巻末注記1
起動直後
BP Load:無
53. Shimadzu Business Systems
ITSの耐用検証(応答基準)
53
0 ms
1,250 ms
2,500 ms
3,750 ms
5,000 ms
10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
※計測諸条件→巻末注記1
起動直後
BP Load:有
54. Shimadzu Business Systems
ITSの耐用検証(応答基準)
54
0 ms
1,250 ms
2,500 ms
3,750 ms
5,000 ms
10万 20万 30万 50万 70万 100万 150万 200万
Issue C
Issue B
Issue A
Ticket List
PJ Top
PJ List
ITS Top
※計測諸条件→巻末注記1
起動直後
BP Load:有
2. 暖機運転の時間短縮
200万チケットの時は暖機運転に
かなりの時間が必要だった。
MySQL5.6のBufferPool
Dump&Load機能により、有効なペー
ジキャッシュが短時間で回復していると
確認できた。
63. Shimadzu Business Systems
63
0
60
120
180
240
300
ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C
Ruby1.9.3
Ruby2.0.0 OOBW-GC
※計測諸条件→巻末注記1
3.その他対策
今回の計測環境
200万チケット、主要画面7種
結果
Ruby2.0.0 + Passenger4 OOBW-
GCは、Ruby1.9.3 + Passenger4
に対し、画面6種において平均8.5%の
応答速度向上を確認した。
65. Shimadzu Business Systems
65
0
100
200
300
400
500
ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C
Redmine 1.4
Redmine 2.0Tuned
Redmine 2.1Tuned
Redmine 2.3Tuned
※計測諸条件→巻末注記1
10万チケット
Redmine
各バージョンの比較
3.その他対策