製造・エネルギーグループの辻です。Web系のシステム開発やデータ連携においてデータフォーマットにJSONを利用することは一般的ですが、製造系の基幹システムとのデータ連携においてEDIFACTを利用するケースがあります。EDIFACTはあまり馴染みのない、あるいは聞きなれないデータフォーマットかと思いますが、製造業あるいは他業種においても歴史あるデータフォーマットです。またEDIFACTデータを処理するにあたってはエンタープライズ向けのETL製品やEDIミドルウェアが導入されているケースがよくあると思います。ただ、今回、EDIFACTを扱うJavaアプリケーションをスクラッチ開発するニーズがありました。

そこで本記事では、まずEDIFACTとは何か？ということを簡単に触れたのち、JavaでEDIFACTデータを処理するためのライブラリ選定や実装アプローチの概要を紹介します。

そもそもEDIFACTとは？

EDIFACTとは、国連が定めた電子データ交換の国際標準規格です。正式名称はUN/EDIFACT（the United Nations rules for Elec­tronic Data Interchange for Administration, Commerce and Transport）¹と呼ばれます。テキストベースのデータ構造ですが、JSONのようにキー名を持たず、位置と順序でデータの意味が決まります。' 、 + 、 : などの文字を用いて文字列を区切り、メッセージ仕様に基づいて階層構造やデータの詳細がわかるデータフォーマットです。

EDIFACTのサンプルデータを以下に記載しました。なお、実際の伝送データは改行されていませんが、可視性向上のために改行しています。

UNB+UNOA:2+SENDER_ID+RECEIVER_ID+251228:1500+1234'
UNH+ME001+ORDERS:D:96A:UN'
BGM+220+PO12345+9'
DTM+137:20251228:102'
NAD+BY+BUYER_CODE::92'
NAD+SE+SELLER_CODE::92'
LIN+1+1+PRODUCT_A:EN'
QTY+21:100:PCE'
PRI+AAA:500::NTP'
LIN+2+1+PRODUCT_B:EN'
QTY+21:50:PCE'
PRI+AAA:1200::NTP'
UNS+S'
CNT+2:2'
UNT+14+ME001'
UNZ+1+1234'

UNB や UNH、 DTM といった謎の単語（EDIFACTの用語でセグメントと呼びます）と付随する文字列が現れました。何を意味しているか一見、理解不能のように見えます。

ところが、JSONフォーマットに変換するとなんとなくイメージがわく方も多いのではないでしょうか？以下は先ほどのEDIFACTメッセージを擬似的にJSONに変換したデータです。

{
  "interchangeHeader": {
    "senderId": "SENDER_ID",
    "receiverId": "RECEIVER_ID",
    "timestamp": "2025-12-28T15:00:00",
    "controlReference": "1234",
    "syntaxIdentifier": "UNOA:2"
  },
  "messageBody": {
    "messageHeader": {
      "messageType": "ORDERS",
      "version": "D:96A:UN",
      "messageReferenceNumber": "ME001"
    },
    "documentDetails": {
      "documentNameCode": "220",
      "documentNumber": "PO12345",
      "messageFunctionCode": "9",
      "documentDate": "2025-12-28"
    },
    "parties": [
      {
        "role": "BUYER",
        "id": "BUYER_CODE",
        "codeListQualifier": "92"
      },
      {
        "role": "SELLER",
        "id": "SELLER_CODE",
        "codeListQualifier": "92"
      }
    ],
    "lineItems": [
      {
        "lineNumber": 1,
        "productId": "PRODUCT_A",
        "quantity": {
          "value": 100,
          "unit": "PCE"
        },
        "price": {
          "amount": 500,
          "type": "NetPrice"
        }
      },
      {
        "lineNumber": 2,
        "productId": "PRODUCT_B",
        "quantity": {
          "value": 50,
          "unit": "PCE"
        },
        "price": {
          "amount": 1200,
          "type": "NetPrice"
        }
      }
    ],
    "summary": {
      "totalLineCount": 2
    }
  }
}

EDIFACTの文字列を、上記のように階層構造に変換できる理由は、メッセージタイプ（業務プロセスごとに定義されたデータ構造の仕様）により構造が定義されているためです。上記で紹介した例は、UN/EDIFACTの ORDERS （発注）というメッセージタイプに基づくサンプルメッセージです。

https://service.unece.org/trade/untdid/d96a/trmd/orders_t.htm

その他にも DESADV（出荷通知）、INVOIC（請求）など、様々な業務プロセスに対応するメッセージタイプが定義されています。それぞれのメッセージタイプごとに、どのセグメントを、どの順序で、何回繰り返すかというデータ構造が定義されています。

ただ、実務上はUN/EDIFACTの国際標準をベースにしつつも、業界ごとに独自の規約（サブセット）を定義して運用することが一般的です。たとえば自動車業界では JAMA（日本自動車工業会） ² がEDIFACT導入ガイドラインを制定しています。さらに、業界内でも個社ごとに仕様がカスタマイズされているケースは少なくありません。

JavaのEDIFACTライブラリ選定

EDIFACTの概要を紹介しました。次は、EDIFACTメッセージをJavaアプリケーションで処理するにあたって、ベースとなるライブラリ選定プロセスを紹介します。Javaライブラリをざっくりと調査&簡易検証した結果、候補として以下の2つに絞られました（ただ調査&簡易検証範囲は限定的です。他にもこのライブラリが便利だよ、という知見をお持ちの方、こっそりと教えて下さい）。

結論としては、案2のStaediを採用しました。当初、案1のSmooksを主として検討していましたが、EDIFACTメッセージの定義ファイルを用意することが困難であると判明しました。UN/EDIFACTの標準規格の定義ファイル自体はSmooksの標準機能として提供されており、当初はよさそうに見えていました³。

しかし、実務上は個社別にカスタマイズされているEDIFACTの定義ファイルを用意する必要がありました。いくつか試行錯誤しましたが、この個社別にカスタマイズされている定義ファイルを作成することが困難であるとわかりました。これがノックアウトファクターとなり、代替案であるStaediを採用することにしました。

実装アプローチ

Staediは、EDIFACTデータの読み書きに特化したストリームベースのパーサライブラリです。メッセージ構造の解釈や処理フローはアプリケーションコードに委ねられています。実装方針は大きく2通り考えられました。

1. StaediのREADMEにあるような、イベント駆動（ステートマシン）的なアプローチ
2. 全データをメモリ上のツリー構造として扱う、構文解析的なアプローチ

今回は2の方針を採用しました。実務で採用されている複雑なEDIFACT仕様にそって処理することを考えたとき、主に以下の理由から2のアプローチのほうがコードの保守性が高いと判断したためです。

• コードの構造からメッセージ仕様を直接的に読み取れる
• 入力データの並び順とシステムが必要とする出力データの順序が異なる場合でも、ツリー構造であれば柔軟にデータを取り出せる
• 構文木としてデバッグできるため、構造定義とデータ抽出定義のどちらに問題があるかを特定しやすい

2のアプローチではEDIFACTのセグメントを一度JSONノードのリストとして展開し、そのリストをカーソルを使って走査しながら、階層構造を構築します。EDIFACTのメッセージは ' や + や : などの文字により区切られていますが、このような字句解析はStaediにまかせます。字句解析結果のJSONノードをアプリケーションコードで構造解析し、ビジネスロジックで必要なデータを抽出します（なお、本記事ではデータの抽出部分は割愛します）。

Java処理フロー概要

StaediとJacksonを用いたセグメントのリスト化

まず、Staediの EDIStreamReader とJacksonの ObjectMapper を組み合わせて、EDIFACTメッセージを List<JsonNode> に変換します。EDIFACTの各セグメントを扱いやすいJSONオブジェクトのリストにします。

private static final ObjectMapper MAPPER = new ObjectMapper();

/***
 * EDIFACTデータを読み込み、セグメントのリストを取得する.
 *
 * @param edifactStr EDIFACT形式の文字列データ
 * @throws IOException 入出力例外
 * @return セグメントのリスト
 */
public static List<JsonNode> readSegments(String edifactStr) throws IOException {
    var factory = EDIInputFactory.newFactory();

    // 実データは標準仕様と細部の違いがあるため
    factory.setProperty(EDIInputFactory.EDI_VALIDATE_CONTROL_STRUCTURE, false);
    var stream = new ByteArrayInputStream(edifactStr.getBytes(StandardCharsets.UTF_8));

    JsonNode rootNode;
    try (var ediReader = factory.createEDIStreamReader(stream);
         var jsonParser = factory.createJsonParser(ediReader, JsonParser.class)) {
        // StaediのReaderをJacksonのParserとして扱う
        rootNode = MAPPER.readValue(jsonParser, JsonNode.class);
    }

    // 各セグメントをJsonノードのリストとして取得
    List<JsonNode> segmentList = new ArrayList<>();
    for (JsonNode node : rootNode.path("data")) {
        segmentList.add(node);
    }

    return segmentList;
}

カーソルの用意

次に現在どのセグメントを参照していているか？を管理するカーソルクラスを用意します。パース処理中に、次のセグメントが UNH メッセージであれば UNH メッセージ処理をする、といった先読みをできるようにしています。

/**
 * EDIFACTデータのカーソル操作クラス.
 */
public class EdifactCursor {
    private final List<JsonNode> nodes;
    private int position = 0;

    /**
     * コンストラクタ.
     *
     * @param nodes EDIFACTセグメントのリスト
     */
    public EdifactCursor(List<JsonNode> nodes) {
        this.nodes = nodes;
    }

    /**
     * 現在位置のセグメント名を確認.
     *
     * @return セグメント名
     */
    public String peek() {
        if (position >= nodes.size()) return null;
        return nodes.get(position).path("name").asText();
    }

    /**
     * 指定したタグであれば取得して位置を進める.
     *
     * @param expectedTag 期待するセグメント名
     * @return JsonNode
     */
    public JsonNode match(String expectedTag) {
        if (expectedTag.equals(peek())) {
            return nodes.get(position++);
        }
        return null;
    }
}

パース処理

カーソルを用いて、メッセージをパースする処理を実装します。複数回登場しうるセグメント（NAD、LIN など）は先読みしながらループを回して処理します。コードの構造から、セグメントの流れ（UNH の次に BGM が登場するなど）や登場回数（1回なのか複数回）が、わかることが嬉しいポイントです。

/**
 * ツリー構造のノードとなるグループクラス
 */
public class EdifactGroup {
    private final String name;
    private final List<JsonNode> segments = new ArrayList<>();
    private final List<EdifactGroup> children = new ArrayList<>();

    /**
     * コンストラクタ.
     *
     * @param name グループ名
     */
    public EdifactGroup(String name) {
        this.name = name;
    }

    /**
     * ルートのパース処理.
     *
     * @param cursor EDIFACTカーソル
     */
    public static EdifactGroup parseInterchange(EdifactCursor cursor) {
        EdifactGroup interchange = new EdifactGroup("Interchange")
                .addSegment(cursor.match("UNB"));
        while ("UNH".equals(cursor.peek())) {
            interchange.addChild(parseMessage(cursor));
        }
        return interchange.addSegment(cursor.match("UNZ"));
    }

    /**
     * Message単位のパース.
     *
     * @param cursor EDIFACTカーソル
     */
    private static EdifactGroup parseMessage(EdifactCursor cursor) {
        EdifactGroup message = new EdifactGroup("Message")
                .addSegment(cursor.match("UNH"))
                .addSegment(cursor.match("BGM"))
                .addSegment(cursor.match("DTM"));

        while ("NAD".equals(cursor.peek())) {
            message.addSegment(cursor.match("NAD"));
        }

        return message.addChild(parseDetailSection(cursor))
                .addSegment(cursor.match("UNS"))
                .addSegment(cursor.match("CNT"))
                .addSegment(cursor.match("UNT"));
    }

    /**
     * 明細行単体のパース.
     *
     * @param cursor EDIFACTカーソル
     * @return 明細行グループ
     */
    private static EdifactGroup parseLineItem(EdifactCursor cursor) {
        return new EdifactGroup("LineItem")
                .addSegment(cursor.match("LIN"))
                .addSegment(cursor.match("QTY"))
                .addSegment(cursor.match("PRI"));
    }

    /**
     * 明細セクションのパース.
     *
     * @param cursor EDIFACTカーソル
     * @return 明細セクショングループ
     */
    private static EdifactGroup parseDetailSection(EdifactCursor cursor) {
        EdifactGroup detail = new EdifactGroup("Detail");
        while ("LIN".equals(cursor.peek())) {
            detail.addChild(parseLineItem(cursor));
        }
        return detail;
    }

    /**
     * セグメント追加.
     *
     * @param seg 追加するセグメント
     * @return 追加したセグメント
     */
    public EdifactGroup addSegment(JsonNode seg) {
        if (seg != null) {
            this.segments.add(seg);
        }
        return this;
    }

    /**
     * 子グループ追加.
     *
     * @param group 追加する子グループ
     * @return 追加した子グループ
     */
    public EdifactGroup addChild(EdifactGroup group) {
        if (group != null && !group.isEmpty()) {
            this.children.add(group);
        }
        return this;
    }

    private boolean isEmpty() {
        return segments.isEmpty() && children.isEmpty();
    }
}

実行クラスや toString() などの実装は省略しますが、これらを組み合わせると、以下のようにEDIFACTメッセージを構造化して扱えます。

[Interchange]
  UNB : UNOA:2 + SENDER_ID + RECEIVER_ID + 251228:1500 + 1234
  [Message]
    UNH : ME001 + ORDERS:D:96A:UN
    BGM : 220 + PO12345 + 9
    DTM : 137:20251228:102
    NAD : BY + BUYER_CODE::92
    NAD : SE + SELLER_CODE::92
    UNS : S
    CNT : 2:2
    [Detail]
      [LineItem]
        LIN : 1 + 1 + PRODUCT_A:EN
        QTY : 21:100:PCE
        PRI : AAA:500::NTP
      [LineItem]
        LIN : 2 + 1 + PRODUCT_B:EN
        QTY : 21:50:PCE
        PRI : AAA:1200::NTP
    UNT : 14 + ME001
  UNZ : 1 + 1234

まとめ

JavaによるEDIFACT処理のスクラッチ開発について、ライブラリ選定から実装までの一連の流れを紹介しました。ストリームパーサであるStaediで字句解析、アプリケーション側で構文解析するアプローチを採用することで、EDIFACTの複雑なネスト構造を直感的なコードで表現できるようになりました。少々ニッチな領域ではありますが、モダンな開発環境でレガシーな仕様と向き合う際の参考になれば幸いです。

春の入門祭り2025の21本目の記事です。

はじめに

はじめまして。最近視力が 2.0 から 1.8 くらいに下がった気がする 24 卒 10 月入社の生駒開です。ブルーライトカットレンズは効果ありますか？そろそろ眼鏡市場に行ってみようと思います。

2025 年 2 月より現所属プロジェクトに参画し、Java とにらめっこの毎日を過ごしています。コーディングの機会に恵まれることは大変嬉しく、充実感を感じる日々ですが、一方で、画面の中で完結してしまう作業に少し寂しさを感じていました。

そんな背景から、「自分の手で作ったコードが、現実世界のモノを動かす」という体験をしてみたくなりました。そこで目をつけたのが Raspberry Pi です。この小さなデバイスは、センサーやLEDなどの電子機器をプログラミングで制御できるうえ、電子工作の基礎を学ぶのにも最適です。

このブログでは、初心者向けに私が Raspberry Pi を使って行った障害物検知センサーの制作プロセスをご紹介します。同じように「画面の中だけでないコーディングの楽しさ」を共有できれば嬉しいです。ラズパイを通じて、電子回路やハードウェアの世界へ一歩踏み出すきっかけになれば幸いです！

１．Raspberry Pi って何？

Raspberry Piとは

イギリスの Raspberry Pi 財団が開発した超小型のシングルボードコンピュータです。クレジットカードほどの大きさながら、Linux が動作し、通常のパソコンのように使うことができます。また Raspberry Pi には Model A や Zero、Pico など、サイズや性能によってモデル分けされており、用途に合わせて選定することができます。

• 主な特徴：小型で電力効率が良い
• 用途：IoT デバイス開発、教育、ホームオートメーションなど

使用方法

Raspberry Pi を活用するまでには、いくつかステップを踏む必要があります。

1. OSのセットアップ
   • Raspberry Pi Pico W は MicroPython を使用することが多いです。この OS を作業用 PC から書き込み準備します
   • Thonny などを使うと便利です
2. 電子回路の設計と構築
   • Raspberry Pi の GPIO ピンを使い、外部デバイスを接続します。初めての方は、シンプルな回路設計（例: LED の点滅）から始めるのがおすすめです
   • 注意：GPIO ピンの電流制御が必要なので、抵抗を適切に導入します
3. 実行環境の整備
   • コードは MicroPython や C を利用して開発。シンプルな LED 制御から徐々に複雑なセンサー動作へ応用します

GPIO ピンの役割や基本的な回路の接続方法について、第３項で詳しく触れます。

２．今回のチャレンジ内容

今回のプロジェクトでは、Raspberry Pi Pico W と赤外線反射センサーを使用して、障害物検知センサーを作成します。最終的には、障害物を検知した際に LED で信号を出力する仕組みを実現することを目指します。

• Raspberry Pi と外部センサー（赤外線反射センサー）を連携させる
• Raspberry Pi のGPIOを活用して入出力の基本を覚える
• チュートリアルを通じて初歩的な電子工作を学ぶ

３．障害物検知センサーの開発

本番開発を行う前に、まずは必要なものを揃えてチュートリアル開発をクリアしましょう！

3.1 必要なもの

今回使用するものは以下の通りです。

• Raspberry Pi Pico W: 主人公。コンパクトかつ省電力でとにかく安い。¥1,300 くらい
• ブレッドボード: 回路構築用。¥400 くらい
• 抵抗器: LEDへの過電流を防ぐため。今回は安全な電流量を計算し 220Ω を使用。¥40 くらい
• LED: 障害物検知時の信号出力用。¥10 くらい
• ジャンパーワイヤー: 配線用。10 本で ¥700 くらい
• 作業用PC: コードの作成・転送用。（セキュリティ事故が怖いので私用 PC ）
• マイクロUSBアダプタ: 電源供給兼データ通信用。（忘れがち）（充電用だけでは×）
• 赤外線反射センサー: 障害物検知用。一個 ¥600 くらい
• 電池ボックス: Pi の外部電源として使用

