毎日欠かさずやっている脳トレのパズルゲーム
毎月最後の日は、難易度の高い問題が出題されます。
本日も、なかなかの難題でしたが・・・30分以上かけて解きました。
で・・・正解！
（ほっ！）
これで、1か月間全部正解なので・・・
今月は、免許皆伝をいただきました。
本日は大晦日
明日は新年です。
2025年を頑張って、毎日一問を欠かさず実施したいとと思います。
では、皆様、よいお年を・・・
明日は、いよいよ大晦日です。
今年一年間ありがとう・・・ということで、時計の電池を交換して、きっちり時刻を合わせなおしました。
（私が、よく使うのは JST Clock です。）
また、一年間、がんばってください・・・
なんだか私のPCの調子がおかしくなってきました。
使用して、そのあと放っておくとレジュームになりますが・・・そのレジュームから復帰すると、キーボードが使用できなくなる・・・という現象が頻発するようになってきました。
キーボードは、外付けに親指シフトキーボードを付けているので、実質的な問題ではないのですが、それでも不安です。
ということで・・・一日かけてPCの引っ越しをしました。
（新しいPCは、手に入れていたのですが、引っ越しが面倒なので、そのままにしていた）
まあ、新しいPCといっても、ヤフオクで２万円くらいで手に入れた中古ですが・・・
OS や MS-Office のインストールは、何度もやっていて慣れっこなのですが・・・個別に入れていたアプリが面倒です。（インストール手順とか、忘れたし・・・）
さらに、フリーソフトなどは、バージョンが上がっているものもあり、バージョンが上がったら非互換で動作しなくなっていたり・・・もう、いろいろ大変です。
でも、まあ、なんとか使えるようになってきました。
あと・・・何があったっけ？ そうだ、RCXを動かすやつだ・・・
マレーシア（クアラルンプール）で買ってきた Asam Laksa
前回はラーメン風に調理したので、今回は焼きそば風に挑戦です。
作り方を、もう一度、Google レンズで翻訳しておさらい。
お湯で１分間煮て、水けをきって、野菜と入れて、味付けする
みたいな感じ・・・揚げるという言葉があるので、茹でた麺を炒めるの？
まあ、良く分からないけどやってみます。
まず、麺を１分間茹でます
ラーメン風だと２分茹でるけど、今回は１分でいいの？
はい、１分茹でて、水けを切りました。
これをもう一度鍋に戻して炒める！？
そして、スープの粉を（全部入れたら、ダメだと思って半分くらい）入れて、混ぜます
うん、失敗です。
炒める必要は無かったようです。
鍋の底に、麺がこびりつきました。
ただ、お湯を捨てて、スープの粉を混ぜれば良かったのかな。
（カップ焼きそばみたいに・・・）
で、出来たのがこちら。
麺を１分しか茹でてないので、大丈夫かと心配でしたが・・・
その硬いところが、ちゃんと焼きそば風になってます。
スープの粉は半分でも多い感じでした。
うん、おいしい！
なんか、初めての体験です。
ウルトラマン商店街のマンホール
駅前のウルトラマン
渋谷のハチ公前のように、待ち合わせ場所とかになっているのか、ここだけ人が多い・・・
近くでみると、なかなかりりしいのですが・・・
ちょっと離れてみると・・・小便小僧に見えてしまうのは、私の心が清らかでないからでしょうか・・・（笑）
たまに RCJJ Forum を見てます。
ブログのネタあさりとか・・・（笑）
で・・・今回見つけたのがこれ
私は、英語が苦手なので、必ず機械翻訳で日本語にして読むのですが・・・
I can only find a template for the TDP in Microsoft Word format (.docx). However there are some people (like me) who haven’t sold their soul to Mircosoft.
TDP のテンプレートは Microsoft Word 形式 (.docx) でしか見つかりません。しかし、Microsoft に魂を売っていない人々 (私のような人々) もいます。
投稿された内容は・・・何で、TDPのファイルはMS-WORDの文書ファイルしかないの？ というものなのですが・・・読んでいて・・・魂を売る・・・そんなことが書かれているの？ それ、英語ではどう書くの？
魂を売る というのを 英語では sell one's soul というのを初めて知りました。 英語でも同じ魂（soul）なんですね！
手持ちの電子辞書で調べると
Sell one's soul ( to the devil )
金などのために良心に反した行動をする どんな犠牲をも払う
と書かれていました。
まあ、今回は、たわいもないネタでした。
もう、一か月以上が経過してしまいました。
RCJJ（RoboCupJunior JAPAN）東東京ノード大会 神奈川・西東京ノード大会 のレスキューコースです。
Rescue Line のフィールドA
こちらはフィールドB
AフィールドもBフィールドも、難しいと思えるところが、全くありません。（笑）
もう、これは、少なくともライントレースの部分はみんな満点だね！・・・というスタッフからのプレゼントだと思います。
ただ、意外と苦労していたのが「波型の直角」で、近年のロボットは直角に弱い感じがします。（２つの光センサーでライントレースしていて、その２つのセンサーの距離が近いから、なんだろうなぁ）
で・・・こんなにライントレース部分を簡単にしたのだから、救助ゾーンでの被災者救助で勝負してよ・・・と言うスタッフからのメッセージでしたが・・・被災者救助活動をしたチームが１チームだけ！ 後は、被災者救助の活動すらしていませんでした。（そもそも被災者救助の活動をするための機構を持っていないロボットも多数・・・）
これ、救助ゾーンをコースの前半に配置して、「少なくとも一人の被災者を救助しないと、救助ゾーンがら出られない」くらいのルールにしないと、被災者救助がまともに行われないのかもしれません。
さて、今度はチャレンジクラス Rescue Line Entry のコースです。
こちらがAフィールド
こちらがBフィールド
どちらも、難しいところは無いと思うのですが・・・
やっぱり、直角で外れるチームが多かったです。
ただ、上位チームは、さすがライントレースの部分は満点で、救助ゾーンでの被災者救助数や競技時間での勝負になったり、なかなか面白かったです。
RCJ（RoboCupJunior）Forum にレスキューの 2025年ルールの変更点が掲載されたのに合わせて、これまでのルールの疑問点を質問しました。
そのひとつがこれ
Rescue Simulation 2024 Rules の
2.5.2 Silver tiles will be placed randomly throughout the field.
銀タイルは「ランダム」に配置される。
いや、ランダムには配置されませんよね。 コース設計者が設計したとおりに配置されますよね・・・。
ということで、なんでランダムに配置されるって書かれているの？
という質問をしました。
これ、以前にも同じ内容を質問したことがあって・・・そのときの Committeeの回答は、「ランダムとは、競技毎に設置する場所が違うということです」と言う回答がありました。「それなら、何で銀タイルだけランダムに配置と書くの？ 壁だって、被災者だって、障害物だって、すべてのものが競技毎に設置場所が変るのだから、全部ランダムに配置すると書かないの？」と質問したら・・・「ルールには全部は書けない・・・」という謎の回答になって・・・うんダメだ、この回答者、と思いました。
で・・・今回の回答は・・・
The idea of randomness refers to the fact that there is no defined rule for how the silver tiles are placed. The same term is applied in rule 2.6 which refers to swamps, obstacles and holes. These are also defined at the time of the map design.
「ランダム性」という概念は、銀のタイルがどのように配置されるかに関して明確なルールが存在しないことを指します。同じ用語はルール2.6にも適用されており、そこでは沼地や障害物、穴についても言及されています。これらもマップ設計時に定義されます。
えっ、そういうことなの？
ランダムっていうのは、「配置のルールが無い」ということらしいです。 言い換えると、どこにでも配置される（どこにでも配置していい）です。
ということで、「ランダムに配置される」と思っていたことが間違いでした。
そうすると、いま、RCJJ レスキュー技術委員会から提供されているレスキューリーグの日本語版ルールの表記は、ことごとく間違っていることになります。
例えば Rescue Line では
2.9.11 審判は、救助ゾーン内の出入り口の無いコーナーに避難場所をランダムに配置できます。
ですが、これもランダムに配置するわけではなく、単に「コーナーであれば、どこにでも配置可能」ということで、競技の運用（やり方）について書かれている訳ではないことになります。
同様に
2.10.4. 競技運営者は救助ゾーン内で被災者をランダムに配置します。
これも、ランダムに配置する訳では無く、救助ゾーンの中ならどこに配置しても良い、と書かれているだけのことですね。
どうも、ランダムというと、サイコロを振って偶然の出目で何かをするようなことを想像してしまうのですが・・・そうでは無い場合もあるというのを初めて知りました。
ただ、じゃあ、random は偶然の意味は無いのか？ というと・・・
4.3.11 の ランダム化方法に基づいて行われる や 4.5.6 の 被災者はランダムに救助ゾーンに配置されます は、偶然性のランダムのことらしいです。
つまり、random には
①ルールがないこと（配置するルールが無い。だからどこでも配置できる）
②サイコロを振るような偶然性で決まること
の２種類があるようです。
う～ん、日本人には、なかなか難しい！
で・・・今回の説明を聞いて、「なるほど」と思ったのですが・・・
例えば、Rescue Line 2024 ルールの 2.5.2 には
Speed bumps may also be placed anywhere in the evacuation zone.
このように「どこにでも配置できる」という表現「も」使われています。
どこにでも配置できる、の同じ意味なら、２つの表現ではなく１つの表現に統一して下さいよぉ・・・
という要望を Forum に入れましたが・・・リアクションはありません・・・
先日の RCJ Rescue Rules 2025 の変更内容が Forum に掲載された件で・・・いくつかの意見が投稿されています。（私も、いくつか投稿しました）
その中で、「エンジニアリングジャーナルの提出不要」があります。
A.2) Elimination of Engineering Journal and introducing Presentation Video
The requirement to submit an Engineering Journal has been removed. Instead, each team is required to create and submit a short video presentation showcasing their work. These videos will be presented during the competition and should summarize the key aspects of the team’s project, design process, and innovations. The rubrics for video and TDP will be updated and will continue to have a weight in the team’s final score.
A.2) エンジニアリングジャーナルの廃止とプレゼンテーションビデオの導入
エンジニアリングジャーナルの提出が廃止され、代わりに各チームは自分たちの成果を紹介する短いプレゼンテーションビデオを作成して提出することが求められます。このビデオは競技会中に発表され、チームのプロジェクト、設計プロセス、および革新の主要な要素を要約する内容である必要があります。ビデオとTDP（技術設計文書）の評価基準は更新され、引き続きチームの最終スコアに影響を与えることになります。
これが、Committeeが掲載した元の文章です。
エンジニアリングジャーナルの提出を指せない代わりに、チーム紹介ビデオ（動画）を作成して、提出する、という変更です。
で、この「エンジニアリングジャーナルの提出不要」について、いくつか意見がだされています。
一つ目が SanjaTronic 氏の投稿
Regarding the point “(A2) - Elimination of Engineering Journal and Introducing Presentation Video,” we discussed this as a team and concluded that the removal of the Engineering Journal could be detrimental in future seasons.
「（A2）- エンジニアリングジャーナルの廃止とプレゼンテーションビデオの導入」に関して、私たちはチームとしてこの点を議論し、将来的なシーズンにおいてエンジニアリングジャーナルの廃止が悪影響を及ぼす可能性があると結論しました。
As a team dedicated to documenting our work, we believe the Engineering Journal greatly facilitates the understanding and connection of different areas and knowledge related to the competition. A well-maintained journal not only ensures organized planning but also supports a logical workflow. Additionally, it helps the evaluation committee identify teams that have not complied with regulations, upholding the principle that robots must be designed and programmed exclusively by team members.
私たちは、作業の記録を大切にしているチームであり、エンジニアリングジャーナルが競技に関連するさまざまな分野や知識を理解し、結びつける上で非常に有益であると考えています。よく整備されたジャーナルは、計画を組織的に進めることを保証するだけでなく、論理的なワークフローを支援します。また、評価委員会が規定に従っていないチームを特定するのにも役立ち、ロボットがチームメンバーによってのみ設計およびプログラムされるべきだという原則を守ることができます。
Therefore, we believe the Engineering Journal should not be eliminated but rather used as a source of knowledge and sharing among teams, fostering fair play and camaraderie, but most importantly, promoting learning.
したがって、私たちは工学ジャーナルを廃止するのではなく、知識や情報の共有のための資料として活用し、チーム間でのフェアプレーと友情を促進するだけでなく、何よりも学習を推進すべきだと考えています。
この人の「自分のチームでは作業記録を大切にしている」というのは素晴らしいと思います。ただ、「エンジニアリングジャーナルの廃止が・・・」というのが勘違いしているように思います。 Committee は「エンジニアリングジャーナルを作成しなくて良い。」と言っている訳では無く「エンジニアリングジャーナルを提出しなくて良い。（評価しない）」といっているだけです。
だから、作業記録は継続して作れば良いのではないでしょうか？
それとも、「自分たちは、ちゃんと真面目に作業記録を作っているのだから、評価して得点に加えてくれないと困る」と言っているのでしょうか？
二つ目は moritz_biobrause 氏
I respectfully disagree with @SanjaTronic perspective.
@SanjaTronicの視点には敬意を表しますが、私は異なる意見を持っています。
Last year, our experience showed that the Engineering Journal actually slowed down our development process. I believe that each team has its own unique approach to innovation and problem-solving. In our case, a rapid-iteration methodology allowed us to quickly adapt and refine our solutions, which was a key factor in our success. The requirement to maintain the Engineering Journal was a significant obstacle in this process, as it demanded time that could have been better spent testing and improving our designs.
昨年の経験から、エンジニアリングジャーナルは実際には私たちの開発プロセスを遅らせていたと感じています。私は、各チームには独自のイノベーションと問題解決のアプローチがあると考えており、私たちの場合、迅速な反復法が解決策を迅速に適応し、改善するための鍵となり、成功に繋がったと信じています。エンジニアリングジャーナルの維持がこのプロセスにおける大きな障害となり、設計のテストや改善に使うべき時間が割かれてしまいました。
While I agree that documentation can help organize planning and maintain a logical workflow, I think it’s important to recognize that not all teams benefit from the same methods. For us, the Journal felt restrictive rather than supportive. I do see the value that an Engineering Journal can provide for some teams, however, I think it should remain optional for teams that find it helpful, rather than a requirement for everyone.
ドキュメント化が計画を整理し、論理的なワークフローを維持するのに役立つことには賛成ですが、すべてのチームが同じ方法から利益を得られるわけではないことを認識することが重要だと思います。私たちにとって、ジャーナルは支援的というよりは制約を感じさせました。確かに、エンジニアリングジャーナルがあることで価値を見出すチームもあることは理解していますが、それがすべてのチームにとって必須であるべきではなく、役立つと感じるチームにとってはオプションであるべきだと考えています。
この人の意見は・・・作業記録を作るのに時間がかかってロボット開発に支障がでている。作業記録を作る時間を設計やテストや改善に回したい。
と言うことのようです。
明確には書かれていませんが「作業記録なんて必要ない」と言うことでしょうか？（さすがにそこまでの意見では無い⁉） でも最後の方に、「作業記録が必要と思えるチームだけが作業記録を作れば良い」みたいなことが書かれているので、作業記録はマストではない、という考えなのでしょう。
で・・・これらの意見に対して Rescue Committee の CsabaAbanJr 氏が回答以下のようにしています。
We still consider the creation of the Engineering Journal valuable; however, each team prepares, works, and develops differently, especially in an international setting. This makes it really challenging to evaluate uniformly and fairly without placing a burden on teams to strictly adhere to the rubric. If any criteria are not fully met, teams have two options: either they can supplement it afterward ending in a 90+ page documents that is hard to evaluate objectively, or they will receive fewer points. That is why we decided to change this to a video deliverable, which provides more flexibility to the teams and where creativity is encouraged. The goal of this video is to complement the TDP document to create a better understanding of the competitor’s understanding and development.
私たちは依然としてエンジニアリングジャーナルの作成が価値があると考えていますが、特に国際的な環境において、各チームは異なる方法で準備し、作業し、開発を進めているため、均一かつ公正に評価することが非常に難しくなっています。厳密に評価基準に従わせることは、チームに過度な負担をかけてしまいます。もし評価基準が完全に満たされていない場合、チームには2つの選択肢があります。1つは、後から補足して90ページ以上のドキュメントを作成することで、客観的に評価するのが難しくなるか、もう1つは、評価ポイントが少なくなることです。このため、私たちは評価基準を変更し、プレゼンテーションビデオの提出に切り替えることにしました。これにより、チームにもっと柔軟性が与えられ、創造性が奨励されることになります。このビデオの目的は、TDP文書を補完し、競技者の理解と開発の過程をより良く理解できるようにすることです。
We still encourage teams to develop their own engineering journal without the pressure of being evaluated in their final scores.
なお、私たちは引き続き、チームが最終的なスコアに影響を与えない形で独自のエンジニアリングジャーナルを作成することを推奨しています。
まず、ロボット開発において、作業記録をとるのは「当たり前」のことですよね。
昨日は、ここまでできたから、今日は続きをやるぞ！ 昨日は、こんな失敗があったから、その失敗を繰り返さないようにすすめよう・・・
人間、誰しも間違いがあり、その間違いを乗り越えて進むことで成長するのですが・・・その記録が無いということは、瞬間瞬間が行き当たりばったりということ!? いや、僕は記憶力が良いので、記録する必要がないんだ！ というのであれば、記録は必要無いのかもしれませんが・・・
で・・・Committeeの言い訳は・・・
・作業記録が必要無いとは言っていない。（作業記録は引き続き作ろうね）
・でも、作業記録を提出させて、作業記録を評価して点数化することはやめる。 だって評価できないんだもん。（評価が難しい）
ということです。
私も、彼らの「評価できない」という意見に「なるほど」と思っています。
（作業記録なんて、評価できないよね。 そして、そもそもドキュメントの評価を、短時間に、公正公平にできるのか？ が疑問・・・）
富士川鉄橋で新幹線を撮影した後に立ち寄ったのが「ふじのくに田子の浦みなと公園」です。
この展望台は「富士山ドラゴンタワー」と言うらしいです。
塔の高さも富士山の1/100である 37.78mというこだわりです。
その「富士山ドラゴンタワー」の上から富士山を望む
公園を出て少ししたところに、こんなものがありました。
冨嶽三十六景 東海道江尻田子の浦略図
の下の部分だけの模型
本物の富士山と合わせて撮影するのですが・・・どうしても煙突が入ってしまいます。（笑）
久々に、「新幹線と富士山」を見に、富士川鉄橋に行ってきました。
現地には 08:00頃に到着しました。
気温４℃です。（ぶるぶる）
河原に降りて、撮影スポットを決めて列車を待ちます。
（どこぞのローカル線と違って）新幹線は、次々と来るので飽きません。
寒い中、気が付くと１時間半くらい居ました。
自分のことながら・・・バカですねぇ！
まあ、とりあえず、天気も良く、ミッションコンプリートです。
日曜日（12/15）に高専ロボコンの全国大会の様子が放映されました。
今年のルールは、サンプルリターンを題材にしたルールでした。
なかなかやんちゃで、ロボットを打ち出して、離れた場所に着地させるのですが・・・その過程で壊れるロボットが続出でした。
しかも、その打ち出したロボットがボールと箱を回収する、という機能を果たさなければならないので、すごく大変です。
で・・・そんなやんちゃなルールなので、地区大会では、全く動かなかったり、ロボットを打ち出すだけで終わってしまったり・・・「もう、両方動かないので、動いたほうが勝ち！」というような、情けない競技が沢山ありました。 そして、ほとんどが着地点勝負でした。（しょうもない！ 笑）
さて、全国大会ですが・・・
放映された番組の中では、面白い（というか、まともに動いた）競技だけを紹介してくれたみたいなので、（地区大会を視聴した時のように）ストレスがたまらなくて良かったです。
さすがに、全国から選りすぐられたチームが参加する全国大会です。最後の決勝トーナメント、特にベスト４の試合は見ごたえがありました。
どのチームも、満点を取るパフォーマンスを持っていました。 だから、もうどのチームが勝ってもおかしくありません。負けたチームは、何かちょっとしたミスで優勝を逃してしまった、という感じです。
優勝した、大阪公大高専、おめでとうございます。
全ての地区大会を見て（放映された番組を見て）、一番可哀そうだったのが、四国地区大会の決勝戦で負けてしまった香川高専（高松）Aチーム。
このチームは、満点を出すパフォーマンスを持っていて、実際満点を出して決勝まで行った（だったと思う）のに、決勝戦だけトラブルでサンプルリターンができず、着地点勝負で負けてしまいました。普通なら、地区大会で優勝できなくても、素晴らしいロボットなら審査員推薦を受けられるのですが・・・最悪なことに、決勝戦の相手が同じ学校のBチームで、優勝した（してしまった）Bチームが全国大会に行くので、同校のAチームは推薦が受けられなくなってしまいました。
Aチームは全国優勝も狙えたのに・・・と、とっても残念です。
（これを見てから、決勝の同校対決は、意外とよろしくないのでは、と思うようになりました。）
まあ、100回やったら、100回満点を出せるロボットでないとダメなんでしょうね！
アクセス
トータル
ランキング
