技術とエンタメと、その他・・・

主に、技術ネタ、エンタメ系のネタを書いていく予定です。また、自分が参加したイベントに関する記事も投稿予定。

ピクトグラムになるために Scratch 3.0用の独自拡張機能を使った話の概要（PoseNet2Scratch）

どんな話なのかは、動画で見ていただくのが分かりやすいと思うので、まずはデモ動画をのせてみます。

また、ブラウザ上でご自身で試していただけるバージョンも以下に用意してみました。
以下のお試しができるものは、公式の Scratch にはない独自拡張機能が組み込まれていて、それをオンラインで共有することが可能な「adacraft」というものを使っています（Twitter上で、このような環境で公開できるのではないかと教えていただき、公開してみました）。

【実際に試せるもの】
●adacraft： pictogram_PoseNet2Scratch
　https://adacraft.org/player/?project=4c3801b7
※ お試しされる場合は、両肩より上がカメラにうつる感じで

なお、冒頭のツイートの動画は、PoseNet2Scratch を作られた @jishiha さんが公開されている環境の「Stretch3」を使って実装していました。こちらは、adacraft のようなオンライン共有機能はないものの、機械学習系をはじめとした多数の独自拡張機能が組み込まれており、面白い仕組みが作れて楽しいので試すのをオススメしたい環境です（記事の最後に補足を書きます）。

作った経緯

Twitter で、ピクトグラムを使ったいろいろなネタを見かけて、その中に「自分がピクトグラムになれる・自分でピクトグラムを作れる」というものがありました（この記事の最後の部分に事例をいくつか掲載しています）。

それを見て当初は、「JavaScript版 の MediaPipe」と「p5.js」の組み合わせでやってみたいな、と頭に思い浮かべていました。
JavaScript版 の MediaPipe は、カメラ映像に対してブラウザ上で画像認識をさせるような仕組みを試すのに、ちょこちょこ使っていたものでした。

例えば、顔・体・手を認識できる MediaPipe Holistic というもので、こういうものを作ってみたり...

また、複数の手を認識できる MediaPipe Hands というもので、このようなことをやってみたりもしました。

上記のツイートの動画の事例の両方とも、描画まわりは「p5.js」というライブラリを利用しています。

今回の場合、画像認識に MediaPipe JavaScript版を利用するなら、MediaPipe Pose（今回のものと同じ仕様）か、MediaPipe Holistic（Pose と似ているが、顔と手の部分でとれるキーポイントが格段に多いもの）のどちらかを使えば、というところです。

このようなことを考えていた中、Scratch 3.0用に作られた独自拡張機能で、機械学習を用いた人の姿勢推定を行える「PoseNet2Scratch」もあるというのを思い出し、「単純な実装をする場合は、描画まわりとか座標の処理など Scratch を使うのが楽でシンプルになるかも？」と思いました。
そして思いついてから実装をしてみて、割と短い時間で冒頭の仕組みを試作できました。

どんな実装をしたか？

今回、短時間で作れて自分が動画を撮るのに楽なように、上半身のみを対象として作っています。
今回の姿勢推定に使われている「PoseNet」は以下の記事などにあるように、全身の特定の箇所のキーポイント（全部で16箇所）を取得できます。

●ポーズ推定  |  TensorFlow Lite
　https://www.tensorflow.org/lite/examples/images/pose.png?hl=ja

f:id:youtoy:20210729090358j:plain

その中で、以下の 9箇所分のキーポイントを用いています。

【利用したキーポイント】
　鼻、左耳、右耳、左肩、右肩、
　左ひじ、右ひじ、左手首、右手首

利用したキーポイントと使われ方