3.2 環境構築

Raspberry Pi Pico W を使うためには、まず開発環境を整える必要があります。以下の手順で環境構築を行います。

1. MicroPython のインストール

Raspberry Pi Pico W に MicroPython をインストールします。これはPicoをプログラムするために必要な標準的な OS です。MicroPython公式サイトからUF2形式のファイルをダウンロードし、Pico を PC に接続した後、ドライブへドラッグ＆ドロップするだけでインストールが完了します。

2. 開発ツールの準備

作業用 PC に Python IDE（統合開発環境）であるThonnyをインストールします。Thonny は Raspberry Pi Pico W に標準対応しており、コードを書いて直接転送するための便利なツールです。以下のステップを行います。

1. Thonny公式サイトからインストールする
2. 適切なボードを選択（例: Raspberry Pi Pico W）
3. MicroPython を選択して開発開始テスト

3. 接続確認

Thonny を起動し、接続ができたことを確認します。

準備が整ったら次のステージへ進みます！

3.3 チュートリアル開発

3.3.1 Raspberry Pi Pico W の GPIO

図１　Raspberry Pi Pico WH 本体

GPIO（General Purpose Input/Output）は、「汎用入力/出力ピン」を指します。このピンを使用することで、さまざまな外部デバイス（センサー、LED、モータなど）と通信したり制御したりすることができます。Raspberry Pi Pico W には40ピンのヘッダがあり、それぞれ異なる役割を持っています。以下は、全体のピン配置と役割の概要です。

1. GPIO（汎用入出力ピン）
   • ピン番号: GPIO 0〜25
   • 外部デバイスとの通信や信号の受け渡しに使用します
   • GPIO ピンは「デジタル入出力（HIGH/LOW）」の動作を設定できます
   • 特定のピンは通信プロトコルのための特殊機能を持つ（SPI/I2C/UARTなど）
2. 電源系ピン
   • GND（グランド）
     • 複数箇所に配置されています。（例: ピン3, ピン8, ピン13など）
     • 電子回路を完成させるために必要な基準電位を提供します
   • 3V3（3.3Vピン）
     • ピン番号: 36, 37
     • Raspberry Pi Pico W 自身や外部デバイスへの供給電圧として使用します
     • Pico は 3.3V で動くデバイス用に設計されています
   • VBUS（USBバス電源）
     • ピン番号: 40
     • USB から提供される電源（5V）を使用したい場合に利用
3. ADC（アナログ入力ピン）
   • ピン番号: GPIO 26〜28
   • アナログ信号（電圧値）をデジタル値に変換するためのピン
   • 電圧範囲: 0〜3.3Vのアナログ入力を取得できます
   • 例: センサーの出力を読み取りたいときに使用
4. 通信プロトコル専用ピン
   • SPI（Serial Peripheral Interface）
     • GPIO 10（MOSI）、GPIO 11（SCK）、GPIO 8（CS）
     • 高速通信が可能で、センサーやディスプレイとの接続に適しています
   • I2C（Inter-Integrated Circuit）
     • GPIO 4（SDA）、GPIO 5（SCL）
     • 複数のデバイスを並列で接続する場合に便利
   • UART（Universal Asynchronous Receiver/Transmitter）
     • GPIO 0（TX）、GPIO 1（RX）
     • シリアル通信に使用

ピン配置マップ（概要）

図２　Raspberry Pi Pico WH 本体の裏側

以下は、Raspberry Pi Pico W の40ピンの役割を簡単にまとめたものです。

3.3.2 ブレッドボード電子回路

図３　ブレッドボードの電気的関係

ブレッドボードは、電子部品をハンダ付けせずに接続・テストできる基板です。電源レールと端子列を使って部品を配置し、ジャンパーワイヤで接続します。

1. 電源レール
   • 長い列（赤と青のライン）で、電源（例: 3.3V、GND など）を供給するために使います。
   • 赤: プラス（+）
   • 青: マイナス（-）
2. 端子列（作業スペース）
   • 中央の多数の穴が5つずつ連結されており、部品や配線を接続できます。
   • 部品を差し込むと、5つの穴が電気的に結ばれる。
3. 溝（中央のノッチ）
   • 真ん中の溝は「左側」と「右側」を分け、電気的に互い独立したエリアです。

使用方法

ブレッドボードを使う際の基本的な手順は以下の通りです。

1. 電源を供給

電源レールに適切な電圧（例: 3.3V、GND）を供給します。Raspberry Pi Pico W の場合、以下のピンを利用します：

• 3V3 ピン：赤い電源レールへ接続。
• GND ピン：青い電源レールへ接続。

2. 部品を配置

電子部品（LED、抵抗、センサーなど）を端子列の適切な穴に差し込みます。配線が正確になるよう配置を確認しましょう。

3. ジャンパーワイヤで接続

ジャンパーワイヤを使い、部品同士をつなぎます。

• GPIO ピンや電源レールを正しく接続。
• 必要に応じて抵抗器やコンデンサを挿入。

4. 動作確認

回路が完成したら Raspberry Pi Pico W の電源をオンにして動作をチェックします。

3.3.3 「Lチカ」をやってみよう

ここでは Raspberry Pi Pico W の基本機能を試します。「Lチカ」とはプログラミング言語学習における「Hello World !」です。「LEDを点滅（チカチカ）させる」作業を行い、GPIO ピンが正しく動作していることを確認します。電子回路は以下のように設計し、構築していきます。

図４　Lチカ時の配線概要図

以下はMicroPythonで記述したコードです。

from machine import Pin
import time

led = Pin(25, Pin.OUT)  # Raspberry Pi Pico W内蔵LEDのピン番号

while True:
    led.high()           # LEDを点灯
    time.sleep(1)        # 1秒待機
    led.low()            # LEDを消灯
    time.sleep(1)        # 1秒待機

LED が1秒間隔で点滅すれば成功です！これは GPIO ピンの基本動作の確認にも役立ちます。

3.3.4 赤外線反射センサーの動作確認

次は、赤外線反射センサーの動作を検証します。センサーが反応すると LED が発光するよう、以下の通りに電子回路を設計し、構築していきます。

図５　赤外線反射センサーの動作確認時の配線概要図

以下は本動作確認におけるコードです。

from machine import Pin
import time

sensor = Pin(15, Pin.IN)  # 接続したセンサーのGPIOピン番号
led = Pin(21, Pin.OUT)

while True:
    var = sensor.value()
    print("センサー値：", val)

    if val == 0: #反射が無い
        led.on()
    else: #反射有り
        led.off()

    time.sleep(0.2) #0.2秒のインターバル

動作確認ができたら、いよいよ障害物検知センサーの開発です！

3.4 本番開発

3.4.1 目的と目標

本番開発では、チュートリアルで学習した内容を応用して、以下のシステムを完成させることを目指します。

1. 障害物の検知：赤外線反射センサーを２つ使用して障害物の有無を正確に確認する
2. 信号の処理：検知した信号に応じて、LED を利用して視覚的なフィードバックを提供する
3. 動作タイミングの調整：プログラムとハードウェアが一体となってシームレスに動作するシステムを設計する

3.4.2 回路設計

本番開発の回路は電子工作初心者にもわかりやすい設計です。以下に手順を示します。

図６　障害物検知センサーの配線概要図

1. 障害物検知センサーの接続
   • センサーの出力ピンを Raspberry Pi Pico W の GPIO に接続
   • 入力ピンを 3.3V ピンに接続し、センサーの動作電圧を供給
   • GND ピンを Pico の GND ピンへ接続
2. LED の接続
   • LED の長い足を抵抗（220Ω）を介して GPIO ピンに接続する
   • LED の短い足を GND に接続し、過電流を防ぐ
3. 電源供給
   • 電池ボックスを使用して安定した電源を提供する

回路完成後は再確認を行い、誤接続がないことを確認してください。

3.4.3 プログラム設計

以下は、本番環境向けのコードです。障害物検知時、LED が光る動作を実装します。

from machine import Pin
import time

left_sensor = Pin(10, Pin.IN)  # 左センサー DOUT
right_sensor = Pin(11, Pin.IN) # 右センサー DOUT
led = Pin(21, Pin.OUT)         # LED

while True:
    left_val = left_sensor.value()
    right_val = right_sensor.value()

    print("", left_val, "", right_val)

    if left_val == 0 or right_val == 0:
        led.on()  # センサーどちらかが反射無し
    else:
        led.off() # センサーどちらとも反射有り

    time.sleep(0.1)

このコードでは、各センサからの信号値を確認し、それに基づいて LED をオン・オフ切り替えます。

3.4.4 動作検証

1. センサーの応答性チェック
   • 受信したセンサーの値を確認できました
   • 左右のセンサーが独立して障害物を検知できていました
2. LED 動作のタイミング
   • LED が障害物検知してから 0.1 秒以内に発光しました
3. 電源の安定性確認
   • 電池ボックスの電源供給は安定していました

図７　障害物がない状態

図８　片側のセンサーのみ障害物を検知している状態

図９　両センサーが障害物を検知した状態

3.4.5 のびしろ

1. センサーの信号をアナログに変更
   • 信号強度によって今後組み込むモーターの制御を可能にできます
2. Raspberry Pi Pico W の Wi-Fi 機能の活用
   • 障害物を検知した際に LINE で通知する機能を実装しようと思います

４．今後の展望

今回のプロジェクトでは、障害物検知センサーシステムを作成しましたが、これをさらに発展させて、火星探査ローバーのような機能を持つ移動式ロボットの開発にチャレンジしたいと思います。また以下のような要素を追加することで、より高度で有意義なプロジェクトになることを望んでいます。

1. モータ制御で移動機能を追加
   • Raspberry Pi Pico W を使ってモータを制御し、センサーが検知した障害物を回避できるロボットを作成
   • ロボットが自律的に動く仕組みを実現することで、探査ローバーのようなプロジェクトに挑戦
2. 無線通信の導入
   • Pico W の Wi-Fi 機能を活用し、リアルタイムで障害物データを遠隔地に送信するシステムを構築
   • 火星探査ローバーのように、データ収集とその送信を組み合わせたプロジェクトを展開
3. AI 技術の応用
   • カメラモジュールや画像認識技術を追加し、物体の種類を判別可能なロボットを試作
   • 機械学習を組み合わせることで、よりインテリジェントなシステムを作り上げる

またローバーにフォーカスするだけでなく、他の分野へ応用できる可能性も見つけられると思います。まだまだ始まったばかりのプロジェクト（笑）ですが、より面白いものが作れるよう取り組んでまいります。

５．まとめ

障害物検知センサーの開発を通じて、Raspberry Pi Pico W の GPIO 操作や電子工作の基礎を学ぶことができました。特に、コードを使ったプログラムだけでなく、実際にハードウェアを動かす楽しさを味わえたのではないでしょうか。電子工作の魅力は、コーディングが画面の中だけに留まらず、実世界で形になり、動作するものを生み出せることにあります。その瞬間、センサーやモータなどが動く様子は、まるで魔法をかけたかのようにワクワクさせてくれるものです。

みなさまも、ぜひ自分らしいプロジェクトに挑戦してみてください。小さな成功が自信につながり、次のステップへの扉を開きます。そして、楽しい人生を彩る最高の体験になるはずです！

本記事は、春の入門祭り2025の3本目です。

はじめに

昨年のWWDC2024のセッションEmbedded Swiftでサイズを縮小でSwiftで組み込み開発ができることを知り、今回実際にEmbedded Swiftを用いてRaspberry Pi Pico WをLチカさせてみました！

実際に、サンプルプロジェクトを動作させるまでに組み込み開発初心者視点で詰まった箇所や知らなかったことなども一緒に紹介したいと思います。

Embedded Swiftとは

Embedded Swiftとは、メモリやストレージに制約のある環境でも使えるように、Swiftの柔軟性を保ちつつ、動的機能を制限してサイズを小さくしたSwiftのサブセット言語です。

Embedded Swiftの強み:

Swiftの強みである型安全・所有権管理・自動メモリ管理といった利点を組み込み開発にも適用できることが最大のメリットです。これはCやC++での組み込み開発におけるメモリリークやバッファオーバーフローといった不具合が発生しやすいことや安全性の確保が難しいという課題を解消することにもつながります。

Embedded Swiftの制約:

組み込み開発の現場では、メモリやストレージが極めて限られており、従来のSwiftランタイム（約5MB）では到底収まりません。たとえば、ArduinoやSTM32などのボードでは、使用可能なRAMがたった数十〜数百KBというケースも珍しくありません。Embedded Swiftは、このような制約環境でも動作可能な、軽量なSwiftの実行モデルを提供します。

Embededed Swiftでは、以下のSwiftが提供する動的機能を制限することでコードサイズを小さくすることを実現しています。

• 動的リフレクション（reflection）
  • Mirror型
  • as?を用いたダウンキャスト
• 存在型（existentials）
  • any型
• ABIの安定性とライブラリの進化への対応
• 別コンパイルされたジェネリクス
• 動的コード読み込み（プラグインなど）

次の図は、Swiftランタイムと標準ライブラリのサイズ縮小に関する既存の取り組みとEmbedded Swiftがどのようにアプローチしているかを示しています。（swiftlang/swift-evolution/visions/embedded-swift.mdより引用）

より詳細なEmbedded Swiftの制約は以下を参照してください。

swift/docs/EmbeddedSwift/EmbeddedSwiftStatus.md

Embedded Swiftを用いてRaspberry Pi Pico WをLチカさせる

レポジトリapple/swift-embedded-examplesにいくつかのサンプルプロジェクトがあるなかで、今後色々電子工作で楽しめそう、かつ情報も豊富そうなRaspberry Pi Pico Wに関するプロジェクトを実際に試して見ることにしました。

以下のサンプルプロジェクトを使って、Embedded Swiftを用いてRaspberry Pi Pico WをLチカさせたいと思います。

• apple/swift-embedded-examples/pico-w-blink-sdk

このプロジェクトは、公式が提供しているPico-sdkを用いることで、基本的な機能等はSDKに持たせ、どのように動作させるかなどはEmbedded Swiftで実装していくようなものです。

実行環境

• macOS: 15.4（24E248）
• Swift: Apple Swift version 6.2-dev (LLVM 3f3fde0d5f85709, Swift 0c5fd6a3017961d)
• MacBookPro 13-inch M1(2020)
• Raspberry Pi Pico W

事前準備

次のドキュメントに沿って事前準備行います。

• apple/swift-embedded-examples

その後、今回使用するRaspberry Pi Pico Wに対するサンプルプロジェクトのREADME.mdに沿ってビルドランまで行います。

• apple/swift-embedded-examples/pico-w-blink-sdk

最新のdevelopment snapshotのToolchainをインストール

次のサイトから、最新のdevelopment snapshotのToolchainをインストールします。
https://www.swift.org/install/macos/#development-snapshots

Toolchainがインストールされたことを確認します。swift-DEVELOPMENT-SNAPSHOT-2025-04-03-a.xctoolchainが追加した Toolchainです。タイミングによっては、より新しいものになっていると思います。

$ ls /Library/Developer/Toolchains/

swift-DEVELOPMENT-SNAPSHOT-2025-04-03-a.xctoolchain	swift-latest.xctoolchain

追加したToolchainが使用できるように、パスを通します。

$ vi ~/.zshrc
export PATH="/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-04-03-a.xctoolchain/usr/bin:$PATH"
export TOOLCHAINS="/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-04-03-a.xctoolchain/usr/bin"

Swiftのバージョンが次のように変わっていることを確認します。

$ swift -version

Apple Swift version 6.2-dev (LLVM 3f3fde0d5f85709, Swift 0c5fd6a3017961d)
Target: arm64-apple-macosx15.0
Build config: +assertions

Raspberry Pi Pico SDK（pico-sdk）の準備

続いて、pico-sdkの準備をします。

• pico-sdkをクローン

  git clone https://github.com/raspberrypi/pico-sdk.git cd pico-sdk git submodule update --init

• pico-examplesをクローン

  git clone https://github.com/raspberrypi/pico-examples.git

• CMake、ninja、The Arm Embedded Toolchainのインストール
  HomeBrewを使ってそれぞれインストールします。

  brew install cmake brew install armmbed/formulae/arm-none-eabi-gcc　←ここ注意 brew install ninja

環境変数の設定

次のように設定します。

export PATH="/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-04-03-a.xctoolchain/usr/bin:$PATH"
export TOOLCHAINS="/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-04-03-a.xctoolchain/usr/bin"
export PICO_BOARD=pico_w
export PICO_SDK_PATH={任意のディレクトリ}/pico-sdk
export PICO_TOOLCHAIN_PATH=/opt/homebrew/opt/arm-none-eabi-gcc/lib/

ビルドラン

準備が完了したので、サンプルプロジェクト(apple/swift-embedded-examples/pico-w-blink-sdk)をビルドランしたいと思います。

CMakeを実行します。

cd pico-w-blink-sdk
cmake -B build -G Ninja . -DCMAKE_EXPORT_COMPILE_COMMANDS=On

完了すると、次のようなメッセージが出力されます。

-- Configuring done (0.3s)
-- Generating done (0.1s)
-- Build files have been written to: {任意のディレクトリ}/build

次に、ビルドします。

cmake --build build

無事ビルドが成功すれば、次のようなメッセージが末尾に表示されます。

[X/X] Linking CXX executable swift-blinky.elf

buildフォルダ配下にswift-blinky.uf2ファイルができます。
このファイルをデバイスにコピーします。

そうすると、LEDが点滅します。

LEDを点滅させる処理は、Main.swiftに次のように書かれています。

