活用段階に入ったNoSQLですがまだまだ実際どう使えるのかご存じ無い方も多いのでは無いでしょうか。当セッションでは、MapR-DB(Hbase互換のNoSQL)が企業でどう活用されているのか、インドのマイナンバー事例や国内事例を元に実際の使い方のイメージと技術的な裏付けをご説明します。2015年6月10〜12日に開催されたdb tech showcase Tokyo 2015での講演資料です。
【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上でリアルタイムで動作します。
セル生産方式におけるロボットの活用には様々な問題があるが，その一つとして 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.
Traditional IT capacity planning, by the very nature of the logistics of acquiring hardware, installation, configuration and networking, has to take a forward looking view. Complex estimates of the utilisation of resources are made in order to handle the peaks you anticipate. Shown here in red is the level of resources a business needs to install in order to handle the peak needs of a service. Demand on that service might vary by the time of day, week, month or year, or be driven by exceptional demand driven by promotions or seasonal events.
There are many patterns of usage that make capacity planning a complex science. From on and off usage patterns, where capacity is only needed at fixed times and not at others, fast growth where an online service becomes so successful that step changes in traditional capacity need to be added, variable peaks - where you just don't know what demand will be when and best guess applies, to predictable peaks such as during commute times as customers use mobile devices to access your service.
Each of these examples is typified by wasted IT resources. Where you planned correctly, the IT resources will be over provisioned so that services are not impacted and customers lost during high demand. In the worst cases, that capacity will not be enough, and customer dissatisfaction will result. Most businesses have a mix differing patterns at play, and much time and resource is dedicated to planning and management to ensure services are always available. And when a new online service is really successful, you often can't ship in new capacity fast enough. Some say that's a nice problem to have, but those that have lived through it will tell you otherwise!
You control how and when your service scales, so you can closely match increasing load in small increments, scale up fast when needed, and cool off and reduce the resources being used at any time of day. Even the most variable and complex demand patterns can be matched with the right amount of capacity - all automatically handled by AWS.
Back in 2008, they launched a Facebook application that lets people tell their friends when they've uploaded a video that includes that friend. When people saw the music videos their friends created when the application shared it with them, they wanted to go out and create their own videos. Shortly after launching their social networking modification, they were featured on Techcrunch. As you can imagine, this brought them a lot of unexpected traffic. In the course of 3 days, they went from running on 40 instances to 5,000 instances. Because they were using Amazon Web Services, they were able to handle all of this incoming traffic without having to do a thing. AWS managed it all for them.