認識結果として得られるキーポイントの各座標（x, y）をどのように使ったかという話は、以下のようになっています。

  • 鼻
    • 顔のパーツの表示位置の基準を決める座標となっている
  • 左耳、右耳
    • カメラに顔が近づいたり、逆に遠ざかったりしたとき、顔のパーツの大きさを変える仕組みに利用（2点間の距離の大きさによって、顔のパーツの大きさの比率を変化させる）、それと合わせて肩から肘・肘から手までのパーツの大きさを変える仕組みにも流用（※ 実装の簡単化のため）
  • 左肩、右肩
    • 肩から肘にかけてのパーツの表示位置と表示する際の回転角を決めるのに利用している（左ひじ、右ひじの座標とセットで）
  • 左手首、右手首
    • 肘から手にかけてのパーツの表示位置と表示する際の回転角を決めるのに利用している（左ひじ、右ひじの座標とセットで）
  • 左ひじ、右ひじ
    • 上記のとおり「 左肩、右肩」、「左手首、右手首」の座標と組み合わせて利用している

重畳表示する素材の用意

顔や体、腕の部分で表示しているパーツは、Scratch公式の画像エディタで作ったものを利用しています。

f:id:youtoy:20210729211100j:plain

作ったといっても、円を描いたり、長方形を描いたりというシンプルな作図です。肘から手の部分のみ、「大きさの異なる 2つの円と、長方形を描画した後に変形させて台形にした四角 1つ」を組み合わせて形を作っています。

f:id:youtoy:20210729211341p:plain

重畳表示の処理周り（大きさや位置・回転方向の実装まわり）

大きさを変化させる部分は、見た目カテゴリの大きさの比率を変えるブロックを利用しています。 随時、「左耳と右耳の間」と「 左肩と右肩の間」のそれぞれの横方向（x座標方向）の距離を計算し、その計算結果を使って、適当に調整した計数をかけあわせて表示サイズの比率を動的に変更しています。

回転角を決める部分は、「肩と肘」・「肘と手首」のそれぞれの 2点がなす角を公式通りに計算して使っています（Scratch でアークタンジェントを計算するブロックがあるので、公式そのままの実装です）。
「肘と手首」については、どちらが画面上で左側にあるかという、左右方向の位置関係によって算出される角度が変わってくるので、条件分岐と一方の条件のほうは 180度値を足し込む処理を加えていたり、ということをやっています。

説明はざっくりですが、以上のような実装を行って冒頭の内容を実現しました。
以下は、肘から手にかけてのパーツを処理するブロックのプログラムです。

f:id:youtoy:20210729211543j:plain

まとめ

以上が、今回作ったピクトグラムになれる PoseNet2Scratch実装の作品（※ 対応は上半身のみ）の仕組み等の概要でした。

Stretch3 の補足

冒頭の動画に出ていた作品を実装した Stretch3 について、簡単に補足をします。

教育界隈で良く出てくるビジュアルプログラミングなどが行える環境の Scratch 3.0 は、オープンソースで公開されており、GitHub リポジトリからソースを取得して JavaScript による機能追加等を行うことができます。
具体的には、以下の 2つのリポジトリの内容を取得し、組み合わせて使う形です。

●LLK/scratch-gui: Graphical User Interface for creating and running Scratch 3.0 projects.
　https://github.com/LLK/scratch-gui
●LLK/scratch-vm: Virtual Machine used to represent, run, and maintain the state of programs for Scratch 3.0
　https://github.com/LLK/scratch-vm

私自身、公式の Scratch にはないリアルタイム通信機能（IoT界隈で良く登場する MQTT）を、MQTT.js を使って Scratch に追加実装したこともありました。
（以下の動画は、スマホのブラウザ上で行った操作を、MQTT を介して独自実装を加えた Scratch に伝えている様子）

Stretch3 は、自分が作ってみたような公式にはない Scratch 3.0 に対する独自拡張を、1つだけではなく様々含み、また開発環境がオンラインで公開されたものになります。
独自の拡張機能としては、画像分類の学習・推論の両方を扱えたり、Teachable Machine の画像・音声・ポーズプロジェクトを全て扱えたり（Web上にホスティングされた機械学習モデルを呼び出す側を実装できる）、冒頭の動画で使った姿勢推定の PoseNet が使えたり、他にも複数の機械学習系の拡張機能が追加されています（QRコード読み込みなど、機械学習系以外の拡張も複数あったりします）。