@main
struct Main {
  static func main() {
    let led = UInt32(CYW43_WL_GPIO_LED_PIN)
    if cyw43_arch_init() != 0 {
      print("Wi-Fi init failed")
      return
    }
    let dot = {
      cyw43_arch_gpio_put(led, true)
      sleep_ms(250)
      cyw43_arch_gpio_put(led, false)
      sleep_ms(250)
    }
    let dash = {
      cyw43_arch_gpio_put(led, true)
      sleep_ms(500)
      cyw43_arch_gpio_put(led, false)
      sleep_ms(250)
    }
    while true {
      dot()
      dot()
      dot()

      dash()
      dash()
      dash()

      dot()
      dot()
      dot()
    }
  }
}

ビルド時詰まった箇所とその解決策

cmake --build buildを実行したときに、以下のエラーに遭遇したので、その原因と解決策について記載します。

arm-none-eabi-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory
error: failed to emit precompiled header '.../BridgingHeader.pch' for bridging header '.../BridgingHeader.h'
error: 'inttypes.h' file not found

1. arm-none-eabi-gcc の nosys.specs が見つからない

arm-none-eabi-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directoryというエラーは、はじめに、次のコマンドでHomeBrew版arm-none-eabi-gccをインストールしてしまったが良くありませんでした。

brew install arm-none-eabi-gcc

もう一度、apple/swift-embedded-examples/pico-w-blink-sdkを確認してみるとThe Arm Embedded Toolchain.とリンク付きで書いてありました。

正しくは、以下のコマンドでARMmbed版のarm-none-eabi-gccをインストールします。

brew tap armmbed/formulae
brew install armmbed/formulae/arm-none-eabi-gcc

これでARM Toolchainのリンカを使ってバイナリファイルが無事生成できるはずです。

2. C言語の標準ヘッダが見つからない

次のエラーは、sysrootを認識しないことが一つの要因だと考えました。

error: failed to emit precompiled header '.../BridgingHeader.pch' for bridging header '.../BridgingHeader.h'
error: 'inttypes.h' file not found

そこで、Swiftコンパイラにsysrootを明示的に指定することで解決を行いました。

CMakeLists.txtに以下を追加します。

-Xcc --sysroot=/opt/homebrew/Cellar/arm-none-eabi-gcc/14.2.0/arm-none-eabi

具体的には、次のようになります。

cmake_minimum_required(VERSION 3.13)
include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)

project(swift-blinky)
pico_sdk_init()

if(APPLE)
execute_process(COMMAND xcrun -f swiftc OUTPUT_VARIABLE SWIFTC OUTPUT_STRIP_TRAILING_WHITESPACE)
else()
execute_process(COMMAND which swiftc OUTPUT_VARIABLE SWIFTC OUTPUT_STRIP_TRAILING_WHITESPACE)
endif()

add_executable(swift-blinky)
target_link_libraries(swift-blinky
    pico_stdlib hardware_uart hardware_gpio pico_lwip_arch pico_cyw43_arch_none
)

# Gather compile definitions from all dependencies
set_property(GLOBAL PROPERTY visited_targets "")
set_property(GLOBAL PROPERTY compilerdefs_list "")

function(gather_compile_definitions_recursive target)
    # Get the current value of visited_targets
    get_property(visited_targets GLOBAL PROPERTY visited_targets)

    # make sure we don't visit the same target twice
    # and that we don't visit the special generator expressions
    if (${target} MATCHES "\\$<" OR ${target} MATCHES "::@" OR ${target} IN_LIST visited_targets)
        return()
    endif()

    # Append the target to visited_targets
    list(APPEND visited_targets ${target})
    set_property(GLOBAL PROPERTY visited_targets "${visited_targets}")

    # Get the current value of compilerdefs_list
    get_property(compilerdefs_list GLOBAL PROPERTY compilerdefs_list)

    get_target_property(target_definitions ${target} INTERFACE_COMPILE_DEFINITIONS)
    if (target_definitions)
        # Append the target definitions to compilerdefs_list
        list(APPEND compilerdefs_list ${target_definitions})
        set_property(GLOBAL PROPERTY compilerdefs_list "${compilerdefs_list}")
    endif()

    get_target_property(target_linked_libs ${target} INTERFACE_LINK_LIBRARIES)
    if (target_linked_libs)
        foreach(linked_target ${target_linked_libs})
            # Recursively gather compile definitions from dependencies
            gather_compile_definitions_recursive(${linked_target})
        endforeach()
    endif()
endfunction()

gather_compile_definitions_recursive(swift-blinky)
get_property(COMPILE_DEFINITIONS GLOBAL PROPERTY compilerdefs_list)

# Parse compiler definitions into a format that swiftc can understand
list(REMOVE_DUPLICATES COMPILE_DEFINITIONS)
list(PREPEND COMPILE_DEFINITIONS "") # adds a semicolon at the beginning
string(REPLACE "$<TARGET_PROPERTY:PICO_TARGET_BINARY_TYPE>" "$<TARGET_PROPERTY:swift-blinky,PICO_TARGET_BINARY_TYPE>" COMPILE_DEFINITIONS "${COMPILE_DEFINITIONS}")
string(REPLACE ";" ";-Xcc;-D" COMPILE_DEFINITIONS "${COMPILE_DEFINITIONS}")

add_custom_command(
    OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/_swiftcode.o
    COMMAND
        ${SWIFTC}
        -target armv6m-none-none-eabi -Xcc -mfloat-abi=soft -Xcc -fshort-enums
        ${COMPILE_DEFINITIONS}
        -Xcc -DCYW43_LWIP
        -Xcc -DPICO_CYW43_ARCH_THREADSAFE_BACKGROUND
+        -Xcc --sysroot=//opt/homebrew/Cellar/arm-none-eabi-gcc/10.3-2021.10/gcc/bin/../arm-none-eabi
        -Xcc -I$ENV{PICO_SDK_PATH}/lib/lwip/src/include
        -Xcc -I${CMAKE_CURRENT_LIST_DIR}/include
        -Xfrontend -function-sections -enable-experimental-feature Embedded -wmo -parse-as-library
        $$\( echo '$<TARGET_PROPERTY:swift-blinky,INCLUDE_DIRECTORIES>' | tr '\;' '\\n' | sed -e 's/\\\(.*\\\)/-Xcc -I\\1/g' \)
        $$\( echo '${CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES}'             | tr ' '  '\\n' | sed -e 's/\\\(.*\\\)/-Xcc -I\\1/g' \)
        -import-bridging-header ${CMAKE_CURRENT_LIST_DIR}/BridgingHeader.h
        ${CMAKE_CURRENT_LIST_DIR}/Main.swift
        -c -o ${CMAKE_CURRENT_BINARY_DIR}/_swiftcode.o
    DEPENDS
        ${CMAKE_CURRENT_LIST_DIR}/BridgingHeader.h
        ${CMAKE_CURRENT_LIST_DIR}/Main.swift
)
add_custom_target(swift-blinky-swiftcode DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/_swiftcode.o)

target_link_libraries(swift-blinky
    ${CMAKE_CURRENT_BINARY_DIR}/_swiftcode.o
)
add_dependencies(swift-blinky swift-blinky-swiftcode)
pico_add_extra_outputs(swift-blinky)

おわりに

Embedded Swiftを用いてLaspberry Pi Pico WをLチカさせることができました。

Laspberry Pi Pico Wを買うときに、電子工作のスターターキットで購入していたので、Embedded Swiftを使って様々な電子工作にもチャレンジしてみたいと思います。

参考

• Embedded Swiftでサイズを縮小-WWDC24-ビデオ-Apple Developer
• https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md
• https://github.com/apple/swift-embedded-examples/
• https://github.com/apple/swift-embedded-examples/tree/main/pico-w-blink-sdk
• GCCのsysrootオプションについて調べてみた
• Raspberry Pi PicoとEmbedded Swiftを試してみる - ANDPAD Tech Blog
• iOSDC Japan 2024: Raspberry Pi Pico を Swift で操作する / yochidros

はじめに

こんにちは。180度開脚に憧れてストレッチを続けている、HealthCare Innovation Group(HIG)所属の山本です。

以前から自作キーボード、分割キーボード、XX％キーボードといった単語には興味を惹かれていたのですが、電子工作初心者の自分としてはなかなか敷居を高く感じていました。

この度、自作キーボードに初めて挑戦し、40％分割キーボードを使いこなすに至ったので、その動機や経緯を含め、魅力をお伝えしていきたいです。

※自作キーボードについては既存記事も面白いものが多いのでぜひ御覧ください！

https://future-architect.github.io/tags/自作キーボード/

作成したもの

今回私が作成したキーボードは、以下のようなものです。

キーキャップに無刻印のものを使用しているためちょっと分かりづらいですが、通常のキーボードよりもキー数が少ないです。

ファンクションキーや数字キーもないので、かなりスッキリした見た目になる反面、初めて見る方にはどう入力するのかと困惑されるのではないでしょうか？

製品としては、foostanさんが作成されているCorne Cherryシリーズのものを使わせていただきました。

日本で有数の自作キーボードの店舗＆オンラインショップである、遊舎工房さんのサイトでもいくつかシリーズが販売されています。
https://shop.yushakobo.jp/search?type=product&options%5Bprefix%5D=last&options%5Bunavailable_products%5D=last&q=Corne+Cherry

作成までの経緯

このセクションでは、作成に至るまでの動機と経緯をポエミーに書きます。

動機編

はじめに、今回挑戦した動機について軽く触れておきます。

今までの多くをリモートワークで過ごしてきたわけですが、以下のような思いをモヤモヤと抱えていました。

1. デスクに向かいすぎて、首肩こりが強くなってきた
2. せっかくリモートワークをしているから、至高のデスク環境を極めたい
3. 一般的なキーボードでタッチタイピング程度であればできるが、より高みを目指せるのではないか…？

1についての対応としては、「分割キーボード」を導入することがよいという一説があります。通常のキーボードではどうしても肩幅より小さい位置へ手を置くことになりますが、分割されていることにより各々の肩幅や手の位置似合わせて配置できるという利点ですね。

2, 3については、より高みを目指したいという心の奥底のコダワリ心ですね。つまり私的には自己満足と浪漫の世界です。そんな折、「40％キーボード」の魅力を先人が書いた記事を見かけました。いわく、ホームポジションからほとんど手を動かさずにすむためキー入力が効率的になるということです。これに強い魅力を感じました。

これらの思いから、自作40％キーボードの世界には強い興味を持っていました。

見学編

とはいえ、自作キーボードの作成経験もなく、電子工作の経験もあまりない私には右も左もわからない状態でした。

そのため、実際に国内でも有数の自作キーボードショップである、遊舎工房さんの実店舗(秋葉原にある)に行ってみました。

https://yushakobo.jp/shopinfo/

こちらの店舗では、様々な種類の自作キーボードが店内に展示されており、実際に触ることができます。キー入力の感触や外観、他にも形状など己のフィーリングを確かめることができるので、気分は伝説の聖剣を抜きにきた村人Aの気持ちになれます。

店員さんも親切で、各種部品やキットの販売なども行っているため、同じように入門される方は一度行ってみることをおすすめします。

作成編

残念なお知らせとして、このブログ記事の執筆時点ではすでにキーボードは完成してしまいました。(記録など取ること忘れてました。。)

そのため、組み立てやはんだ付けについては他の方の記事や動画などを参照ください。

日本で販売されている組み立てタイプの自作キーボード(自分ではんだ付けから行うもの)の多くは、ビルドガイドがGithub上で公開されていたりします。

(例：今回扱ったfoostanさんのビルドガイド)

自作キーボードに挑戦される方は、これらの事前情報があるタイプのキーボードかも確認されると良いかもしれません。

また、はんだ付けに不安がある方へはキーボードの組立サービスであったり、そもそもはんだ付けがされた状態で発売されている製品などもあるので挑まない選択肢もあるため安心できます。
(私はYouTubeのはんだ付け動画を繰り返しみつづけました)

使いこなすまでの試行錯誤

ここまでの経緯で、なんとか動作する自作40％キーボードについては作成できました。

しかしなんと、製作したから終わりではなく、まだまだ拘れるポイントがあるので紹介します。
(これがキーボード沼と呼ばれる理由かと思ってます。時間と金を無限に溶かすことができそうです)

1. キースイッチの試行錯誤

キーボードの打鍵感は非常に個人的なもので、それを自由にカスタマイズできるのが自作キーボードの強みの1つかと思っています。

キースイッチには、赤軸、青軸、茶軸、スピードシルバー軸などなどさまざまな種類があり、それぞれによって打鍵したときの感触や打鍵音が変わってきます。HHKBやKeychronなどを購入する際にも比較するような情報ですね。

今回のキーボードでは、軽めの打鍵感と感触の好みからスピードシルバー軸のものを購入しました。

2. キーキャップの試行錯誤

キーキャップの素材やデザインも打鍵感に意外なほど大きな影響を与えてきます。

このキーキャップの形状についてはProfile(プロファイル)と呼ばれており、高さやくぼみなどの形状が異なってきます。市販のメカニカルキーボードの多くはOEM Profileと呼ばれるものに該当するそうです。

(https://www.keycaps.info で作成した画像を引用)

上記の画像で見比べて見ると、多様性があることがわかるのではないでしょうか？

試行錯誤の末、私の個人的な好みとしては高めのProfileであるSA Profileが打ちやすいことがわかりました。

3. キーボード角度の試行錯誤

キーボードの水平方向の傾きもキー入力のしやすさや肩こりの解消に大きな影響を与えてきます。自分の手を前水平に伸ばしてみると感じることができますが、人間の手首は微妙に外向きに回転した状態が自然な除隊となることが多いです。

そのため、机と平行なフラットなキーボードで長時間入力することで、手首や肘への疲労が蓄積していまいます。

対策として、キーボードの角度を変える、「テンティング」という単語で呼ばれる試行錯誤があります。

結論として、水平方向ではこのくらいの角度が自分にはフィットしました。(人によっては60度くらいの角度を付けている人も見かけますね)

4. キーマップの試行錯誤

こちらは40％キーボードや60％キーボード特有の話となってきますが、キーマップの試行錯誤についても探求の余地があります。

そもそも、数字キーボードや一部記号キーがない40％キーボードでは、これらのキーをどうやって入力するのでしょうか？

ここで、「レイヤー」という概念が出てきます。通常のキーボードでもFnキーを押している間、他のキー入力の効果が変わるといったことがあると思います。これを自由にカスタマイズできるのが特徴です。

下画像での例としては、「G」キーを単体で入力したときにはGがそのまま入力され、右下の青い上矢印キー+「G」キーを入力したときには6が入力される、といった挙動としています。

自作キーボードの多くは、以下のRemapのサイト上などでキー配置を自由に組み替えることができます。

https://remap-keys.app/configure

私のキーマップ例を示しますが、以下のようになっています。自分の入力しやすいようにカスタマイズできるのはもちろん、レイヤーキーとの組み合わせで入力できるキー数が3倍となっています。

40％キーボードでありながら、過不足なく、ホームポジションからほとんど手を動かさずに入力できるのは素晴らしい利点です。

これら以外にも、3Dプリンタでの筐体作成、バックライト、トラックボールの組み込みなどまだまだこだわれる要素はたくさんあります。

あまりに極めすぎると2度と通常のキーボードで入力できなくなる懸念はありますが、楽しみが多いのは良いことですね。

まとめ

これまでの記事で、自作40％キーボードに挑戦する道のり、そのさきの沼の深さの一端をご紹介しました。

肩こりを動機として挑んだ自作40％キーボードですが、試行錯誤の末かなり満足できる環境とできたと個人的には感じています。

ひとつひとつ自分の体の特徴やクセを見極め、相棒となる道具をアップデートして成長していける経験は人生でもそう多くないものと考えています。

個人的には、そのような機会に大人になってから挑戦できるという意味でも良い経験となりました。

肩こりに悩む方、キーボード沼にハマってみたい方、あるいは自分の相棒となるキーボードを探したい方、それ以外の全ての方にも、自作キーボードを探して・作って・試行錯誤して、といった経験はとても楽しいものですのでぜひ一度はやってみることをオススメしたいです。思ったより敷居は高くなかったです。

こんにちは！ 流通・製造サービス事業部所属の高世です。

こちらは春の入門連載2024の10記事目です。

IoTという言葉が話題になり始めてから、かなりの時間が経ちました。私自身も身近なIoTに関心を持っていろいろ取り組んできましたが、ソフトウェアだけでなくハードウェアの知識も必要になるなど、初めて挑戦する方にとっては敷居が高いと感じることがしばしばありました。
特にインターネットに接続するあたりのインフラ周辺は、選択肢が多様で、その分複雑であったり費用がかかったりする場合もあります。

この記事では、そうしたIoTの問題点をGoogleSpreadSheetを利用することで、手軽に実装できた経験を共有したいと思います。

今回やること

今回はESP32というマイコンを利用して温度センサから定期的に温度を計測し、その情報をGoogleSpreadSheet上に保持するシステムを構築します。

温度センサにはDS18B20という安価で入手性の良いセンサを使用し、冷蔵庫内と冷蔵庫の外（室内）の2つのセンサを設置します。

ESP32とは

https://akizukidenshi.com/catalog/g/g115673/

今回使用するESP32は、いわゆるマイコン（マイクロコントローラー）と呼ばれるもので、PCほど高尚な処理はできませんが、プログラムを書き込むことで決められたInputから何かしらのOutputを出すことができます。

その中でもESP32はWi-FiやBluetoothなどの無線通信機能を搭載し、IoTデバイスの開発などによく用いられます。

またArduino IDEと互換性があるのも強みです。Arduino IDEで利用できる様々なライブラリを用いることでセンサーやデバイスとの接続を容易にします。

DS18B20とは

今回使用する温度センサです。
Amazonにて5本で1000円というかなり安価に手に入りますし、1-wireインターフェースといって1本の信号線でデータのやりとりができたり、複数のDS18B20を1本の信号線で接続して制御できたりなど使い勝手がかなり良かったです。

前提

今回のシステムを構築するにあたっての前提条件としてはArduino IDEでESP32を用いたDS18B20の開発環境が整えられていることです。

検索すると多くの記事がでてきますが、私は以下の記事を参考にしました。

• ESP32開発ボード Arduino IDE開発環境の構築
• 温度センサー DS18B20をESP32で動かすメモ

温度センサ(DS18B20)で温度を測ってみる

温度センサ(DS18B20)を使って温度を測ってみます。

DS18B20から3本の線が出ており、電源線(赤)・信号線(黄)・GND線(黒)となっております。

ブレッドボートに挿せるようにピンヘッダをハンダ付けしてあげて、ESP32と接続します。

余談ですがハンダ付けしたあとの保護のためにホットボンドを利用しています（左下画像）。

シンプルな1センサに対しての温度計測と表示を行ってみます。

#include <OneWire.h>
#include <DallasTemperature.h>

// 1-Wire設定
#define ONE_WIRE_BUS 4

// 1-Wire接続インスタンスの作成
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);

void setup(void)
{
  // シリアル通信の設定
  Serial.begin(115200);
  
  // 1-Wire接続スタート
  pinMode(ONE_WIRE_BUS, INPUT_PULLUP);
  sensors.begin();
}

void loop(void)
{ 
  delay(500);
  Serial.print("温度測定中...");
  
  // デバイスに対して温度計測をリクエスト
  sensors.requestTemperatures();
  
  // 計測結果をプリント
  Serial.println(sensors.getTempCByIndex(0));
}

ソースはこちらのサンプルコードを参考にしました。
ちょっと変更を入れている点としては、pinMode(ONE_WIRE_BUS, INPUT_PULLUP)によって1-Wireの信号線に対して、ESP32の内蔵プルアップを設定しています。

実際に書き込みを行い、Arduino IDEのシリアルモニタで見てみます。

温度の変化がわかるようにセンサ部を指で温めています。
最初26.44度からスタートし、指で触り始めると温度が上がっていくことを確認しました。

GoogleSpreadSheetでWebアプリをデプロイする

GoogleSpreadSheetでPOSTリクエストを受け付けるWebアプリを作っていきます。

まずスプシを作成し、拡張機能>Apps ScriptからGASを作成します。

今回はESP32から計測した温度データをJSONに詰めて、POSTリクエストを飛ばします。

送信するJSONをあらかじめ以下のように定義しておきます。

今回は2つのセンサからの温度情報を送るため、温度が問題なく取得できたことを確認する属性successと温度情報tempを持つオブジェクトをリストで持つように設計しました。

{
	"data": [
		{
			"success": true,
			"temp": 1.23
		},
		{
			"success": true,
			"temp": 2.34
		}
	]
}

上記のJSONを受け取ってスプシにデータを挿入するスクリプトを書きます。

空行を挿入して、そこに受信した温度データを書き込む仕様としました。

function doPost(e) {
  const params = JSON.parse(e.postData.getDataAsString()); 

  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheets()[0];
  sheet.insertRowBefore(2);
  sheet.getRange(2, 1).setValue((new Date).toLocaleString('ja-JP'));
  sheet.getRange(2, 2).setValue(params.data[0].success ? params.data[0].temp : "err");
  sheet.getRange(2, 3).setValue(params.data[1].success ? params.data[1].temp : "err");

  return ContentService.createTextOutput("OK");
}

それではこちらのPOSTリクエストを受け付けるWebアプリをデプロイします。

デプロイ方法は簡単で以下手順でボタン押下するだけでURLが発行されます。

このURLにPOSTリクエストを投げれば、先程のスクリプトが実行されます。
注意点としては、このURLはデプロイするたびに変わるということと、認証などの仕組みはないため、URLが漏洩すると誰でもアクセスできるので取り扱いには注意してください。

ESP32からデータをアップロードする

プログラムを作る前に温度センサを冷蔵庫に設置します。

冷蔵庫内部にセンサをマスキングテープで付けて、ケーブルを冷蔵庫の外に出してESP32と接続しました。

それではESP32から先程デプロイしたWebアプリに対してPOSTリクエストを送信するプログラムを作成していきます。
ちょっと長くなってしまいましたが、やってることとしてはWi-Fiの接続設定と1分間隔で温度計測とAPIリクエストの実行となっています。

#include <OneWire.h>
#include <DallasTemperature.h>
#include <WiFi.h>
#include <HTTPClient.h>

// 1-Wire設定
#define ONE_WIRE_BUS 4
#define TEMPERATURE_PRECISION 12

// 1-Wire接続インスタンスの作成
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);

// 接続するデバイスのアドレスを指定（以下サンプルソースを利用して取得）
// https://github.com/milesburton/Arduino-Temperature-Control-Library/blob/master/examples/oneWireSearch/oneWireSearch.ino
DeviceAddress refrigeratorDevice = { 0x28, 0xC3, 0x9F, 0x46, 0xD4, 0x09, 0x76, 0xF9 };
DeviceAddress outsideDevice = { 0x28, 0x75, 0x4B, 0x46, 0xD4, 0x4B, 0x21, 0x5F };

// Wi-Fi接続設定
char ssid[] = "xxx";
char password[] = "yyy";

// リクエストURL設定
char requestURL[] = "GASでデプロイしたWEBアプリのURL";

unsigned long timer;

void setup() {
  // シリアル通信設定
  Serial.begin(115200);

  // WiFi接続スタート.
  Serial.print("Connecting to ");
  Serial.println(ssid);
  WiFi.begin(ssid, password);
  WiFi.setAutoConnect(true);
  WiFi.setAutoReconnect(true);
  // WiFi接続完了まで待機.
  while (WiFi.status() != WL_CONNECTED)
  {
    delay(500);
    Serial.print(".");
  }
  // WiFi接続完了.
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());

  // 1-Wire接続スタート
  pinMode(ONE_WIRE_BUS, INPUT_PULLUP);
  sensors.begin();
  sensors.setResolution(refrigeratorDevice, TEMPERATURE_PRECISION);
  sensors.setResolution(outsideDevice, TEMPERATURE_PRECISION);

  // タイマ初期化
  timer = 0;
}

void loop() {
  // 1分間隔で実行
  if (timer < millis()) {
    timer = millis() + 60 * 1000;
    measureAndRequestSend();
  }
}

void measureAndRequestSend() {
  // デバイスに対して温度計測をリクエスト
  Serial.print("温度測定中...");
  sensors.requestTemperatures();

  float refrigeratorTemp = sensors.getTempC(refrigeratorDevice);
  float outsideTemp = sensors.getTempC(outsideDevice);

  // 計測結果をプリント
  Serial.print(refrigeratorTemp);
  Serial.print(", ");
  Serial.println(outsideTemp);

  // 送信するJSON文字列生成
  String requestStr = String("{\"data\":[") +
                      "{\"success\":" + String(refrigeratorTemp != DEVICE_DISCONNECTED_C) + ",\"temp\":" + String(refrigeratorTemp, 2) + "}," +
                      "{\"success\":" + String(outsideTemp != DEVICE_DISCONNECTED_C) + ",\"temp\":" + String(outsideTemp, 2) + "}]}";

  // データ送信
  apiRequest(requestStr);
}

void apiRequest(String body) {
  // 指定されたデータを送信する
  if (WiFi.status() == WL_CONNECTED) {
    HTTPClient http;
    http.setFollowRedirects(HTTPC_STRICT_FOLLOW_REDIRECTS);
    http.begin(requestURL);
    http.addHeader("Content-Type", "application/json");
    int httpResponseCode = http.POST(body);
    if (httpResponseCode < 0) {
      Serial.print("通信に失敗しました。");
      Serial.println(httpResponseCode);
    }
    http.end();
  } else {
    Serial.println("Wi-Fi接続に失敗しました。");
  }
}

こちらのプログラムをESP32に書き込み、実行してみます。

するとスプシ側に送信したデータが書き込まれていることを確認できました。

試しに1日動かして結果をプロットしてみました。
室内温度は昼間になるにつれて温度が高くなっていき、15時過ぎごろにピークを迎えます。
冷蔵庫温度は細かな上がり下がりが確認できますが、1日中一定を保っています。おそらく基準の温度があってそこを超えたら冷却をON、下回ったらOFFにするような制御が入っているのではと予想できます。

まとめ

IoTで取得したデータをクラウド上にストアすることを考えると、AWSだったりのクラウドサービスを使ったりやHerokuなどのPaaSを利用する方法が考えられますが、インフラの構築コストだったり、利用料金がかかってしまいます。

ですが今回紹介したGoogleSpreadSheetとGASを利用する方法では、無料ですし、たった数行のコードを書くだけでWebアプリをデプロイできるのが強みだと思います。

またGASのトリガーを使えば定期的にスクリプトを実行できるので、例えば温度が規定値を上回った場合にメール通知を送ることなども実装できるので、応用すれば色々できそうです。

参考URL

• ESP32開発ボード Arduino IDE開発環境の構築
• 温度センサー DS18B20をESP32で動かすメモ
• DS18B20 Programmable Resolution 1-Wire Digital Thermometer
• 外部からJSONをPOSTするだけでGoogleSpreadSheetにデータを書き込む

そんな私が、無人航空機操縦士試験（二等）に合格するまでの体験記をご紹介します。

↓著者の相棒 DJI社製 Mini3

1. 無人航空機操縦士試験（二等）とは

無人航空機操縦士試験（二等）とは、ドローン等（無人航空機）に関する唯一の国家資格になります。

2022年12月5日から技能証明制度が施行されており、ドローン等を飛行させるのに必要な技能（知識及び能力）を有することを証明する資格制度です。

資格の取得には、以下の３つの試験をクリアする必要があります。

仮免試験がない車の免許をイメージして頂くと近いと思います。

• 学科試験
• 実地試験
• 身体検査

また資格には、以下の限定(車で言うとAT限定のようなもの)があり、限定解除する場合は、通常の資格に追加して講習や試験が必要になります。

無人航空機の種類（機体の種類）

回転翼航空機（マルチローター）

回転翼航空機（ヘリコプター）

飛行機（固定翼）

無人航空機の種類（機体の重量）

上記の機体の種類それぞれに対して最大離陸重量25kg未満

飛行の方法

目視内飛行(モニターを見ず、機体を目視しながら飛行させること)

昼間飛行

著者は、回転翼航空機（マルチローター）で資格を取得し、他の限定解除は行っておりません。

2. 無人航空機操縦士のメリットと有用性

この資格は以下のメリットがあります。

1. 認証済みの機体と合わせて申請することで、（ルールの範囲内で）自由に飛ばすことができる。
2. 国土交通省への飛行許可申請の際に、一部手続きを省略できる。
3. 建設業等で入札条件に含まれている。

著者も飛行許可申請を出していますが、実際に手続きを一部省略して申請しています。

しかしドローンを取り巻く環境は、まだ成長途中です。国家資格を利用して、（ルールの範囲内で）自由に飛ばすことができるようになるには、以下の２つをクリアすることが必要です。

• 操縦者技能証明（無人航空機操縦士の資格）
• 型式認証済みの機体 or 機体認証済みの機体

現在、個人で買えるような価格帯で、型式認証をクリアしている機体が少なく、この資格が効力を発揮できない状況となっております。

今後、メーカーが基準を満たす機体を幅広く製造してくれることを願っています。

※なお、上記認証済みでない機体でも、国土交通省への飛行許可申請を実施すれば、（ルールの範囲内で）ドローン自体は飛ばせます。

著者がドローンに興味を持った経緯として、物流を担うシステムを担当したことがきっかけとなっています。物流業界は2024年問題をはじめ、あらゆる課題がある業界です。そして、ドローンはその解決策の1つであると同時に、複雑な法制度や制約に縛られているということを知り、自分で勉強してその壁を超えたいと思うようになりました。ちょうど国家資格が始まったこともあり、国家資格を取りながら体系的に学びたいと思い、今回チャレンジすることにしました。

3. 資格取得までの道のり

資格取得までの道のりは、以下の通りです。全体で2か月程かかりました。

こちらの順で詳細を紹介させて頂きます。

1. ドローンスクールに入会
2. 学科試験の講習→受験
3. 実地試験の講習→受験
4. 身体検査
5. 証明書交付

1.ドローンスクールに入会

まずは、無人航空機操縦士試験に対応しているドローンスクールを選びました。

著者は、株式会社モビリティテクノのドローンマスターズスクール(通称DMS)を選びました。

公式サイト：https://drone-school.mobility-techno.jp

選んだ理由は、「都内にある」「価格が安い」「練習場が利用できる」という理由でした。当時の基準で選んでいるため、選ぶ際は最新の情報で確認をお願いします。2023年12月22日時点では、二等資格の初学者コースは25万円(税込)に設定されておりました。

2.学科試験の講習→受験

スクールに入校後は、e-learningで学科試験の勉強が始まります。

全体で約8時間＋確認テストの内容になっています。

1. はじめに
2. 無人航空機操縦者の心得
3. 無人航空機に関する規則
4. 無人航空機のシステム
5. 無人航空機の操縦者及び運航体制
6. 運行上のリスク管理

受験はテストセンターで受験しました。

無事、一発合格できました。

3.実地試験の講習→受験

実地試験は以下のようなスケジュールです。

1,2日目は東京足立校で実施し、3日目の試験は埼玉浦和校で実施しました。

実施講習の中で、操縦時間が目一杯あるわけではなく、技能に不安を感じていたので、モバイルアプリで300円ほど課金して、練習もしました。

実地試験では、満点合格で試験管の人に技能を褒めて頂けました。

試験会場の様子はこちらです。

4.身体検査

著者は、普通自動車運転免許を持っていたため、システム上の手続きで完了しました。

検査内容は、以下のように定められています。

https://ua-remote-pilot-exam.com/

身体検査は、①有効な公的証明書の提出、②-1医療機関の診断書の提出（一等25㎏未満限定及び二等）、②-2医療機関の診断書の提出（一等25kg以上）、③指定試験機関の身体検査受検（一等25㎏未満限定及び二等）のいずれかの方法で受検ができます。

5.技能証明書交付

ここまでで、技能証明書交付までの要件が完了したため、システム上で発行手続きを行い、2週間ほどで手元に証明書が届きました。

4. ドローンを飛ばしてみて

ドローンの飛行には、国土交通省への飛行許可申請や、関係各所への許可取り等も行う必要があります。警察署に連絡したり、土木管理事務所に使用許可申請を提出したりすることもあります。

また、著者は新たにドローンを購入したため、機体登録、リモートID（車のナンバーのようなもの）の登録など、様々な手続きを行っています。

それらを完了させて、実際に撮影した写真はこちらになります（実際は映像ですがここでは静止画で紹介となります）。

5.まとめ

ドローンを飛ばすのはとても楽しく、やってみたら多くの人がはまると思います。しかし、危険性も高く、法律も複雑です。何も理解しないまま飛行させると、知らぬ間に違法な飛行として、警察のお世話になる可能性や、重大な事故に発展する可能性もあります。

そのため、しっかり勉強したうえで取り組む必要があると思います。また、ドローンを飛ばしているだけではなかなか価値が生まれませんが、武器の1つになると思っています。これからも、楽しみながら、よりよいドローンの活用を考え実践していきたいと思います。

初めまして。製造（PLMソリューション）所属/九州在住　の水田です。

夏の自由研究連載2023の第3弾の方を執筆させていただきます。

今回が技術ブログ初投稿になります。不慣れな部分もありますが、なるべく分かりやすく書くように心がけていますので、最後までお付き合いください。

研究テーマについて

漠然と

• ArduinoやRaspberry Piを触ってみたい
• ArduinoにWebサーバを構築してみたい

…と思ったのでRaspberry Piに立てたWebサーバのブラウザから好きな文字列を入力してArduinoに接続したLCDに表示する までをやっていきます。

最終的には、在宅勤務している部屋のドアに設置して、スマホ経由でブラウザにアクセスして会議中であることを表示できればいいなとか考えています。

あと、色々とハマったのでその辺りも書いておこうかと思います。

※長くなるのでRaspberry PiやArduinoの基本的な部分の話は、割愛しています。

構成(予定)

最終的に以下の図のような構成を予定しています。

Arduino→LCDへの表示

まずは、LCDに任意の文字列を表示してみます。

使用するArduinoについて

家にあるArduinoを使おうとしたのですが、どのLCDを買えばよいのかがよく分からなかったので、新しくスターターキットを購入しました。値段の割に基本的なセンサー類からLCDやコントローラーまでついている上にサンプルコードまでついていて分かりやすいです。

ELEGOO Arduino用UNO R3スターターキット レベルアップ チュートリアル付 mega2560 r3 nanoと互換 [並行輸入品]

以下、実際につないで動かしてみた画像と使用したソースコードです。

// LCDを使用するためのライブラリをインクルード
#include <LiquidCrystal.h>

// Arduinoから出力するPin番号とLCDのPin番号との対応を定義
const int rs = 7, en = 8, d4 = 9, d5 = 10, d6 = 11, d7 = 12;

// LCDの初期化（使用するPin番号の指定）
LiquidCrystal lcd(rs, en, d4, d5, d6, d7);

void setup() {
  lcd.begin(16, 2);             // 桁数と行数の指定
  lcd.clear();                  // 画面のクリア
  lcd.setCursor(0, 0);          // カーソル位置の指定（1行目の1文字目に設定）
  lcd.print("Hello, World!");   // 文字出力
}

void loop() {
  lcd.setCursor(0, 1);          // カーソル位置の指定（2行目の1文字目に設定）
  lcd.print(millis() / 1000);   // 文字出力
  lcd.print(" [sec]");
}

Raspberry Pi の準備

Raspberry Piについては、昔購入したModel Bを使用。OSの状態とか覚えていないので、まずは付属のSDカードよりRaspian（wheezy）を再インストール＆以下の作業を実施

• packageの更新
• python3とpipの更新
• pyserial（＝シリアル通信で使用するPythonモジュール）のインストール

packageの更新

apt-getがうまく動かなかったので苦労しました。

色々と調べてみるとapt-getでパッケージを更新する際に使用するミラーサイトのURLが古いのが原因だったみたいです。以下に記載があるURLを最新のURLに書き換えて対応しました。