ちなみに、機械学習系の拡張機能の話は、過去に以下のような記事を書いてたりもするので、よろしければご覧ください。

ネットで見かけたピクトグラムネタ（プログラムで何かやったというもの）

自分以外にもピクトグラム絡みの作品を、いろいろな環境で作られている方の話を見かけたため、いくつか掲載してみます。

Scratch で ピクトグラムメーカー

MediaPipe（Python版） でピクトグラムに

ソースコード
github.com

ブラウザ上で体験できる JavaScript実装もの

ソースコード
github.com

MediaPipe（JavaScript版） でピクトグラムに

Scratch でガッツリ実装されている

Azure Kinect でピクトグラム

撮影角度を合わせるという観点の作品

技術雑誌で Teachable Machine に関する連載記事の掲載が始まった話（2021年7月）

このブログ記事は、月刊I/O 2021年8月号に掲載された Teachable Machine に関する記事について書いたものです（※ 自分用の備忘録も兼ねて）。

月刊I/O で 4回にわたり掲載予定の『「Teachable Machine 」で機械学習』という連載について、その 1回目の記事が掲載された話になります。

今回の連載のきっかけ

上記の連載記事を執筆する話をいただいたきかっけは、以下のブログ記事でも書いたちょうど 1年前の記事執筆です。

yo-to.hatenablog.com

この時は Node-RED と Teachable Machine を組み合わせるという内容で、4ページの記事を書いていました（元々、Node-RED に関するリレー記事が毎月掲載されており、その中の 1回分を担当させていただきました）。

その後、上記の記事のやりとりを担当いただいた方から「Teachable Machine を題材にした連載記事を書く話」をいただき、調整を進めることとなりました。

今回の連載の内容が決まった流れ

内容について

「1回あたり 3ページほどで 4〜5回くらいの連載」というボリューム感の話を聞いたので、その分量で説明できる内容として「画像プロジェクトについて書くパターン」と「音声プロジェクトについて書くパターン」などを提示しました。
Teachable Machine はポーズプロジェクトという姿勢推定を行うものもありますが、自分がよく使っていたのが上記 2つだったため、それら 2つのみを題材にした案を出していました。

各回で何を書くかのイメージ（概要紹介、基本的な流れを試す回、自分でソースコードに手を加えてみる回、などといった扱う内容案と、もう少し具体的なイメージ案）も合わせて出していった中で、それを見てもらった結果、画像プロジェクトをベースにした案で進めることとなりました。

開始タイミングについて

話をいただいたのは今年2月ごろだったのですが、初の複数回の連載記事ということで、タイミングは先方の進め方・状況を伺いながら慎重に進めました。
何よりも「書く内容が不足して執筆が遅れて、原稿が〆切に間に合わない」という状況になるのを心配してました（確認してみると、やはり 1度始まったら毎月連続して原稿が必要という話...）。

そして、年度の切り替わりの前後は仕事の状況も読めず、十分な時間が確保できるかがいつも以上に不明瞭になるため、そういった状況も加味しつつ、先々の原稿のネタの骨子やおおよその盛り込む内容を整えられそうな（ある程度、ネタとなる情報をため込めそうな）期間を見積もりつつで、新年度になった後に十分に余裕を持たせた 1回目の原稿提出のタイミングで、という調整をさせていただけました。

連載で扱っていく内容

この記事の冒頭でふれていた第1回目は、Teachable Machine 自体の概要紹介を行いました。

今後、掲載されていく残り 3回は、以下の内容を扱っていく予定となっています。

  • Teachable Machine の Webサイト上で機械学習モデルを作成し、推論を同じサイト上で試す（＋モデルのエクスポート）
  • Teachable Machine の Webサイト上で作成した機械学習モデルを、公式サンプルのコードを用いて、自分の用意した環境で動かす
  • サンプルコードをベースにした結果表示（文字による表示）を行う出力部分に、少し手を加えて推論の結果によって何らか動きが変わる処理を付け加える