• /etc/apt/sources.list
• /etc/apt/sources.list.d/collabora.list

python3とpipの更新

apt-getでインストールしようとするとエラーになるのでこっちも苦労しました。色々と調べた結果、pyenvを使用してインストールするとうまくいきました。

pyserial（＝シリアル通信で使用するPythonモジュール）のインストール

pipでインストールしたらすぐに終わりました。

Raspberry Pi →Arduinoへシリアル通信

Raspberry PiとArduinoの準備が大体整ったので試しにシリアル通信を行ってみます。
以下のような文字列送信用のPythonを用意します。

import serial

ser = serial.Serial()
ser.port = '/dev/ttyACM0'
ser.baundrate = 9600
ser.open()

data = 'NOW MEETING...  16:30 - 17:30'
ser.write(data.encode())
ser.close()

Arduino側は、上記コードを以下のように書き換えます。なお、送られてくる文字列は1文字目～16文字目までを1行目に、17文字目～32文字目までを2行目に出す想定にしています

// LCDを使用するためのライブラリをインクルード
#include <LiquidCrystal.h>

// Arduinoから出力するPin番号とLCDのPin番号との対応を定義
const int rs = 7, en = 8, d4 = 9, d5 = 10, d6 = 11, d7 = 12;

// LCDの初期化（使用するPin番号の指定）
LiquidCrystal lcd(rs, en, d4, d5, d6, d7);

void setup() {
  lcd.begin(16, 2);             // 桁数と行数の指定
  lcd.clear();                  // 画面のクリア
  lcd.setCursor(0, 0);          // カーソル位置の指定（1行目の1文字目に設定）
  lcd.print("INPUT...OK");      // 文字出力
  Serial.begin(9600);           // ボーレートの設定
}

void loop() {
  if (Serial.available())                         // シリアル通信が有効かどうかの確認
  {
    String input = Serial.readString();           // 文字列取得
    lcd.clear();                                  // 画面のクリア
    lcd.setCursor(0, 0);                          // カーソル位置の指定（1行目の1文字目に設定）
    lcd.print(input);                             // 文字出力

    String input2 = String(input.substring(16));  // 文字列の後半部分を抜き出し
    lcd.setCursor(0, 1);                          // カーソル位置の指定（2行目の1文字目に設定）
    lcd.print(input2);                            // 文字出力
  }
}

以下、結果です。

うまくいっているように見えますが

実は、うまくいっていないんです。。。笑

具体的に書くと

• 上記Pythonファイルを叩いても、LCDが点滅するだけ
• Pythonファイルの内容をPython3のコマンドラインに張り付けて実行
  →LCDに表示される（上記は、この時の写真となります）

調べてみると、Arduino Unoには「USB経由でシリアル通信した場合にDTR端子の状態がLOWであればリセットがかかる」仕様があるらしくこれが原因でLCDがリセットされているようです。DTR端子をHIGHにすればよいのでは？ とは思うので設定してみてはいるのですがなぜかうまくいかない。

仮説

open()後にsleepを入れるとうまくいくのでは？ という仮説が出てきました。
ファイル実行では、open→writeまでの処理に間が無いので、open処理完了→DTRリセット処理　のリセット中に書き込みを行っていてうまくいっていないような気がしてきました。

コマンドライン実行では、ser.open()→数秒後にser.writeを実行という流れなので、数秒の間にリセット処理が完了→LCDへの書き込みがうまくいくという流れのような気がしています。

コマンドライン実行時のopen処理直後のLCDを見ていると、open直後のタイミングでLCDにリセットがかかっているように見えます。試す価値がありそうです。

（open＝シリアル通信開始なので当たり前と言ったら当たり前ですが）、、、

以下のようにsleepを2秒入れて実行してみました。

import serial
import time

ser = serial.Serial()
ser.port = '/dev/ttyACM0'
ser.baundrate = 9600
ser.open()
time.sleep(2)

data = 'NOW MEETING...  16:30 - 17:30'
ser.write(data.encode())
ser.close()

結果としてはうまくいきました。仮説が当たっていたみたいです。

個人的には、以下の理由で上記方法は気に入らないのですがひとまず、これで進めます。

• 本来であればDTR端子を何とかする（＝設定やらなんやらで何とかする）のが筋
• sleepで解決するのが力技っぽくて、あまり好みではない

よくよく考えると、、、

sleepを入れない方向でもいいのでは？ と考えています。

まず、Webサーバの方に必要なモジュールをブラウザに表示する内容から考えると以下のようになると考えています。

ブラウザ表示（仮）

• シリアル通信開始（接続ボタン押下）
• シリアル通信終了（切断ボタン押下）
• 文字列送信（送信ボタン押下）

上記のようなUIで考えると、シリアル通信開始～送信ボタン押下までには、タイムラグがあると思います。

仮に接続ボタンを無くしたようなUIであっても、文字列送信部分に入力するのに数秒はかかるはずなので、sleepは無くて良いと想像しています。
（接続ボタン押下からコンマ数秒で入力する超人または、RTA挑戦者は考えていないです）

そのため、この後の方向としては、以下のようになると考えています。

• 文字列送信については、sleepを入れない形でひとまず実装を進める
• 上記実装で問題が発生した場合、改めてsleepを入れることを検討する

おわりに

Webサーバは？

という声が聞こえてきそうですが、これ以上自由研究に作業時間が取れそうにないので今回はここまでとさせていただきます。今後執筆する機会があれば、続きを書きます。

メモ：残作業

• Webサーバ構築（Apache?nginx?マシンスペックが弱いので軽いのがいい）
• マイコンへの書き込み及び、基盤へのはんだ付け作業
• マイコンとRaspberry Piを設置するようの箱を用意（木？ 近所に3Dプリンターが使える店があるのでプラスチック？ )
• ドアへの設置

あとがき

初めてArduinoやRaspberry Piに触ってみましたが色々とトラブルが続いて思うように進まなかったです。ハードウェア周りは、未経験だったので、良い経験にはなったかなと考えています。

あと、今回のような誰かに見せるようなものを書いたりすると、アウトプットの仕方を考えたりする練習にもなると思うので、書いたことが無くて二の足を踏んでいるような方がいれば、挑戦してみると良い経験になるかと思います。

では、また執筆する機会があればお会いしましょう

フューチャーアーキテクトでアルバイトをしている寺迫です。

代表的な音声合成サービスの使用方法や性能の違いについて調査しました。

音声合成(text-to-speech)の概要

• コンピュータを用いて音声を生成する技術(主に人間の発話音声)
• 深層学習・強化学習における音声合成モデルの性能向上により、自然な音声を生成することが出来る
• 応用分野
  - 音声案内システム：券売機や電話案内、ナビゲーション等に利用される
  - バーチャルキャラクター:キャラクターのセリフの作成に利用される
  - 失声症の方への支援

想定読者

• 音声合成サービスを試してみたい人
• 品質の良い音声合成を行いたい人
• 音声合成サービスの差異を確認したい人

記事に含まれない内容

• 音声合成モデルの説明
• 音声合成時の具体的な読み間違い・イントネーションなどの調整方法
• 英語言語の音声合成

2. 音声合成サービス比較

2.1 比較方法

比較サービス一覧

音声合成サービスのうち、（1）商用利用可能 （2）API提供あり（3）公式ドキュメントの充実（4）発音調整が可能なものを比較しました。

• Google Cloud Platform text-to-speech(以下、GCP TTS)
• Amazon Polly(以下、Polly)
• Azure text-to-speech(以下、Azure TTS)
• VOICEVOX

比較観点

8項目を比較観点としました。

• 声色の種類
• 音声合成の品質
  • 音質
  • ノイズ
  • 読み間違い
  • なまり(アクセント、イントネーション)
• 辞書機能
• 音声調整の容易さ
• 実装負荷(Software Development Kitの有無)
• 利用料金
• クォータリクエスト上限
• 入力文字制限

比較に使用したテキストデータ

平均100文字の日本語テキスト約35文で品質の評価を行いました。

2.2 比較結果詳細

声色の種類

声色の種類はVOICEVOXが多いです。アニメからアナウンスまで多彩な状況にマッチする声色が揃っています。

GCP TTS、Polly、Azure TTSはアナウンス、会話音声に向いている声色の種類があります。

品質

Azure TTS > Polly > GCP TTS > VOICEVOXの順番で合成音声の品質が良いです。VOICEVOXはノイズが発生したり、イントネーションが不自然な時があります。Azure TTS、Polly、GCP TTSに関して、無調整だと少し不自然なところがあります。しかし、アクセント、イントネーションの調整によって、自然な音声を生成できます。

辞書機能

GCP TTS以外辞書機能を備えています。登録できる単語数の上限が決められていることや、辞書ファイルをpublicなURIに公開が必要など扱いづらいところがあります。

利用料金

VOICEVOXは一部の声色の商用利用が有料であるが基本無料です。

GCP TTS、Polly、Azure TTSは無料枠を除き、同一料金の従量課金です。

実装負荷

GCP TTS、Polly、Azure TTSは、Software Development Kit(SDK)が準備されているため、容易に実装することが可能です。

音声調整の容易さ

Polly、AzureTTSで使用できる「カナ」を用いた、音声調整はとても直観的で優れています。GCP TTSでの音声調整は国際音素記号を使用が必要なためで学習コストと調整コストが高いです。

カナを用いた発音調整(読み間違い+アクセント)

飴と雨のアクセント例
「雨」は「ア」が高く「メ」が低い、反対に「飴」は「ア」が低く「メ」が高く発音される。

# 雨が降る
<phoneme alphabet="x-amazon-pron-kana" ph="アメ">雨</phoneme>が降る

# 飴を食べる
<phoneme alphabet="x-amazon-pron-kana" ph="アメ'">飴</phoneme>を食べる

橋と箸のアクセント例
「橋」 の「ハ」は低く、「シ」は高く、 「箸」 の「ハ」は高く、「シ」は低く発音される。

# 橋を渡る
<phoneme alphabet="x-amazon-pron-kana" ph="ハシ">橋</phoneme>を渡る

# 箸を使う
<phoneme alphabet="x-amazon-pron-kana" ph="ハシ'">箸</phoneme>を使う

VOICEVOX、GUI上での音声調整

Azure、GUI上でのイントネーション修正

APIクォータ

GCP TTS、Polly、Azure TTSは申請することで上限を引き上げることが出来ます。

SpeechSynthesisTaskとStartSpeechSynthesisTaskの違い

合成音声の最大長

万単位文字の音声合成を行う場合Polly、Azure TTSを使用する必要があります。

2.3 比較結果まとめ

音声合成サービスを比較した結果の長所、短所をまとめました。

IaaSに依存しない場合、Azure TTS > Polly > GCP TTS > VOICEVOXの順でお勧めです。

3. おわりに

本記事ではアナウンス、朗読の仕様用途を想定した比較検証の結果をまとめました。

生成モデルは日進月歩で性能が向上し、SOTA(Steate of the art)が続々と塗り替えられています。deep modelの音声合成は特段修正せずとも違和感が少なく驚きました。しかし、イントネーションについては調整を行わなければいけない場合が多少ありました。今後の音声合成モデル改善に期待したいです。

付録に記載した、リンク集は他の記事で見当たりませんでした。サンプル音声の再生や音声合成のデモを簡単に触ることができるのでぜひ試してほしいです。

本記事が音声合成を用いてサービスを作成する人の助けになると幸いです。

4. 付録

4.1 各サービス　SAMPLE・DEMO一覧

※以下のsample・demoは音声の品質確認用途以外の目的で使用できないため注意が必要

• XMLの一種
• 音声合成の制御を行うことができる
• サービスによって独自のタグ(制御方法)がある
• W3Cにおいて標準化されている
• polly SSML タグ説明ドキュメント
  

  # polly SSMLの一例 <speak>本日、<phoneme alphabet="x-amazon-pron-kana" ph="セカイホケンキカン">世界保健機関</phoneme>が記者会見を開いた。</speak>

はじめに

本記事は春の入門祭り2日目の記事となります。
今日はM5Stackを使ったお家電子工作の沼へ誘いたいと思います。

過去にも電子工作連載があり、Futureでは活発にお家電子工作をやっております。

https://future-architect.github.io/articles/20220404a/

何を作るか考える

お家電子工作はワクワクが原動力なので、何かワクワクするものを作りたいなーと考えてみました。

うーんと考えてみたところ、この3年間コロナもあり海外に全然行ってないなーと。

海外に行くときのワクワクはまず空港に到着してフライト情報を眺めることから始まります。

じゃあ、自分の住んでいる周辺を飛ぶ飛行機の情報を表示することで、その飛行機に思いを馳せてワクワクするんじゃないかと考えました。

必要なもの

• M5Stack Basic
• SDカード（16GB以下）
• Wi-Fi環境
• VSCode

M5Stackはいいゾ

とりあえずお家で電子工作やIoTをやってみたい方はぜひ1台持っておくとよいです。ほぼ何でもできます。

• ESP32ベース
  • 簡単にWi-Fiが使えるのでIoTにもってこいです。
    • 処理も早いです。
• ノーコードでもいける
  • GUIで簡単に作ることもできます。
  • https://flow.m5stack.com/
• 公式が凄い（語彙力）
  • とりあえず、公式がM5Stack売り始めからめっちゃ頑張ってます。
  • めっちゃ拡張機能出してます。
    • https://www.switch-science.com/collections/m5stack
  • 自動水やりとかできます。
    • https://www.switch-science.com/products/6913

学生時代にM5Stack拡張して、赤外線サバゲー作ってたりもしました。

https://www.youtube.com/watch?v=deW3GmdMe_M

環境構築

VSCodeは公式ページからインストールして下さい。
VSCodeの拡張機能であるPlatformIO IDEを使って開発を行います。
PlatformIO IDEの導入はこちらの記事を参考にして下さい。

プロジェクトの作成

拡張機能のインストールが終わると、Welcome画面が出てきます。
「New Project」からプロジェクトを作成しましょう。

• Name: Future_Tech_Blog（なんでもよいです）。
• Board: M5Stack Core ESP32
• Framework: Arduino

以下のようなディレクトリ構成でプロジェクトが作成されます。

ライブラリのインストール

今回は以下のライブラリを使用します。

• M5Stack.h
  • M5Stackの各種機能を使うためのライブラリ
• Wi-Fi.h
  • Wi-Fiに接続するためのライブラリ
• HTTPClient.h
  • GETリクエストを送るためのライブラリ
• ArduinoJson.h
  • JSONを扱うためのライブラリ
• time.h
  • 時刻を扱ったり、変換したりするためのライブラリ

PlatformIOでのライブラリインストールは以下の手順で行っていきます。

PlatformIO Home画面から「Libraries」を選択します。

M5Stack.hを例にライブラリを検索します。

該当のライブラリをクリックします。

「Add to Project」からプロジェクトへ追加します。

「Select a project」から作成したプロジェクトを選択し、「Add」を押すことで追加できます。

これをあとArduinoJsonとTimeに対して行うことで準備完了です。
HTTPClientやWi-Fiに対しては不要です。

Flightrader24を理解する

Flightrader24は世界中のフライト情報を取得できます。

iOSやAndroidのアプリもあり、触ったことがある人も居るのではないでしょうか？

Flightrader24ではREST APIも公開していて、以下のURLにGETリクエストするとJSONでデータを取得できます。

http://data-live.flightradar24.com/zones/fcgi/feed.js?adsb=1&mlat=1&faa=1&flarm=1&estimated=1&air=1&gnd=1&vehicles=1&gliders=1&array=1

各クエリパラメータの説明は以下に詳しく書いてあります。
JSON - Flightradar24 から飛行中の航空機情報を取得！

ここでbounds=というクエリパラメータを追加し、緯度（北）・緯度（南）・経度（西）・経度（東）の順で値を入れていくとフライト情報を取得するエリアを指定できます。

今回は大崎がある品川区の端から端を指定してみます。

どうやって緯度・経度を取得するかって？ それはChat-GPTにお任せです。

こういう調べても出てきそうにない情報は初手Chat-GPTがおススメです。
緯度・経度が得られたのでクエリパラメータを指定したURLが以下になります。

http://data-live.flightradar24.com/zones/fcgi/feed.js?bounds=35.63,35.59,139.71,139.76&adsb=1&mlat=1&faa=1&flarm=1&estimated=1&air=1&gnd=1&vehicles=1&gliders=1&array=1

これでGETしてみたところ、取得できませんでした。
さすがに範囲が狭すぎたようなので小数点第二位を四捨五入して取得したところ、以下のようなフライト情報が取得できました。

['2fe70675', '4D23DB', 35.5631, 139.7589, 329, 0, 1, '', 'T-RJTT172', 'GL7T', '9H-VIL', 1681552816, 'XSP', 'HND', 'VJT735', 1, 0, 'VJT735', 0]

各項目の意味は先ほどのリンクを参考にしてください。
JSON - Flightradar24 から飛行中の航空機情報を取得！

とりあえず、10: 便名、11: 時刻、12: 出発空港, 13: 到着空港がわかれば楽しめそうです。

M5Stack側のコードを作成

M5Stackはsetup()とloop()の2つの大きな関数による構造となっております。
setup()は最初の1度しか呼ばれず、残りはloop()が名前の通り永遠に呼ばれるようになっています。

コード全体はこちらのGitHubに置いてあります。

https://github.com/bigface0202/flightM5rader

setup側

setup側は起動後の1度しか呼ばれないため、主に接続を確立したり、画面の初期設定を行うなどの処理を記述します。

M5Stackのディスプレイ設定

M5Stackのディスプレイには文字や画像を表示できます。
その初期設定を以下のように記述します。

// M5Stackの初期化
M5.begin();
// フォントサイズ
M5.Lcd.setTextFont(4);
// フォントカラー
M5.Lcd.setTextColor(WHITE);
// 文字の初期位置
M5.Lcd.setCursor(0, 0);

Wi-Fiへ接続

今回はHTTPリクエストを投げる必要があるため、Wi-Fiへの接続は必須となります。
WIFI_SSIDとWIFI_PASSWORDを自宅のWi-Fiの情報に書き換えることで接続できるようになります。
また、5GHz帯は接続不可能なため2.4GHz帯のWi-Fiを選んで下さい。

// WiFiに接続
WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
int _cursorX = 0;
M5.Lcd.print("Connecting to Wi-Fi");
// 接続を試みている状態を画面に表示
while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    M5.Lcd.setCursor(0 + 5 * _cursorX, 30);
    M5.Lcd.print(".");
    delay(300);
    _cursorX++;
    if (_cursorX > 320) {
      _cursorX = 0;
    }
}

loop側

loop側は主に処理をさせたい内容を記述していきます。
今回の場合だと、フライト情報の取得とその情報の変換・表示になります。

リクエストを投げる

GETリクエストは以下のように投げることができます。
毎回、取得できるとは限らないのでHTTP_CODE_OK以外の時はエラーコードを表示するにようにしています。
また、GETリクエストを送る際はdelayを最後に挟むようにしてください。
delayを入れないとマシンガンリクエストを送ることになり、APIサーバーに対して負荷をかけてしまうため大変よろしくないです。

HTTPClient http;
String apiAddress = "http://data-live.flightradar24.com/zones/fcgi/feed.js?bounds=35.6,35.5,139.7,139.8&adsb=1&mlat=1&faa=1&flarm=1&estimated=1&air=1&gnd=1&vehicles=1&gliders=1&array=1";

void loop() {
    String payload;
    http.begin(apiAddress);
    int httpCode = http.GET();

    if (httpCode > 0) {
        if (httpCode == HTTP_CODE_OK) {
            // 以下、取得したデータの処理
            // ...
    } else {
        M5.Lcd.setCursor(0, 0);
        M5.Lcd.print("HTTP GET ERROR: ");
        M5.Lcd.println(httpCode);
        delay(5000);
    }
    // delayを入れ忘れるとマシンガンリクエストになるので、忘れずに
    delay(5000);
}

取得したJSONの処理と表示

Flightrader24にリクエストを送って取得した情報を表示していきます。
基本的に取得した配列に対して、ループで3秒ごとに表示していく処理になります。
1点だけ注意したいのが、リクエストを投げて得られる時刻がUNIX時間なので人間が読める時間に変換する必要があり、そちらの関数unix2datetimeは後述します。

// JSON取得用の変数
DynamicJsonDocument doc(4096);
// リクエストで取得した情報を格納
payload = http.getString();
// String -> JSON
deserializeJson(doc, payload);
// 配列の大きさを取得
int len = doc["aircraft"].size();
// 配列の数だけフライト情報を表示
for (int i = 0; i < len; i++) {
    String flightName = doc["aircraft"][i][10];
    time_t unixTimeUTC = doc["aircraft"][i][11];
    String departure = doc["aircraft"][i][12];
    String arrival = doc["aircraft"][i][13];

    // Unix timeから日本時間へ変換
    String dateTimeString = unix2datetime(unixTimeUTC);
    // 表示
    M5.Lcd.setCursor(0, 0);
    M5.Lcd.print("Flight Name: ");
    M5.Lcd.println(flightName);
    M5.Lcd.print("Time: ");
    M5.Lcd.println(dateTimeString);
    M5.Lcd.print("Departure: ");
    M5.Lcd.println(departure);
    M5.Lcd.print("arrival: ");
    M5.Lcd.println(arrival);
    // 3秒待つ
    delay(3000);
    // 画面初期化
    M5.Lcd.fillScreen(BLACK);

UNIX時間を変換する

Chat-GPTマジ便利。
要所要所で詰まったらChat-GPT先生にお任せしたほうが早いです。

String unix2datetime(time_t unixTime) {
  time_t unixTimeJTC = unixTime + 32400;
  struct tm *tmTime = localtime(&unixTimeJTC);
  char dateTimeString[20];
  strftime(dateTimeString, sizeof(dateTimeString), "%Y-%m-%d %H:%M:%S", tmTime);

  return dateTimeString;
}

画像を表示する（おまけ）

ここからは機能的にはあまり関係ないのでおまけになりますが、こうやって遊びを入れることで自分のプロダクトに愛着が沸きます。
現在の状態だと画面にフライト情報の文字だけが表示されて味気ないので、フライト情報のAPIをGETする際に飛行機の画像を表示します。

画像はこちらのフリー素材をサイズ変更（幅160px）してダウンロードし、SDカードにフォルダ（フォルダ名：img）を作成して取り込んで下さい。
取り込み終わったSDカードはM5Stackに挿しましょう。

https://jitanda.com/2014/02/07/j413_6/

また、LavyanGFXをライブラリインストールの手順でやったようにインストールして下さい。

コードでは画像をsprite.pushRotateZoom()で徐々に拡大させることで、近づいてきているようなエフェクトを作ってみます。

#define LGFX_AUTODETECT

#include <LovyanGFX.hpp>
#include <LGFX_AUTODETECT.hpp>

static LGFX lcd;
static LGFX_Sprite sprite(&lcd);

// 画像サイズが違うかもなので、ここはよしなに変えて下さい
int width = 160;
int height = 120;

void setup()
{
    // 初期化処理
    lcd.init();
    lcd.clear(TFT_BLACK);
    SD.begin(TFCARD_CS_PIN, SPI, 20000000);

    // 画像の読み込み
    sprite.createSprite(width, height);
    sprite.drawPngFile(SD, "/img/airplane.png", 0, 0);
    // ...
}

void loop()
{
    // 画像を徐々にズーム
    for (int i = 0; i < 10; i ++) {
        sprite.pushRotateZoom(width, height, 0, i, i);
        delay(100);
    }
    //...
}

できあがったもの

まとめ

こうやってハードウェア込みで自分がワクワクするものを開発できるのがお家電子工作の良いところですね。GPSモジュールなんかもあるので、位置情報のあたりも自動化するなど色々工夫もできそうです。

ぜひ皆さんもLet’s enjoy お家電子工作してください。

明日は井上さんで初めてのセキュリティ情報収集（mjckeck4)です。

アイキャッチは時短だの飛行機38を使わせていただきました。

はじめに

TIG 岸下です。業務でGKE（Google Kubernetes Engine）を利用することがあるのですが、Kubernetesの挙動や仕組みなど如何せん理解が難しいです。

そこで今回は、自分の手でイチからKubernetesを構築することで勉強しようと思ったのが本記事のモチベーションです。

ちょうど自宅にRaspberry Piが3台あったのでRaspberry Piでクラスタを構築していこうと思います。基本的には以下の記事を参考に設定を行っていき、自分の理解を深めるために解説を挟みながら書いていこうと思います。

参考：RaspberryPi 4 にUbuntu20.04 をインストールして、Kubernetes を構築してコンテナを動かす

今回Kubernetes構築するにあたって用意したもの

• Raspberry Pi3 Model B（メモリ1GB）
• Raspberry Pi4 Model B（メモリ4GB）
• Raspberry Pi4 Model B（メモリ8GB）
• SDカード（64GB）x 3
• 5ポートスイッチングハブ（BUFFALO LSW6-GT-5EPL/NBK）
• LANケーブル x 4（CATはバラバラ）
• キーボード
• マウス

各種Raspberry Piの電源はコンセントから取っています。

ラズパイの設定

• 3台共通のものと、3台それぞれで設定する内容があるので注意して下さい。

OS

• OS: Ubuntu 20.04LTS（3台共通）

Raspberry Pi Imagerを使うと簡単にSDカードへOSを焼くことが出来ます。
SDカード3枚全てにUbuntu 20.04LTSを焼きます。

Kubernetesのバージョン

• v1.25.0

初期設定（3台共通）

ラズパイにOSをインストールしたSDカードを差し込み、パッケージを最新版にしておきます。

sudo apt update
sudo apt upgrade -y

ネットワーク周り

物理的な構成図

※Desktop PCはラズパイ達とSSHするために繋いでいます。Kubernetesの構成には必要ありません。

で構成しております。

ネットワークの設定（ラズパイ3台それぞれで）

上記のIPアドレスを各ラズパイに割り振って固定化します。
以下のファイルを作成します。

sudo vi /etc/netplan/99-network.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.1.101/24 # ラズパイ毎でIPを変更してください。（末尾がそれぞれ101, 102, 103になります。）
      gateway4: 192.168.1.1 # 自宅のルーターからゲートウェイを調べて下さい。ここを間違えるとラズパイはネットに繋がらなくなります…
      nameservers:
        addresses:
          - 192.168.1.1

作成したら、適用します。

sudo netplan apply
ifconfig
# eth0の部分が所望のIPアドレスに変わっていることを確認。
# ifconfigが無ければ
# sudo apt install ifconfig
# でインストール

SSHの設定（デスクトップPC）

IPアドレスの固定化が完了したので、ここからはSSHで操作を行うようにします。

※SSHは利用しなくても設定できますが、3台分のラズパイのディスプレイを切り替える作業のストレスが無くなります。

VSCodeのRemote SSHを用意

デスクトップPCにてVSCodeをインストールして、「拡張機能」からRemote - SSHをインストールしてください。

SSH構成ファイルを用意

VSCodeウィンドウ左下の「＞＜」をクリックして、「SSH構成ファイルを開く」からconfigを開いて以下のように設定して保存します。

Host rpi4_8
    HostName 192.168.1.101
    User ubuntu

Host rpi4_4
    HostName 192.168.1.102
    User ubuntu

Host rpi3
    HostName 192.168.1.103
    User ubuntu

• Host名も好きに変更して頂いて構いません。
• IPアドレスは自宅の環境に合わせて適宜変更して下さい。
• User名を変更している場合も適宜変更して下さい。

各ラズパイに接続する

VSCodeウィンドウ左下の「＞＜」をクリックして、「ホストに接続する」からホスト名を選んで接続します。
初回は接続キーの登録が行われるため、キーが表示されたら「続行」を押し、あとはログイン用のパスワードを入力すると接続できます。
複数台同時に接続できるので、3画面分用意しておけばデスクトップPC側からラズパイの操作が可能となります。

ホスト名の変更（ラズパイ3台それぞれ）

ここからはまたラズパイの操作となります。
以下のホスト名を割り振っていきましょう。

sudo hostnamectl set-hostname mas.example.com # 各々のラズパイでhostnameは変える
hostname # 変更の確認作業

/etc/hostsの設定（ラズパイ3台共通）

ホスト名とIPアドレスを対応させるために、etc/hostsに以下の内容を追記します。

sudo vi /etc/hosts

# ...

192.168.1.101 mas01 mas01.example.com
192.168.1.102 work01 work01.example.com
192.168.1.103 work02 work02.example.com

# ...

これによって、ネットワークの名前解決ができるようになります。

余談

以下はKubernetesの設定とは関係のない話なので余談ですが、ターミナル上で

ssh work01.example.com

と打てば、192.168.1.102に接続できます。
これはDNS（Domain Name Service）でも同じことが行われています。
DNSについては、ぜひTIG西田さんのNW入門を読んでみてください。ハンズオン形式でわかりやすいと思います。

IPv6の停止（ラズパイ3台共通）

IPv6は今回利用しないので停止します。
sysctl.confをvimで開きます。

sudo vi /etc/sysctl.conf

下記設定を最後の方へ追記します。
設定を1にすることで停止となります。

#...

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

余談

また余談ですが、最近はKubernetesでIPv4/IPv6デュアルスタックが利用できるそうです。
参考：IPv4/IPv6デュアルスタック

IPv4/IPv6デュアルスタックを利用するとIPv4とIPv6のアドレスの両方をPod及びServiceに指定できるようになります。

なるほど、わからんという感じです。
IPv6自体はIPv4アドレスの枯渇問題を解決するためのプロトコルで、他にもIPv4に対する不満の多くを一挙に解消しようとしています（マスタリングTCP/IP入門編 P.171）。
デュアルスタック機能によって、お互いは仕様の異なるプロトコルスタックですが共存させる仕組みで、やはりどちらのプロトコルも使えるのが美味しいポイントとなるのでしょうか。利用する機会があればまた調べて見ようと思います。

timezone, keymapの変更（ラズパイ3台共通）

タイムゾーンを日本に、keymapを日本語にします。

# タイムゾーンの変更
sudo timedatectl set-timezone Asia/Tokyo

# keymapの変更
sudo localectl set-keymap jp106

Kubernetes周り

ここからKubernetes周りの設定を行っていきます。
基本はkubeadmの設定に沿っていきます。

参考：kubeadmのインストール

iptablesがnftablesバックエンドを使用しないようにする（ラズパイ3台共通）

nftablesバックエンドは現在のkubeadmパッケージと互換性がありません。(ファイアウォールルールが重複し、kube-proxyを破壊するためです。)

だそうです。

# レガシーバイナリをインストール
sudo apt-get install -y iptables arptables ebtables

# レガシーバージョンに切り替える
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
sudo update-alternatives --set arptables /usr/sbin/arptables-legacy
sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy

参考：kubernetes: iptablesがnftablesバックエンドを使用しないようにする

Dockerのインストール（ラズパイ3台共通）

参考：Install Docker Engine on Ubuntu

ターミナルにて以下のコマンドでインストールします。

sudo apt-get -y install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=arm64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-get -y install docker-ce docker-ce-cli containerd.io
# apt-mark holdで、バージョンを固定します。
sudo apt-mark hold docker-ce docker-ce-cli containerd.io

dockerをroot権限無しで実行するためにdockerグループへユーザーを割り当てます。

sudo adduser ubuntu docker
cat /etc/group | grep docker
# 自分のユーザー名が追加されていることを確認

グループ割当を適用するために、一度ログオフ or 再起動をしましょう。
Dockerのバージョンを確認します。

docker version
# Dockerのバージョンが表示されればOK
# グループ割当が適用されていないと、Warningが出る。

dockerの動作確認にhello-worldコンテナを使います。

docker run hello-world
# Hello from Docker!と表示されればOK

kubeadm、kubelet、kubectlのインストール（ラズパイ3台共通）

参考：kubeadm、kubelet、kubectlのインストール

以下のコマンドでインストールします。

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

そもそもこのkubeadm、kubelet、kubectlは何に使われるのでしょうか？

kubeadm

参考：Kubeadm

• Kubeadmはkube initやkubeadm joinといったコマンドを提供するために作られたツールである。
• 最低限実行可能なKubernetesクラスタを立ち上げるために必要なアクションを実行する。
• Kubeadmの設計上、クラスタの立ち上げのみにフォーカスを当てており、マシンへのプロビジョニングまでは考えていない。
  • 同様に、Kubernetesダッシュボードのような種々の便利なアドオンをインストールしたり、モニタリング、クラウド固有のアドオンもスコープ外である。
• 理想的には全てのデプロイのベースとしてkubeadmを使うことで、適合するクラスタの作成が容易になる。

クラスタの立ち上げまではkubeadmが面倒見てくれて、残りのツールとか設定は各々よしなにやりましょうという感じでしょうか。

kubelet

参考：kubelet

kubeletを理解する前に、クラスターの全体像をまず理解する必要がありそうです。

画像引用先： Kubernetesのコンポーネント

グレーの箇所はクラスターになり、先程紹介したKubeadmによって提供されます。

• Control Plane（マスターノード）に対してNode（ワーカーノード）がぶら下がる。
  • 今回で言えば、マスターノードであるラズパイmaster01にワーカーノードであるworker01、worker02がぶら下がる。
• マスターノードはワーカーノードとPodを管理する。
• ワーカーノードはアプリケーションのコンポーネントであるPodをホストする
• Podは1つ以上のコンテナのグループを持ち、Kubernetesにデプロイできる最小単位になる
  • 種々のアプリケーションはPodの中のコンテナ上で動作

で、kubeletですが図を見ると各ワーカーノードの中にkubeletが存在し、ワーカーノードの中で使われることがわかります。どこで使われるかがわかったところでkubeletの機能についてまとめていきます。

• kubeletは、各ノード上で実行される主要な”ノードエージェント”
  • ”エージェント”なので各ノードの中での仲介者で、Podの起動・管理を行う
• kubeletは、PodSpecの観点から動作する
  • PodSpecはPodに関する様々な情報（例えばコンテナの名前やimage）を載せたYAML or JSONファイル
  • PodSpec通りにコンテナが実行・動作されているかを確認することでPodを管理する

kubeletは各Pod内の管理・仲介者と考えておくとよさそうです。

kubectl

参考：kubectlの概要

kubectlはKubernetesクラスターを制御するためのコマンドラインインターフェース（CLI）です。ターミナルからKubernetesクラスターを制御するのに使われます。

cgroupでmemoryの有効化（ラズパイ3台共通）

Kubernetesを利用する際に、cgroupのmemoryを有効化する必要があります。
はて、cgroupとは何なんでしょうか。

Kubernetes内でのcgroup

参考：Linuxカーネルのコンテナ機能［2］ ─cgroupとは？（その1）
参考：Kubernetes で cgroup がどう利用されているか

cgroupはControle Groupの略で、プロセスをグループ化して、そのグループ内に存在するプロセスに対して共通の管理を行うために使われます。例としては、ホストOSが持つCPUやメモリなどのリソースに対して、グループごとに制限をかけることができます。

kubeletの説明の中でPodSpecの話が出てきました。PodSpecのファイルではPod内のコンテナに関する情報を書くわけですが、この中でCPUやメモリの量も制限する（resourcesのlimits）ことが可能です。正にここでcgroupが使われていて、ラズパイの計算リソースに対して、例えば計算リソースをそこまで必要としないPodに対しては制限をすることで、ラズパイのリソースを無駄に食い潰さないようにできます。

有効化の設定

さて、cgroupのメモリーを有効化していきます。
以下のコマンドで確認すると、初期では無効化（末尾が0）されています。

cat /proc/cgroups | grep memory
# 下記が表示される
memory  0       105     0

boot/firmware/cmdline.txtを開き、cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memoryを追記します。

sudo vi /boot/firmware/cmdline.txt

elevator=deadline net.ifnames=0 console=serial0,115200 dwc_otg.lpm_enable=0 console=tty1 root=LABEL=writable rootfstype=ext4 rootwait fixrtc quiet splash cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory

※改行はありません。既に書かれている文の末尾にスペースを空けて追記する形となります。

変更を適用するために再起動します。

sudo reboot
# SSH接続が切れるので、ログインし直す

memoryが有効化されていることを確認します。

cat /proc/cgroups | grep memory
# 下記が表示される
memory  7       107     1

Kubernetesクラスターの作成

参考：kubeadmを使用したクラスターの作成

コントロールプレーンノードの初期化（マスターノードのラズパイのみ）

先程も出てきましたが、コントロールプレーンノード＝マスターノードです。
マスターノードにて操作を行っていきます。

sudo kubeadm init --apiserver-advertise-address=192.168.1.101 --pod-network-cidr=10.244.0.0/16

• apiserver-advertise-address
  • このオプションを利用して明示的にAPIサーバーのadvertise addressを設定します。
  • 明示的に指定しない場合はデフォルトゲートウェイに関連付けられたネットワークインターフェースを使用して設定されます。
• pod-network-cidr
  • Flannelを使用する場合、こちらを指定する必要があります。
  • Flannelはノード間をつなぐネットワークに仮想的なトンネルを構成することで、クラスター内のPod同士の通信を実現しています。
  • /16と広めに設定します（GitHub - flannel-io/flannel）。

初期化後、kubeadm join 192.168.1.101:6443 --token ...という出力が出たら、どこかのテキストエディタにコピーしておきます。
このコマンドはワーカーノードを追加する際に利用します。

もしinit時にcontainer runtime is not runningというエラーが出た場合

参考：Kubeadm unknown service runtime.v1alpha2.RuntimeService #4581

上記ページにエラーについて載っており、内容を読むと以下のように書いております。

In the config.toml file installed by package containerd.io there is the line disabled_plugins = [“cri”] that am guessing creating the issue.

パッケージcontainerd.ioからconfig.tomlをインストールした際に今回のエラーを引き起こす行があるようです（確証ではないみたい？）。
解決方法はマスターノードにて以下のコマンドを実行し、configファイルを削除します。
そして、containerdを再実行します。

# configファイルを削除
sudo rm /etc/containerd/config.toml
# containerdを再実行
systemctl restart containerd

環境変数と入力補完の設定（マスターノードのラズパイのみ）

kubectlをroot以外のユーザーでも実行できるようにするために、以下の設定を行っていきます。

# ホームディレクトリに.kubeディレクトリを作成
mkdir -p ~/.kube
# Kubernetesのadmin.confを.kubeディレクトリのconfigファイルへコピー
sudo cp -i /etc/kubernetes/admin.conf ~/.kube/config
# configファイルの所有者がrootになっているのでk8suserへ変更
sudo chown $(id -u):$(id -g) ~/.kube/config
# .bashrcへ環境変数の追加
echo 'KUBECONFIG=$HOME/.kube/config' >> ~/.bashrc
# コマンドの入力補完を設定
echo "source <(kubectl completion bash)" >> $HOME/.bashrc
# 変更を適用
source ~/.bashrc

Flannelの設定（マスターノードのラズパイのみ）

先程もちょろっと説明しましたが、Flannelはノードを跨いでコンテナ同士が通信できるようにするPodネットワークアドオンになります。
コンテナにはIPアドレスが付与されるのですが、Internal IPなのでそのままだとノードを跨いでコンテナ間で通信できません。これを解決するために、Flannelによってノード間をつなぐネットワークに仮想的なトンネル（オーバーレイネットワーク）を構成することで、Kubernetesクラスター内のPod同士の通信（Podネットワーク）を実現しています。

参考：Kubernetes完全ガイド 3.3.3 Flannel

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

flannelが動作しているか確認します。

kubectl get pods -n kube-flannel
# 以下が出力される
NAME                    READY   STATUS    RESTARTS   AGE
kube-flannel-ds-qcspv   1/1     Running   0          23m

ロードバランサーのインストール（マスターノードのラズパイのみ）

こちらを参考にして作っているので、同様にMetalLBをインストールします。
MetalLB, bare metal load-balancer for Kubernetesを参考にインストールします。

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.5/config/manifests/metallb-native.yaml
# ...

kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

起動の確認を行います。

kubectl get pod -n metallb-system
# 以下が表示される
NAME                          READY   STATUS    RESTARTS   AGE
controller-8689779bc5-txnbg   0/1     Pending   0          70s
speaker-vcg4j                 1/1     Running   0          70s

ワーカーノードをクラスタにジョイン

先程、テキストエディタにコピーしておいたコマンドを実行します。
※sudo忘れに注意

sudo kubeadm join 192.168.1.101:6443 --token y2grpy.nbvcyr1em9o5aigj　--discovery-token-ca-cert-hash sha256:3e9ef8910b95e0a366041c1e156b7cbd6802df4c857cd53ad59bbba631749983

ちゃんとワーカーノードがジョインされたか確認してみましょう。

kubectl get nodes
# 以下が表示される
NAME       STATUS     ROLES           AGE    VERSION
master01   Ready   control-plane      6d     v1.25.0
work01     Ready      <none>          122m   v1.25.0
work02     Ready      <none>          121m   v1.25.0

ROLESがデフォルトになっているので変更します。

# work01
kubectl label node work01 node-role.kubernetes.io/worker=worker
# work02
kubectl label node work02 node-role.kubernetes.io/worker=worker
# 確認
kubectl get nodes
# 以下が表示される
NAME       STATUS     ROLES           AGE    VERSION
master01   Ready   control-plane      6d     v1.25.0
work01     Ready      worker          122m   v1.25.0
work02     Ready      worker          121m   v1.25.0

これでクラスタの完成です。遂に我が家にKubernetesがやって来ました。

もしコピー&ペーストを忘れた場合

以下のコマンドで発行したトークンを確認することが出来ます。

kubeadm token list
# 以下が表示される
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
y2grpy.nbvcyr1em9o5aigj   22h         2022-09-04T08:03:11Z   authentication,signing   <none>                                                     system:bootstrappers:kubeadm:default-node-token

有効期限が切れてしまった場合は以下のコマンドで再発行します。

sudo kubeadm token create

CA証明書のhashも必要なので、以下のコマンドで出力させます。

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

Kubernetesでコンテナを動かす

yamlファイルの作成とapply

Dockerが動作しているホストのHostnameを表示するNginxコンテナをお借りして、Metal-LBでロードバランシングします。

yamlはこちらを参考にさせて頂いております。
MetalLB v0.13以降はConfigMapでの設定が廃止され、Custom Resource Definitions（CRD）での設定が推奨になったようで、MetalLBの部分だけv0.13に適合するように書き換えます。

apiVersion: v1
kind: Namespace
metadata:
  name: nginx-prod
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: pool-ips
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.210-192.168.1.215 # 外部IPレンジ（この中から適当に外部IPが選ばれる）
  autoAssign: true
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: pool-ips
  namespace: metallb-system
spec:
  ipAddressPools:
  - pool-ips
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service-lb # Service(LoadBalancer) の名前
  namespace: nginx-prod
  annotations:
    metallb.universe.tf/address-pool: pool-ips # MetallbのIPプール名
spec:
  type: LoadBalancer
  ports:
    - name: nginx-service-lb
      protocol: TCP
      port: 8080 # ServiceのIPでlistenするポート
      nodePort: 30080 # nodeのIPでlistenするポート（30000-32767）
      targetPort: 80 # 転送先(コンテナ)でlistenしているPort番号のポート
  selector: # service のselctorは、matchLabels 扱いになる
    app: nginx-pod # 転送先の Pod のラベル
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Deployment の名前(ReplicaSetの名前もこれになる)
  namespace: nginx-prod
spec:
  selector:
    matchLabels: # ラベルがマッチしたPodを対象とするReplicaSetの作成
      app: nginx-pod
  replicas: 2
  template: # Pod のテンプレート
    metadata:
      name: nginx-pod # Pod の名前
      namespace: nginx-prod
      labels: # Pod のラベル
        app: nginx-pod
    spec:
      containers: # コンテナの設定
        - name: nginx-container # コンテナの名前
          image: yasthon/nginx-display-hostname # イメージの名前
          env:
            - name: nginx-container
          ports:
            - containerPort: 80 # コンテナのポート
          volumeMounts:
            - name: file-hostname
              mountPath: /usr/share/nginx/html/hostname
      volumes:
        - name: file-hostname
          hostPath:
            path: /etc/hostname

参考：

• MetalLB v0.13以降はConfigmapでの設定ができない
• Heads up: breaking changes in 0.13.x #1473

以下のコマンドでリソースを作成します。

# リソースの作成
kubectl apply -f display-hostname.yaml

動作確認

色々確認していきましょう。

# ポッドの確認
kubectl get pods -n nginx-prod
# 以下が表示される
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-5bd979fdf9-dftnr   1/1     Running   0          92s
nginx-deployment-5bd979fdf9-m9b58   1/1     Running   0          92s

# デプロイメントの確認
kubectl get deployment -n nginx-prod
#
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           23m

# ReplicaSetの確認
kubectl get replicaset -n nginx-prod
#
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-5bd979fdf9   2         2         2       23m

ちゃんと2つ立ち上がってます🙌

サービスを見ることでロードバランサーの外部IPを取得し、アクセスしてみましょう。

kubectl get svc -n nginx-prod
# 以下が表示される
NAME               TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service-lb   LoadBalancer   10.101.40.46   192.168.1.210   8080:30080/TCP   3m26s
# 外部IPへアクセスしてみる
# ポート番号の入力を忘れないように注意する。
curl 192.168.1.210:8080/index.sh
# work02が表示される。
<html><head>
<title>work02</title>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head><body>
HOSTNAME : work02
</body></html>
# もう一度アクセスしてみる
curl 192.168.1.210:8080/index.sh
# 今度はwork01が表示される
<html><head>
<title>work01</title>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head><body>
HOSTNAME : work01
</body></html>

アクセスするたびに接続先が変わっていることから、ロードバランシングされていることが見受けられます。
同じネットワーク内につながっているPCであれば、ブラウザから上記アドレスへアクセスすることも可能です。

可用性を体感する

こちらの記事同様、ワーカーを物理的に落としても外部IPへアクセスできることを確認します。
ワーカーノード（1）に接続されたLANケーブルを抜いてアクセスしてみます。

curl 192.168.1.210:8080/index.sh
# ワーカーノード②に繋がる
<html><head>
<title>work02</title>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head><body>
HOSTNAME : work02
</body></html>

次に、ワーカーノード（1）を繋ぎ直し、ワーカーノード（2）に接続されたLANケーブルを抜いてアクセスしてみます。
（ワーカーノード（1）を繋いでから接続できるようになるまで少し時間がかかります）。

curl 192.168.1.210:8080/index.sh
# ワーカーノード①に繋がる
<html><head>
<title>work01</title>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head><body>
HOSTNAME : work01
</body></html>

このように、どちらかのワーカーが落ちても外部IPアドレスにアクセスでき、可用性を体感できました。
ロードバランサー自体はアクセス先を2つのワーカーに振り分けることで負荷を分散させる役割を持っていますが、このようにアクセス可能なワーカーのみに振り分けることも可能です。

最後に2つのワーカーノードの接続を外してみます。

curl 192.168.1.210:8080/index.sh
# 繋がらない
curl: (7) Failed to connect to 192.168.1.210 port 8080: No route to host

当然ですが、アクセスできないことが確認できます。

再起動してみる

クラスターを止めずに全ノード再起動して、再度確認してみます。

# nodeの状態を確認する
kubectl get node -A
# STATUSがReadyなことが確認できる
NAME                STATUS   ROLES           AGE    VERSION
mas01.example.com   Ready    control-plane   107m   v1.25.0
work01              Ready    worker          101m   v1.25.0
work02              Ready    worker          101m   v1.25.0
# コンテナの情報を見てみる
kubectl get all -n nginx-prod
# コンテナが動いていることが確認できる
NAME                                    READY   STATUS    RESTARTS      AGE
pod/nginx-deployment-5bd979fdf9-h89bh   1/1     Running   1 (13m ago)   38m
pod/nginx-deployment-5bd979fdf9-xnltc   1/1     Running   1 (13m ago)   38m

NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
service/nginx-service-lb   LoadBalancer   10.101.40.46   192.168.1.210   8080:30080/TCP   84m

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   2/2     2            2           84m

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-5bd979fdf9   2         2         2       84m
# 外部IPにアクセスしてみる
curl 192.168.1.210:8080/index.sh
# アクセス可能
<html><head>
<title>work01</title>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head><body>
HOSTNAME : work01
</body></html>

このように、ラズパイ自体を再起動してもまたクラスタが立ち上がっていることが確認できます。

まとめ

ラズパイを使ってKubernetesのクラスタを作成し、ロードバランシング・可用性を体感できました。クラウド上でゴニョゴニョ行われていることに対して、物理的な構成から作ってみることで解像度が上がった気がします。また、Kubernetes周りで使われている技術（cgroup, kubeadm, kubelet, flannel, …）について調べながら進めることで、Kubernetesに対して理解が進みました。
今回、コンテナの構成に関しては自分で作らなかったので、次はWebアプリでも作ってデプロイしてみたいと思います。

夏休み自由研究ブログ連載の8本目です。

はじめに

こんにちは。TIG/DXユニットの宮永です。

昨今の観葉植物ブームに便乗して先日ドラセナ・コンパクタという熱帯アフリカ原産の植物を購入しました。茎の縞模様とパイナップルを彷彿させるような葉っぱがとても可愛らしい植物です。ふとしたときに眺めるととても癒やされます。

観葉植物を購入してから気づいたのですが、水やりというのは結構大変です。植物を置いている場所の室温、日当たり、湿度などから適切な水分量を見極めるのが素人の私には難しいと感じています。

また、生来がズボラな性格をしているため、水をやるのを忘れてしまったりなども今後考えられます。

枯れてしまってから泣きをみることがないように、今回は土壌水分計とRaspberryPi、ADコンバータを使用して観葉植物の水分量を監視するSlackBotを作成します。

また、本記事のサンプルコードはorangekame3/mcp3002にて公開していますので、参考にしてください。

システム構成

構成はシンプルです。

RaspberryPiにこちらの土壌水分計を取り付け、ADコンバータMCP3002で読み出しを行います。読み出した電圧値に応じてSlackBot経由で通知を行います。

Pythonで同様のことを行っている記事はたくさんありますが、Go言語での実装例は殆どなかったのでその点で参考になれば幸いです。

使用機器

• RaspberryPi 3
• 土壌水分計
• ADコンバータ(MCP3002)
• ジャンパーワイヤ（適量）
• ブレッドボード

配線

余談ですが、RaspberryPiにはpinoutというコマンドが標準で備わっています。配線するときに便利ですのでおすすめです。

せっかくですので、pinoutで出力されたピン番号に沿って今回の配線を説明します。

J8:
   3V3  (1) (2)  5V
 GPIO2  (3) (4)  5V
 GPIO3  (5) (6)  GND
 GPIO4  (7) (8)  GPIO14
   GND  (9) (10) GPIO15
GPIO17 (11) (12) GPIO18
GPIO27 (13) (14) GND
GPIO22 (15) (16) GPIO23
   3V3 (17) (18) GPIO24
GPIO10 (19) (20) GND
 GPIO9 (21) (22) GPIO25
GPIO11 (23) (24) GPIO8
   GND (25) (26) GPIO7
 GPIO0 (27) (28) GPIO1
 GPIO5 (29) (30) GND
 GPIO6 (31) (32) GPIO12
GPIO13 (33) (34) GND
GPIO19 (35) (36) GPIO16
GPIO26 (37) (38) GPIO20
   GND (39) (40) GPIO21

ADコンバータは秋月商店で購入しました。

商品詳細ページにデータシートがあったため、こちらを使用して配線の説明をします。

MCP3002には前後があります。写真にあるように前方には半円のマークがついています。
下図のように半円の印がついたものを上向きにした場合、左上から1,2,3…と番号が振られます。

以下、MCP3002とRaspberryPiそして土壌水分計との接続関係です。
今回はMCP3002のCH0のみ使用したため、CH1にはなにも接続していません。

▼配線一覧

実装

今回実装するにあたってこちらのgolang.org/x/exp/io/spiパッケージを使用しました。

また、MCP3002からの読み出しの実装についてはこちらのリポジトリでMCP3004、MCP3008、MCP3204、MCP3208の実装がされていたため、MCP3002のデータシートと比較しながら実装の参考とさせていただきました。

デバイスの読み込み

まずはgolang.org/x/exp/io/spiを使用して、デバイスを読み込みます。

dev, err := spi.Open(&spi.Devfs{
	Dev:      "/dev/spidev0.0",
	Mode:     spi.Mode0,
	MaxSpeed: 3600000,
})
if err != nil {
	fmt.Println(err)
}
defer dev.Close()

MCP3002のドライバ作成

デバイスを読み込んだらMCP3002の仕様に合わせてドライバを作成します。

package mcp3002

import (
	"fmt"

	"golang.org/x/exp/io/spi"
)

type MCP3002 struct {
	Dev     *spi.Device
	Vref    float64
	Channel int
}

func (m MCP3002) Read() (float64, error) {
	if m.Channel < 0 || m.Channel > 1 { //    ---------------- (1)
		return 0, fmt.Errorf("channel is only selected 0 or 1")
	}
	cmd := byte(0x68) // ------------------------------------- (2)
	if m.Channel == 1 {
		cmd = 0x78
	}
	in := []byte{cmd, 0x00}
	out := make([]byte, 2)
	if err := m.Dev.Tx(in, out); err != nil {
		return 0, fmt.Errorf("failed to read channel %d,%w", m.Channel, err)
	}
	data := int(out[0]&3)<<8 | int(out[1]) //    ------------- (3)
	return (m.Vref / 1024) * float64(data), nil
}

上記の実装で初見でよくわからんと思うポイントにナンバリングしました。順に説明します。

(1)MCP3002のチャネル数

(1)の実装はMCP3002のチャネル数に対するバインディングです。冒頭で説明したとおり、MCP3002はチャネルが2つあります。使用するチャネルによってMCP3002に渡すバイナリも変わるため、ここのハンドリングは大事です。

(2)MCP3002に渡すバイナリ

MCP3002のデータシートを参照すると以下のようなシーケンス図が記載されています。DinがRaspberryPi→MCP3002にわたすバイナリ、DoutがMCP3002→Raspberryで受け取るバイナリです。

データシートにはMCP3002に送るべきバイナリと読みとるべきバイナリについて記載がありました。
このデータシートによれば、MCP3002に向けて2バイト渡せば良いことがわかります。そのうち、1バイト目には条件に沿ったバイナリを渡してあげる必要があります。

StartBitの次に記載されているSGL/DIFF、ODD/SIGN、について0/1のどちらを渡すかは使用するチャネルによります。
以下の図に従えばCH0を使用する場合は10を渡せば良いことがわかります。MSBFについてですが、Figure5-1に従う読み出しを行う場合は1にします。よってRaspberryPi→MCP3002にむけて送信するべきバイナリは

01101000 00000000

であることがわかります。これは16進数表記で0x68です。同様にして使用しているチャネルが1である場合SGL/DIFF、ODD/SIGNが11となるためRaspberryPi→MCP3002にむけて送信するべきバイナリは

01111000 00000000

となります。これは16進数表記で0x78です。これで(2)の謎の16進数の役割がおわかりいただけたかと思います。

(3)10ビット読みだし

データシートのFIGURE6-1に記載の通り、末尾10ビットに読み出すべき情報が含まれています。RaspberryPi→MCP3002で2バイト渡したように、MCP3002→RaspberryPiでも2バイト受け取ります。

1バイト目と3で論理積を取ることで1バイト目の下方2ビットの値を特定できます。

例）
10110101と00000011(3)の論理積 は00000001です。

上記で算出したバイナリを8ビット左シフトし後方1バイトと論理和を取ることで、読み出すべき10ビットを取得できます。

例)
00000001を8ビット左シフトすると00000001 00000000になります。