技術雑誌向けに Node-RED と Teachable Machine に関する記事を執筆した話（2020年7月ごろ）

記事を書いた雑誌について

以下のツイートをしていた、月刊I/O 2020年8月号向けに技術記事（4ページ）を執筆した話について、関連する話や余談を含めて残した記録です。

公式の書籍情報ページはこちら
「http://www.kohgakusha.co.jp/books/detail/4615」
になります。

技術系のプライベートの活動について

プライベートの活動で、技術コミュニティを主催・運営したり、イベントでの LT・セッション登壇をやったり（※ ある時期以降のスライドは主に Speaker Deck にて）、オンラインで個人的に技術記事を書いたり（※ 主に Qiita にて）、あれこれやっていた中でいただいた話でした。

この前に、企業さんからの話・紙媒体の執筆という方向では、Seeed K.K. エンジニアブログに Seeedさんの製品を使った micro:bit（マイクロビット）に関する初心者向けの記事を書く話をいただいたり、有志で技術同人誌を作って技術書典というイベントに出したり（自分の記事の内容は micro:bit とロボットカーの話）、その紙媒体の本を Amazonでも電子版で出す、というようなことをやった話はあったのですが、技術雑誌の記事を書くという話はこの時が初めてでした。

リレー記事と執筆の話のきっかけ

この記事執筆の話の背景として、元々 Node-RED に関するリレー記事の企画が行われている流れがあり、それに関して「リレー記事の 1つを Teachable Machine 関連で書かないか？」という話を Tanaka Seigo さん（@1ft_seabass さん） からいただいて、記事を寄稿させていただくこととなったものでした。

この記事執筆の話をいただいたあたりの時点では、Teachable Machine の画像を対象にした機械学習よりも、音を対象にした機械学習をよく使っていました。例えば、その活用先としてはつくばで開催された Mini Maker Faire での展示作品がありました（余談ですが、この作品に手を加えたものは、同年開催の Maker Faire Tokyo 2020 にもブース出展して展示したりもしました）。

リレー記事で書いた内容など

自分が記事に書いた内容としては、フロー型のビジュアルプログラミング環境である Node-RED と、ブラウザ上で簡単に機械学習モデルが作れて出力等もできる Googleさん提供の Teachable Machine を組み合わせる、という話でした。

記事執筆、記事のスペースの制約がある中でコンパクトに内容を伝える文章・画像といった内容を試行錯誤したり、誌面では載せきれない・載せられない内容をどうするか考えたり（他のリレー記事執筆者の方から GitHub にリポジトリを作って、そこに置くという方法をアドバイスいただきました）、といったようなことをやりつつ進めていきました。

なお、誌面のスペースの話に関しては、当初は 3ページ分の内容を提出したのに紙面用にレイアウトしなおしていただいた段階で 4ページ分に増えるという流れがあって、最終的に 4ページの記事となりました（Googleドキュメントで提出したのですが、3ページ分いっぱいの分量で出すのではなく、少なめで出すのが良いという話を後で知ったりして...）。

元の記事データが誌面用のレイアウトになって送られてきた時も感慨深いものがありましたが（内容チェック用に電子版のデータを送っていただく流れがあった）、冒頭に掲載したツイートの実際の雑誌が手元に届いた時は、感慨もひとしおでした。

執筆後の余談

この記事を書いた時点で Teachable Machine は英語のページのみだったので、記事用にキャプチャした画像（＋ページのボタン・ラベルの表記等について触れた本文）は英語になっていたのですが、「記事を出版社宛に出した後のわりと早いタイミングで日本語化されたページが登場」なんてことがありました...

有志で技術同人誌を出した話についても、記事を印刷用に出した後の割と早いタイミングで、英語表記しかなかったプログラム用ブロックの日本語化が行われる、ということがあったりして...