MCP3002→RaspberryPiで受け取った2バイト目のバイナリが01011010だとすると、上記00000001 00000000と01011010の論理和は

00000001 01011010

であることがわかります。これで(3)の謎の演算がわかったかと思います。
あとはこの読み出した値に対して閾値を設定してやれば、観葉植物監視botの要件を達成できます。

呼び出し元の実装

1つのADコンバータに2つのチャネルがついているので監視する観葉植物も2つ登録できます。
Plant構造体を作成してADコンバータを登録するようにします。
閾値0.4を境にbotが通知する状態を変えます。

package main

import (
	"fmt"
	"github.com/mcp3002"
	"golang.org/x/exp/io/spi"
)

const (
	Tirsty = "喉乾いたよ〜"
	Moist  = "お水はもう十分だよ"
)

type Plant struct {
	ADC    mcp3002.MCP3002
	Status string
}

func (p Plant) addState(v float64) Plant {
	resp := p
	if v > 0.4 {
		resp.Status = Tirsty
		return resp
	}
	resp.Status = Moist
	return resp
}

func (p Plant) addChannel(ch int) Plant {
	resp := p
	resp.ADC.Channel = 0
	if ch == 1 {
		resp.ADC.Channel = 1
		return resp
	}
	return resp
}

func (p Plant) addADC(mcp mcp3002.MCP3002) Plant {
	resp := p
	resp.ADC = mcp
	return resp
}