#toio の #Doコン 用に作った #toioDo の作品のコードについて

はじめに

この記事は、ロボットトイ「toio」に関するコンテストである「Do!コン」 に関する話です。そのコンテストに作品を出したのですが、出した作品のコードを以下で説明していきます。

作品の関連リンク

●toioドミノボウリング | ProtoPedia
　https://protopedia.net/prototype/2248

●toioドミノボウリング（ #toio #Doコン #toioDo ） - YouTube
　https://www.youtube.com/watch?v=CHE4_lzTbZE

出した作品の概要

冒頭に書いたコンテストに出した作品は「toioドミノボウリング」という名前のもので、全体の動作などは以下の動画のとおりです。

www.youtube.com

作品名のとおり「toio を動かして ボウリングのピンに見立てたドミノを倒す」というゲームになります。

f:id:youtoy:20210510020745j:plain

操作用の UI について

この作品を実行・操作するための UI は「緑の旗」と「ステージ上に置かれたスプライト 1つ」です。

f:id:youtoy:20210511002248j:plain

出した作品のコード（全体）

まず、コード全体は以下となります。

f:id:youtoy:20210510235401p:plain

以下では、作ったコードを 6つのまとまりに分けて掲載します。
6つのうち 5つはスプライトに、残り 1つは背景にコードを書いています。

スプライト用

f:id:youtoy:20210510232153p:plain

f:id:youtoy:20210510232206p:plain

f:id:youtoy:20210510232218p:plain

f:id:youtoy:20210510232229p:plain

f:id:youtoy:20210510232240p:plain

背景用

f:id:youtoy:20210510232626p:plain

実装した内容

以下に、実装した処理の概要を記載したコードのまとまり 6つの画像を掲載します。

まとまり1

f:id:youtoy:20210510234703p:plain

ここでポイントになる部分は、以下のとおりです。

  • スタート後、初期位置へ自動で動いていく（邪魔にならないよう、端のほうを動くよう導線を設定）
  • スタート時に、開始が分かりやすいように動きや声で知らせるようにしている
  • 初期位置を決めるゲームモードになっている間が分かりやすいように BGM を鳴らしている

なお、これ以降も含めて BGM・効果音関連の処理は、背景の部分にコードを書いています。

まとまり2

f:id:youtoy:20210511002838p:plain

ここでポイントになる部分は、以下のとおりです。

  • 角度を決めるゲームモードになっている間が分かりやすいように BGM を鳴らしている（先ほどの位置決めの時と異なる BGM を選択）
  • toio がいきなり外に向かって飛び出すような角度にならないよう、toio の位置を基準にして取り得る向きの範囲に制約を加えている（アークタンジェントを使った 2点間の角度計算を利用）
  • 向きとして取り得る角度の最小と最大の間を直接変化させるのではなく、角度を少しずつ変化させるようにし、ある程度は角度を狙ったところに止められるようにした

まとまり3

f:id:youtoy:20210510234736p:plain

ここでポイントになる部分は、以下のとおりです。

  • マットの外に出て動き続ける、ということがないよう、少し余裕をもった所定の範囲内で動きが止まるように制約をつけた
  • タイヤの速さは、基準となる速さと補正値の和をとるようにして、この後に出てくる「toio がいる位置によって移動する向きが変わる仕組み」を取り込みやすくした

まとまり4

f:id:youtoy:20210510234749p:plain

ここでポイントになる部分は、以下のとおりです。

  • 動き出すタイミングが分かりやすいよう、声で知らせるようにした
  • 位置決め・角度決めのゲームモードからドミノを倒すモードに変わったことが分かりやすいよう、BGM を鳴らすようにした（位置決め・角度決めと異なるもの）
  • 「toio がいる位置によって移動する向きが変わる仕組み」について、仕組みを複数のパターンから切り替えられるよう、ブロック定義の入れ替えで仕組みの変更を行えるようにした
  • 移動終了が分かりやすいように、効果音や動きを入れた

まとまり5

f:id:youtoy:20210510234802p:plain

ここでポイントになる部分は、以下のとおりです。

  • 「toio がいる位置によって移動する向きが変わる仕組み」を実装する際に、位置指定が複雑になりすぎないよう、座標を使うのではなくマスの番号を利用する仕組みにした
  • 上記の仕組みで複数のマスをまとめて指定できるように、マスの列の範囲指定を使ったり、 単純な範囲指定より複雑なパターンを使えるよう、行と列の和が偶数であるかどうかを判定する処理を使った（複数の斜め方向の列をまとめて指定するパターンを使った）

なお、この部分はユーザ自身で改造してほしい、改造ポイントと想定しています。

まとまり6

f:id:youtoy:20210510234815p:plain

ここでポイントになる部分は、以下のとおりです。

  • BGM の処理を toio の処理と並列で動かせるよう、メッセージを送る仕組みを使った
  • 複数の BGM や 効果音が重複して鳴らないよう、またうまく切り替わるよう、スクリプトの停止処理を組み合わせて仕組みを作った

まとめ

以上が、今回の作品でスプライト・背景のそれぞれに書いたコードと、その説明です。

#toio に関するノウハウのメモと余談（2021/5/4開催のもくもく会でのメモ）【 #GWアドベントカレンダー 2021/5/5 】

この記事は、2021年の GWのアドベントカレンダー 5/5 の分の記事です。

はじめに

toio の非公式のユーザコミュニティで、2021年5月4日にもくもく会を開催しました。
そのイベント中に行われた質問・回答の内容や情報共有された内容について、一部ピックアップしてメモしたのが、今回の記事の内容です。

toio の簡易マットを平らにする

「toio コア キューブ」（単体）に付属している厚紙ではない簡易プレイマットなど、折りたたまれているものを拡げて使う形のプレイマットがあります。これを拡げて使う際、「拡げたマットの折り目に toio が引っかかるが何か対策がないか？」という質問が出ていました。

それについて、「透明で薄いプラスチック製などのカードケースで、サイズが A3 のもので挟み込んで使っている」という話が出て、具体的に商品のリンクが共有されていたので以下に記載します。この 2つがイベント内で共有されていました。

●Amazon | プラス SFカードケース A3 PC-003クリア 43-003 | 文房具・オフィス用品 | 文房具・オフィス用品
　https://www.amazon.co.jp/dp/B003DXWD4C

●サンデーPET | アクリサンデー株式会社 　https://www.acrysunday.co.jp/product/diy-pla/diy-pet/266/

その後、100円ショップで入手できて利用できたものがあった、という情報も出ていました。

ビジュアルプログラミングでのランプの制御関連

ランプをつけてから消すまでの時間を、ランプをつけた後に決める

これは、参加者の方から出た質問に関する内容です。
「toio のビジュアルプログラミングでは、ランプをつける処理は最初に秒数を指定する必要があるが、何か別の動作時間が不定の処理があって、その別の処理が始まってから終わるまでの間だけランプをつけるようなことができないか？」というものです。

つまり、「実行してみてから処理が3秒かかるかもしれないし、5秒かかるかもしれない処理（処理を実行した後に、結果的に時間が定まるもの）」があり、「ランプをつける時点では不定の時間の間だけ、ランプが点灯するようにする」ということになります。

これを解決するための 1つの方法が、「並列処理（メッセージを送る機能）とランプを消す処理の組み合わせ」になります。動きとしては「処理時間不定のとある処理が終わらないくらいの時間ランプをつける ＋ 処理時間不定の処理が終わったらランプを消す処理を実行する」というもので、ブロックで組むと以下となります。

f:id:youtoy:20210504152512j:plain

この例の「1秒待つ」の部分は、本来は「実行してみてから処理時間が定まる処理（そして、9秒以内には終わると見込まれるもの）」が入る想定の部分です。これにより、当初設定している 9秒より短い時間で、かつ、何らか別の処理の時間が終わったタイミングに合わせてランプが消灯される、という動きになります。