上記実装にSlack通知機能を実装します。cronで定期的に土壌水分を監視してPlant.StatusがThirstyである場合はSlackで通知するようにします。Slack通知にはslack-goをcronにはrobfig/cronを使用しました。

package main

import (
	"fmt"
	"log"
	"os"
	"time"

	"github.com/joho/godotenv"
	"github.com/mcp3002"
	"github.com/robfig/cron/v3"
	"github.com/slack-go/slack"
	"golang.org/x/exp/io/spi"
)

func main() {
	dev, err := spi.Open(&spi.Devfs{
		Dev:      "/dev/spidev0.0",
		Mode:     spi.Mode0,
		MaxSpeed: 3600000,
	})
	if err != nil {
		fmt.Println(err)
	}

	defer dev.Close()

	// AD converの設定
	mcp := mcp3002.MCP3002{
		Dev:  dev,
		Vref: 3.3,
	}

	// slackの設定ファイル読み込み
	err = godotenv.Load("../.env")
	if err != nil {
		log.Fatalf("read slack env", err)
	}
	tkn := os.Getenv("TOKEN")
	client := slack.New(tkn)

	var plantA Plant
	plantA = plantA.addADC(mcp)
	plantA = plantA.addChannel(0)

	c := cron.New()
	c.AddFunc("@every 1s", func() {
		if err := worker(plantA, client); err != nil {
			log.Fatal(err)
		}
	})
	c.Start()
	for {
		time.Sleep(time.Second)
	}

}

func worker(p Plant, client *slack.Client) error {
	v, _ := p.ADC.Read()
	p = p.addState(v)
	if p.Status == Tirsty {
		_, _, err := client.PostMessage("#home", slack.MsgOptionText(p.Status, true))
		if err != nil {
			return fmt.Errorf("failed to post message  %w", err)
		}
	}
	return nil
}

const (
	Tirsty = "喉乾いたよ〜"
	Moist  = "お水はもう十分だよ"
)

type Plant struct {
	ADC    mcp3002.MCP3002
	Status string
}

func (p Plant) addState(v float64) Plant {
	resp := p
	if v > 0.4 {
		resp.Status = Tirsty
		return resp
	}
	resp.Status = Moist
	return resp
}

func (p Plant) addChannel(ch int) Plant {
	resp := p
	resp.ADC.Channel = 0
	if ch == 1 {
		resp.ADC.Channel = 1
		return resp
	}
	return resp
}

func (p Plant) addADC(mcp mcp3002.MCP3002) Plant {
	resp := p
	resp.ADC = mcp
	return resp
}

それでは最後に上記ジョブを実行してみます。

ドラセナが喉の乾きを訴えかけてきました…

さいごに

今回は土壌水分計とADコンバータを用いて観葉植物監視botを作成しました。
実はgolang.org/x/exp/io/spiパッケージはすでにメンテがされていないようで、https://github.com/periphの利用が現在は推奨されているようです。

記事をほぼ書き終えてから気づいたので少し反省です。今後GoでRaspberryPi周りを触る際はhttps://github.com/periphを利用してみようとおもいます。Gobotもこちらをベースに実装を行っているようです。

最後まで読んでいただきありがとうございました。

はじめに

こんにちは。日本ソムリエ協会認定ワインエキスパートの今泉です。
間違えました。TIG/DXユニットの今泉です。

先日、古い年式のワインセラーを我が家に迎えました。新品といえど型落ち品のため、怖いのが故障です。

ワインはとてもデリケートな飲み物で真夏の気温などでは直ぐにダメになってしまいます。また熟成に適した温度もあり、一般的には年間を通じて12~15℃程度で一日の温度変化が少ないほうが良いとされています。¹
もし長期間家を空けたタイミングでセラーが壊れてしまったら……………

機械なので故障は仕方ありませんが、なんとかトラブルをすぐに検知する仕組みが欲しいところです。
そこでセラーに温度データロガーを設置することにしましたが、私の要望を満たす市販の製品は非常に高価かつ私にとっては不要な機能も含まれており、選定は難航しました。

ちょうどいい製品がないのであれば作ればよいのです。

ということでアラート機能付きの温湿度データロガーを自作することにしました。

システム構成

実現したいこととしては以下の通りです。

1. セラー内部の温湿度を取得
2. API Gateway経由でLambdaにHTTP POSTし、DynamoDBにデータを蓄積
3. CloudWatchをトリガーにDBへのデータ更新が行われているか、セラー内部の温度が基準を上回っていないか監視
4. 3で問題があった場合、LINE messaging APIで自分のLINEアカウントに通知

MQTT & AWSIoTで実現することも考えましたが、すでに宮永さんが素敵な記事を書いているので今回は見送りました。
GoでMQTT!!　～温湿度マイスターbotの作成～(前編)

まずはAPI

まずはクラウド環境の構築ですが、今回使用するLambda、DynamoDBについては特段本記事では取り上げません。
フューチャー技術ブログでは数多く記事が投稿されていますので是非読んでみて下さい。

Lambdaから実行するコードは以下の通りです。
Node.jsでもよかったのですが、最近使い始めたGoに少しでも慣れるためにもGoで書くことにしました。

package main

import (
	"encoding/json"
	"time"

	"github.com/aws/aws-lambda-go/events"
	"github.com/aws/aws-lambda-go/lambda"
	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/dynamodb"
	"github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute"
)

var tokyo, _ = time.LoadLocation("Asia/Tokyo")

type CellarData struct {
	Id          int    `dynamodbav:"id"`
	TimeStamp   string `dynamodbav:"timestamp"`
	Temperature string `dynamodbav:"temperature"`
	Humidity    string `dynamodbav:"humidity"`
}

type RequestBody struct {
	Temperature string `json:"temperature"`
	Humidity    string `json:"humidity"`
}

type Response struct {
	RequestMethod string `json:"RequestMethod"`
}

func handler(request RequestBody) (events.APIGatewayProxyResponse, error) {

	// connect DB
	db := dynamodb.New(session.Must(session.NewSession()))

	//set Data
	cellarData := CellarData{
		Id:          1,
		TimeStamp:   time.Now().In(tokyo).Format("2006-01-02 15:04:05"),
		Temperature: request.Temperature,
		Humidity:    request.Humidity,
	}
	item, err := dynamodbattribute.MarshalMap(cellarData)
	if err != nil {
		return events.APIGatewayProxyResponse{
			Body:       err.Error(),
			StatusCode: 500,
		}, err
	}

	// execute
	_, err = db.PutItem(&dynamodb.PutItemInput{
		TableName: aws.String("CELLAR"),
		Item:      item,
	})
	if err != nil {
		return events.APIGatewayProxyResponse{
			Body:       err.Error(),
			StatusCode: 500,
		}, err
	}

	// set response
	jsonBytes, _ := json.Marshal(Response{
		RequestMethod: "POST",
	})
	return events.APIGatewayProxyResponse{
		Body:       string(jsonBytes),
		StatusCode: 200,
	}, nil
}

func main() {
	lambda.Start(handler)
}

ここで話せるようなポイントはあまりないのですが、POSTのリクエストボディはAPI Gatewayのマッピングテンプレートを活用しました。

ESP-WROOM02(ESP8266)を使った温湿度センサの作成

今回はじめて電子工作にチャレンジしたのですが、どのマイコンボードを選べばいいのか、どのような機材をそろえればいいのか、全く当たりがつきません。
Arduinoが入門者にはお勧めらしいのですが、無線でのインターネット接続を行うには別途Wifi通信モジュールが必要で、その通信モジュール自体もプログラムの読み書きが可能なマイコンとして動作が可能らしく、じゃあもうそれでいいじゃんとなりました。

回路の構築やはんだ付にやや不安があったのである程度構築済みのものを探した結果、以下の製品を利用することにしました。

• ESPr® Developer（ピンソケット実装済）
• ESPr® Developer用環境センサシールド

ESPr® DeveloperはWifiモジュールであるESP-WROOM-02(RSP8266)の開発ボードで、こちらの製品はすでにピンソケットが実装されています。温湿度センサーとしてはBME280とフォトトランジスタを搭載したESPr® Developer用環境センサシールドを利用したのですがこちらもピンヘッダがすでに付いているので手間が大幅に削減できます。

ESP-WROOM02はArduinoと同様、C/C++をベースとしたArduino言語を使用できるため、キャッチアップなどは不要でプログラミングに取り掛かることができました。
開発環境構築に当たっては以下記事を参考にさせていただきました。

ESP-WROOM-02開発ボードをArduino IDEで開発する方法

ソースコードは次の通りです。

#include <ESP8266HTTPClient.h>
#include <ESP8266WiFi.h>
#include <WiFiClientSecure.h>
#include <BME280I2C.h>
#include <Wire.h>
#include <ArduinoJson.h>

#define SERIAL_BAUD 115200
#define API_KEY "your api_key"
#define WIFI_SSID "your ssid"
#define PWD "your password"

BME280I2C bme;

void setup()
{
    Serial.begin(SERIAL_BAUD);
    delay(10);

    Serial.println("Connecting to Wi-Fi");
    WiFi.begin(WIFI_SSID, PWD);

    while (WiFi.status() != WL_CONNECTED) {
      delay(500);
      Serial.println(".");
    }
    Serial.println("");
    Serial.println("Wi-Fi connected");
    Serial.println(WiFi.localIP());

    Wire.begin();

    while (!bme.begin()){
        Serial.println("BME280 is not available");
        delay(1000);
    }

}

void loop()
{
    float temp(NAN), hum(NAN), pres(NAN);

    BME280::TempUnit tempUnit(BME280::TempUnit_Celsius);
    BME280::PresUnit presUnit(BME280::PresUnit_Pa);

    bme.read(pres, temp, hum, tempUnit, presUnit);

    Serial.print("temp: ");
    Serial.print(temp);
    Serial.print(", humid: ");
    Serial.print(hum);
    Serial.print(", pressure: ");
    Serial.println(pres);

    registerSensor(temp,hum);

    //30min
    ESP.deepSleep(30 * 60 * 1000000 );

}

void registerSensor(float temp,float hum)
{
    if (WiFi.status() == WL_CONNECTED) {

        HTTPClient http;
        WiFiClientSecure client;
        const char* path = "your endpoint";
        http.setTimeout(500); // 500ms
        client.setInsecure();

        http.begin(client,path);
        //set header
        http.addHeader("x-api-key",API_KEY);
        http.addHeader("Content-Type", "application/json");

        //set requestbody
        StaticJsonDocument<JSON_OBJECT_SIZE(20)>  jsonArray;
        char tempstr[10];
        char humstr[10];
        dtostrf(temp, 6, 2, tempstr);
        dtostrf(hum, 6, 2, humstr);

        jsonArray["temperature"] = tempstr;
        jsonArray["humidity"] = humstr;

        char jsonString[255];
        serializeJson(jsonArray,jsonString, sizeof(jsonString));

        // post
        int httpCode = http.POST((uint8_t *)jsonString, strlen(jsonString));

        if (httpCode > 0) {
            Serial.printf("[HTTPS] POST... code: %d\n", httpCode);
        } else {
            Serial.println("[HTTPS] no connection or no HTTP server.");
        }
        http.end();
     }
 }

環境センサシールドはI2C通信のみ対応しているため、温湿度の取得はBME280I2Cをimportしました。

コードはBME280ライブラリのサンプルを参考にしています。
組み込み系ではJSON形式にするのは面倒なのでは…？ と思っていましたが、ArduinoJsonを利用することで手間なくJson化できました。

給電

今回、セラー内に設置する必要があるためPCやコンセント以外での電源確保が必要です。

たまたまスマートフォン用の電池交換式充填機があったため使ってみましたが、問題なく稼働しました。

長時間駆動させることを考えるとセンサを常に稼働させておくのは望ましくありません。
ESP-WROOM02にはDeepSleepモードがあるため、これを活用して30分間隔で温湿度を取得するようにしました。

//30min
ESP.deepSleep(30 * 60 * 1000000 );

sleepの単位はμ秒のため秒を1000000倍する必要があります。

なお、以下記事によると最大で71.5分ほどスリープが可能なようです。

ESP-WROOM-02のDeep-sleepはどれだけ寝ていられるのか
運用から4日程度経ちますが、今のところ駆動に問題はありません。あまりにも電池の持ちが短かったら別の給電方法を考えたいと思います。

さて、プログラムが組み終わったのでセラーに設置してみます。

なんだか電子工作感がまるでありませんが気にしないことにします。

通知機能をつける

Lambdaに実装した関数は次の通りです。

package main

import (
	"strconv"
	"time"

	"github.com/aws/aws-lambda-go/lambda"
	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/dynamodb"
	"github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute"
	"github.com/line/line-bot-sdk-go/linebot"
)

type CellarData struct {
	Id          int    `dynamodbav:"id"`
	TimeStamp   string `dynamodbav:"timestamp"`
	Temperature string `dynamodbav:"temperature"`
	Humidity    string `dynamodbav:"humidity"`
}

func handler() error {
	const threshold = 25.00

	// connect DB
	db := dynamodb.New(session.Must(session.NewSession()))

	result, err := db.Query(&dynamodb.QueryInput{
		TableName:        aws.String("CELLAR"),
		Limit:            aws.Int(1),
		ScanIndexForward: aws.Bool(false),
		ExpressionAttributeNames: map[string]*string{
			"#id": aws.String("id"),
		},
		ExpressionAttributeValues: map[string]*dynamodb.AttributeValue{
			":id": {
				N: aws.String("1"),
			},
		},
		KeyConditionExpression: aws.String("#id = :id"),
	})
	if err != nil {
		return err
	}

	var cellarData []CellarData
	err = dynamodbattribute.UnmarshalListOfMaps(result.Items, &cellarData)
	if err != nil {
		return err
	}

	t1, _ := time.Parse("2006-01-02 15:04:05", cellarData[0].TimeStamp)
	t2 := time.Now().Add(time.Hour + 7)

	f, _ := strconv.ParseFloat(cellarData[0].Temperature, 64)
	if f > threshold {
		return toNotify("セラーの現在の温度は" + cellarData[0].Temperature + "度です")
	}
	if t2.After(t1) {
		return toNotify(cellarData[0].TimeStamp + "以降更新がありません")
	}
	return nil
}

func toNotify(str string) error {
	const LINE_BOT_CHANNEL_SECRET = "your channel"
	const LINE_CHANNEL_ACCESS_TOKEN = "your token"

	bot, err := linebot.New(LINE_BOT_CHANNEL_SECRET, LINE_CHANNEL_ACCESS_TOKEN)
	if err != nil {
		return err
	}

	message := linebot.NewTextMessage(str)
	if _, err := bot.BroadcastMessage(message).Do(); err != nil {
		return err
	}
}

func main() {
	lambda.Start(handler)
}