もし、この処理時間不定の処理がどれくらいで終わるか読めないという場合は、以下のようにすると良いかもしれません（どうやら、ランプをつける処理は、連続して実行すると処理と処理の間で消灯するような見え方にならないようです）。

f:id:youtoy:20210504155139j:plain

それと、以下は自分が作ったものではない別のサンプルで、キーを押下したタイミングで既に実行中だった toio 関連の処理を止めるサンプルです。

f:id:youtoy:20210504153253p:plain

ビジュアルプログラミングでのモーター制御・位置座標ベースの制御関連

短い時間間隔で動きを制御をする

質問した内容

toio DO の「つくる」のサンプルで「シンプルなコントローラーをつくる」というものがあります。
これは、アプリ上に表示された矢印アイコンを押すと toio を動かせて、アイコンを押している間だけ toio が動く仕組みで、アイコンが 1回押されるごとに 0.05秒（20ミリ秒）だけモーターを動かす処理が実装されています。

同じアイコンを押しっぱなしにすると 0.05秒分の処理が繰り返される形ですが、このとき toio の動きは小刻みな動きではなく、連続的な動きとなります。この「短い時間間隔で toio を動かす処理を連続的に実行するやり方」について「絶対位置座標指定を使う処理で似たようなことができないか？」という質問をしました。
具体的には以下のようなことを実現できるかどうか、という話になります。

  • 短い時間間隔で目標地点（目標は現在位置からすごく近い地点を指定）をどんどん変更して、絶対位置座標指定で移動させ、全体の動きを滑らかなものにする
  • 円や直線など特定の軌跡の上を正確にたどるような動きをさせる

上記 2つ目について少し補足すると、「直線上を移動させたいのなら、両方のモーターを同じスピードで動かすだけで良いのでは？」などという話に思えるかもしれませんが、実際にやってみると意図した角度とずれた方向に動いたりします。

質問への回答

自分で試しに「短い時間間隔で絶対位置座標指定を使った動作を繰り返すような処理」を作ってみると、toio の動きがガタガタしてしまっていました。そこで、そもそもそのようなことが実現できるかどうかを確認した形ですが、回答は「実現不可だが、意図した軌跡の上を動かすのは別のやり方がある」というものでした。

ちなみにこれができない理由は、「ビジュアルプログラミングの絶対位置座標指定での移動は、現在位置から目標地点までのモーター制御で加速と減速を行う仕様であるため」とのことでした。加減速が間に入りつつ動き続けるので、動きがガタガタしてしまうようです（なお、絶対位置座標指定で動く速さを遅くしてやれば、加減速が目立たず連続的に動くような感じに見える、とのこと）。

回答の続きですが、意図した軌跡の上を動かす方法の 1つは「つくる」のサンプルの STAGE 7 にある「PID制御で円運動」と似たようなことをやる、というものです。
少し補足すると、上で書いていた「直線上を動かしたいのに、意図した軌跡からズレて動く」という時に「常に toio の位置座標と意図した軌跡とのズレを比較しつつ、そのズレを補正するようにモーターの制御を動的に変える」という対応をします。

余談

今回のもくもく会で、 以下の 2つの話を見聞きしました。 　・簡易マットの上に簡易カードを置いて、簡易カードに触れたら特定の地点にたどり着いたことを判定をする仕組み
　・クリアケースで簡易マットを挟み込んで保護

そして、その後にふと思いついて、以下のゲームを作ってみました。

www.youtube.com

使ったブロックは 11個となっています。

f:id:youtoy:20210504194448j:plain

仕組みの詳細については、以下の記事に書きました。
●#toio を捕まえるゲームを #toioDo で作ってみた【 #GWアドベントカレンダー 2021/5/5 】 - Qiita
　https://qiita.com/youtoy/items/4d024906b3238d03881f