毎日一問をこなすようにしているSWITCHのパズル
毎月最後の日は、難しい問題が出題されます。
さて、本日は大晦日（もちろん月の最後の日）なので難しい問題ですね。
で・・・回答がこれ（そんなに難しくなかった）
良く確かめてから、「判定」を実施！
よし、正解だ！
正解なので、丸スタンプがもらえました。
一か月、コツコツ実施して、全日丸スタンプで埋まりました。
ということで、今月は免許皆伝をもらいました。
毎日、コツコツと積み上げていくことが大切ですね・・・（笑）
また、来年も頑張ろう・・・では！
早いもので、明日はもう大晦日ですね。
新年を迎える準備として、時計の毎年恒例の時刻合わせをしました。
JST（日本標準時）を見ながら、秒まで合わせます。
日付も確認
2023年12月30日
これで、スッキリ！ 新年が迎えられそうです。
頂き物の オレオクッキー
スーパーマリオバージョン！
クッキーにマリオキャラが１つ１つ刻印されています。
なかなか凝ってます！
美味しいのですが・・・ちょっと甘さがきついですかねぇ!?
いつも使えているものが、急に使えなくなると、とっても困ります。
クルマを使おうと思って・・・
普通なら、ドアノブを引くと・・・ピッといってロックが解除されるのですが、何のリアクションもありません。
これは、焦ります。
バッテリーをあげちゃったかなぁ・・・と、とても心配です。
で、結果からすると、リモコンキーの電池切れでした。
リモコンキーのカバーを開けて、電池の電圧を計ったら2.5Vだったので、ヤッパリ電池切れでしょう。
慌てて、ダイソーにボタン電池を買いに行きました。
私のリモコンキーが電池切れと言うことは、M&Y母のリモコンキーも危ないだろうと思って・・・家じゅうのリモコンキーの電池を交換しました。（しときました！）
電池を交換してから、あるふぁ君（プリウス）のところに行って・・・ドアノブを引くと「ピッ！」といって、ロックが解除されました。
あ～良かった！
歩っと、一安心です。
それにしても、（電池切れに）気が付いたのが本日で良かったです。
早朝や、旅先だったら、パニクっていたかも・・・です。
もう、このシリーズも「その４」です。（笑）
4.6.10.b. ii. Walls are marked by '1'; holes as '2'; swamps as '3'; checkpoints as '4'; starting tile as '5'; connection tiles from 1 to 2 as '6', 2 to 3 as '7', 3 to 4 as '8' and 1 to 4 as '9'; wall tokens as the corresponding wall token code (H,S,U,F,P,C,O) and any other tiles/edges/vertices should be '0'.
壁には「1」のマークが付けられます。 穴は「2」です。 沼地は「3」。 チェックポイントは「4」。 開始タイルは「5」です。 接続タイルは 1 から 2 が「6」、2 から 3 が「7」、3 から 4 が「8」、1 から 4 が「9」となります。 対応する壁トークン コード (H、S、U、F、P、C、O) としての壁トークン、およびその他のタイル/辺/頂点は「0」である必要があります。
マッピングボーナスで、作るマップの要素の説明です。
で・・・今回の2024年ルールで「エリア１とエリア３の接続タイル」「エリア２とエリア４の接続タイル」が追加になったのですが、それが定義されていません。 もうすでに数字は使い切っているので、アルファベットを追加するのでしょうか？
とにかく、ルールを変更したのなら、ルール全体で整合性を取ってくださいよ！
さて、今回の2024ルール（DRAFT）で最大のハチャメチャぶりを発揮するのが下の図（2023ルールから変わっていないのですが・・・変わっていないことが問題！）
4.6.10の下の図
これが、ルールにマッチしていません。
ルールにマッチしていないところ その１
ルール4.6.10.c.ではエリア４は「０（ゼロ）」で埋めると書かれています。しかし上の図ではエリア4の領域は「＊」で埋められています。
「０」なの「＊」なの、どっちなんだい？
ルールにマッチしていないところ その２
ルール2.3.4には、「エリアとエリアの接続タイルには２つの壁がある」と書かれています。 でも上の図では、エリアとエリアの接続タイルに壁が１つしかありません。
接続タイルには２つの壁が必要なんだよね!?
ルールにマッチしていないところ その３
エリアとエリアの接続タイルに被災者（壁トークン）が設置されると、ルール4.6.8に定義されているエリア乗数の説明と合わなくなります。（だから、接続タイルには得点イベントを設定できないハズ） 上の図では、接続タイルに被災者（壁トークン）が設置されています。
これは、矛盾ですねぇ・・・これ、Forumでも確認したのに、修正されていません。
ルールにマッチしていないところ その４
ルール2.5.3では、エリア４の出入口（にある接続タイル）の次のタイルはチェックポイントがあると書かれています。しかし、上の図では、エリア４の出入口の次のタイルが、チェックポイントタイルになっていません。
ちゃんと、ルールにマッチした絵（図）にしてくださいよ。
そして、Forumで指摘して、間違っていることを認識したのだから、ちゃんと修正してくださいよぉ！
5.1.1. The competition will consist of multiple rounds of which the worst one or more will be omitted from the final score. The worst round is defined by the lowest normalized field score of the team.
競技会は複数の競技ラウンドで構成され、そのうち最低得点の 1 つ以上が最終スコアから除外されます。 最悪得点のラウンドは、チームの最低の正規化されたフィールド得点によって定義されます。
１回の競技の得点は field score（フィールド得点）と書かれています。
でも・・・ルール4.6.12ではrobot score（ロボット得点）と書かれています。
field score と robot score の、どっちが正しいの？（おそらく field score が正しい）
これも、今回、Rescue Line や Rescue Maze と用語を合わせる変更をしたけど、一部の修正し忘れと思われます。
しっかり、作業してくださいよ！（そして、しっかりチェックしてくださいよ！）
いや～ 長かった！
とにかく・・・ルールに合っていない図や絵が掲載されているルールは、ダメでしょう！
いくら DRAFT版でも、さすがに、これは酷過ぎますよねぇ。
RoboCupJunior の Rescue Committee は、一体どうしちゃったの？
RCJRescueSimulation2024RulesDraft.pdf（Last updated: 2023-10-08 ） を読んでみて・・・の第三弾です。
3.6.1. Teams must make modifications within the schedule of the tournament, and teams cannot delay tournament play while making modifications.
チームは競技会のスケジュール内で変更を行う必要があり、変更を行っている間、チームはトーナメントのプレーを遅らせることはできません。
これだけ読むと、全くの意味不明の文章です。
チームは変更しなければならない・・・何を変更するのでしょうか？
と、クエッションマークが頭に立ちますよね！
これは、Rescue Simulation のルールを作るのに参考にした Rescue Maze のルールから 3.5.1に該当する項目を削除してしまったので、意味が分からなくなってしまいました。「ルールに違反している場合は」という説明が抜けてしまっています。 だから「ルールに違反している場合は、チームは変更する必要があります」ということです。
いや、これ、誰も疑問に思わないのでしょうか？（不思議）
で・・・ロボットを作る Rescue Line や Rescue Maze は、作ったロボットがルールに違反していたら変更（修正）するまで競技に参加できない・・・と言うのは分かるのですが・・・ Rescue Simulation で、「変更するまで競技に参加できない」というのは、どういう状況に発生するのでしょうか？ 想像ができないのですが・・・
4.2.2. The referee performs all operations of the simulation environment in-game, such as loading programs and operating LoP.
審判は、プログラムのロードや競技進行停止の操作など、ゲーム内のシミュレーション環境のすべての操作を実行します。
競技用のプログラムのロードを審判が実施するのはオンライン競技会の場合であって、オンサイトの競技会の時は（ルール4.4.1に書かれているように）チームがプログラムを実行します。ということで、ルールが正しくありません。
もっとちゃんと整理してよ！
4.3.8. * Teams must submit the source code and any other required documents before a particular day set by the RoboCupJunior Rescue Committee. Organizers will share details through the Official RoboCupJunior Forum.
チームは、ロボカップジュニアレスキュー委員会が設定した特定の日までに、ソースコードとその他の必要な書類を提出する必要があります。 主催者は公式ロボカップジュニアフォーラムを通じて詳細を共有します。
ここにも、チームが提出したソースコード（プログラム）やドキュメントを公開するって、書かれています。
勝手に公開しないよね、ちゃんとチームに公開の許可を得るよね・・・
と、私が書くのは・・・
Rescue Line のルールでは、ちゃんと
The organizers will not share the source code with other teams without the team’s permission.
チームに許可をとってから公開する、と書かれているからです。だから、Rescue Simulation でも、公開するのなら、ちゃんとチームの許可を取ってよ！ （Rescue Line や Rescue Maze と書き方を合わせてよ・・・）
4.4.1The next team in line should prepare the computer submitted at the beginning of the previous team’s round to run the program as a client to the game server. The referees will give a maximum of 2 minutes.
次の順番のチームは、前のチームの競技ラウンドの開始時に提出されたコンピューターを準備して、競技サーバーのクライアントとしてプログラムを実行する必要があります。 審判はその作業に最長 2 分を与えます。
ちょっと翻訳した日本語がアレですが・・・
前のチームの競技が始まったら、次のチームが競技サーバに接続したりして準備をする、と書かれているのですが、前のチームの準備中に、（競技中の）さーバーにアクセスしたりしません（やらせません）よね。
ここも、ちゃんと整理してくださいよぉ！
4.4.4. The game time allowed is 8 minutes in real time (not simulated time). Since this is a simulation, an additional one-minute real-time will be allowed. Thus, judges will terminate the controller when 9 minutes of real-time expire.
許可される競技時間は、リアルタイムで 8 分です (シミュレーション時間ではありません)。 これはシミュレーションであるため、追加の 1 分間のリアルタイム時間が許可されます。 したがって、9 分間のリアルタイム時間が経過すると、裁判官はコントローラーを終了します。
ここは、私の英文解釈能力が無いだけのことかもしれません。
競技時間は実８分・・・これは分かりました。
で、さらに実時間の１分が追加されて９分・・・なんで追加されるの？
シミュレーション上の８分が実８分よりも遅い（長い）かもしれないから？
だとすると、PCの性能によって、シミュレーション上の８分が終わる前に（実９分が経過してしまって）途中で競技が中断（終了してしまうかもしないってこと？ 良く分かりません）
この4.4章に書かれている内容についてですが・・・
4.4.1 4.4.2では、チームがPCを競技サーバに接続したり、チームのプログラムをサーバに」接続したりします。
ところが4.4.6では、審判がプログラムをロードすると書かれています。
4.4章の中で書かれていることが矛盾していませんか!?
おそらく、4.4.1～4.4.3はオンサイト競技会の場合で、4.4.6はオンライン競技会の場合を想定してると思われます。（4.4.6は2021年のオンライン大会の時の記述が残ったままなのだと思われます）
4.5.2. The Robot can be installed in any direction.
ロボットはどの方向でも設置可能です。
競技進行停止後の再スタート時に、ロボットの方向を自由に決められる、と書かれていますが・・・実際は競技システムが（ロボットの方向を）勝手に決めます。（だから、ルールのここの記述はおかしいです）
これも、Rescue Maze のルールが、（見直しをされず）そのまま残っているのだと思われます。（Rescue Maze は競技進行停止からの再スタート時に、チームがロボットの方向を自由に決められる）
4.6.3a. For wall tokens located on a tile on a linear wall or adjacent to a linear wall (even diagonally),
リニア壁またはリニア壁に隣接する (斜めであっても)タイルにある 壁トークンの場合
これまではリニア壁、フローティング壁と壁をベースにしていましたが、今回から（壁ではなく）タイルをベースにする考え方に変更しましたよね。 にもかかわらず、「リニア壁」「フローティング壁」の記述が残ってしまっています。
ちゃと、ここも変更してくださいよ！
ここは
リニア壁→リニアタイル
フローティング壁→フローティングタイル
ですね。
いや、こんな単純な間違いをしないでよ・・・
4.6.7. However, the total points will never go below zero points.
ただし、合計得点が０点を下回ることはありません。
合計得点がマイナスになることはありません・・・これだけ読むと、普通なのですが・・・
4.3.3 The score of the game will be -50 points.
ここに書かれているマイナス50点はどうなるの？（０点になるの？）
う～ん よくわかりません。
ということで・・・ハチャメチャなルールは、まだまだ続きそうです・・・
続く・・・
RCJRescueSimulation2024RulesDraft.pdf（Last updated: 2023-10-08 ） を読んでみて・・・の続きです。
2.3.7 の下の絵
Rescue Maze と同様に、スタートタイルの壁を挟んで隣のタイルは、（この絵では Floating tileになっていますが） Linear tile ですよね！
それから、この絵の説明の中、 colour と表記されています。本文では color なので、ちゃんと統一して欲しいです。
2.3.8 が削除されました。ここには「走行可能な通路は幅12cm 」という書かれていたのですが、それが無くなったので、通路はロボットの幅（8cm）ギリギリかもしれません。
つまり、壁の状況を把握して、「ここは通路」「ここは通路ではない」の判断をすることはできなくて・・・とりあえず進んでみて・・・ロボットが詰まれば「ああ、ここは通路ではない」と判断することしか出来ないってことなのかなぁ？
2.3.9 が削除されました。 ここには、「エリア４はフィールド全体の４分の１以下」と書かれていました。 まあ、あんまり影響ないですかねぇ。
2.4 The colors of the passages are as such:
• Between Area 1 and 2: Blue
• Between Area 2 and 3: Purple
• Between Area 1 and 3: Yellow
• Between Area 3 and 4: Red
• Between Area 4 and 1: Green
• Between Area 1 and 4: Orange
ハチャメチャさの本領発揮です！
エリア１とエリア３、エリア２とエリア４の接続タイルが追加されたハズ・・・なのですが・・・最後に書かれているのは「エリア１とエリア４」？？？
「エリア４とエリア１の接続タイルは緑色」「エリア１とエリア４の接続タイルはオレンジ色」この２つの違いはが分かりません。
これ、「エリア２とエリア４」の間違いですよね。 「エリア４とエリア１」の表記も、整理されていません。（普通なら「エリア１とエリア４」ですよね）
この表記ミスとか・・・公開前に、Committeeの中で、誰も確認も指摘もしないのですかねぇ !?
2.5.2. Silver tiles will be placed randomly throughout the field.
フィールド全体に銀色のタイルがランダムに配置されます
赤色になっているので、なにか修正したみたいですが・・・おかしいのは変っていません。
「銀タイルはランダムに配置される」と書かれていますが、銀タイル（チェックポイント）はランダムには配置されません。（コース設計者が、きちんと設計して配置されますよね。）
なぜ、このおかしなルールが修正されないのか謎です。
2.6.1. All these items will be placed in random locations in the field with the following restrictions.
これらのアイテムはすべて、以下の制限付きでフィールド内のランダムな場所に配置されます。
この章は、沼地、障害物、穴なので、これらの配置についてです。
で、これらの配置がランダムに配置されるって・・・「ランダムに配置」が好きですねぇ！
勿論、ランダムには配置されませんよね。（ちゃんと、コース設計者が設計した通りに配置されますよね）
それとも、2024年ルール用のコース管理ツールには、チェックポイントタイルや沼地、障害物などをランダムに配置する機能があるのでしょうか？
2.6.3 a. May be fixed to the floor.
床に固定してもよい。
（Google先生の）翻訳が微妙に違うかもですが・・・「障害物は床に固定されている」訳ではないってこと⁉
と言うことは、ロボットが押すと、障害物が動くかもしれないってこと !?
（まあ、そんなこと無いと思いますが・・・）
2.6.3 d. が削除されたので、障害物を置く場所の制約が無くなりました。（どこにでも置けるってこと）
3.5.5 All teams have to submit their source code before the competition. The organizers will share them online after the competition such that other teams can draw inspiration and learn from them.
すべてのチームは競技会の前にソースコードを提出する必要があります。 主催者は競技後にそれらをオンラインで共有し、他のチームがインスピレーションを引き出し、そこから学ぶことができるようにします。
う～ん、これも、前回指摘して、修正する・・・と言う回答があったはずなのですが・・・修正されていませんねぇ。
チームが事前に提出した、コード（プログラム）はオンラインで共用する、と書かれていますが・・・チームが提出したコード（プログラム）は、勝手に公開されちゃうの？ そんなことないよね！
勝手にチームのプログラムが公開されたら困りますよね。（チームに「公開してもいい？」と確認して許可を得てから公開することになっているようなのですが、このルールの記述が間違ったままになっています）
う～ん、まだまだハチャメチャなルールは続きそうなので、今回はここらで終了にします。
続く・・・
RoboCupJunior のレスキュー競技の2024年ルールですが・・・Rescue Line 、Rescue Maze と読んでみたので、最後は Rescue Simulation（DRAFT版） のルールを確認してみます。
確認したのは RCJRescueSimulation2024RulesDraft.pdf（Last updated: 2023-10-08 ）」です。
以下私が「んっ！」と思ったところです。
Before you read the rules の
Sections of the rules that apply specifically for in-person competitions and online competitions will be marked with a " * ".
対人競技とオンライン競技に特に適用されるルールのセクションには「 * 」のマークが付けられます。
相変わらず、「*」のマークの意味が分かりませんねぇ。 「*」が付いていると、オンサイト競技もオンライン競技の両方に関係する・・・じゃあ「*」が付いていないと、両方には関係しないの？
そもそも、もう（コロナ禍が過ぎたので）世界大会はオンライン競技じゃないから、オンライン競技については書く必要が無いよね！
Before you read the rules の最後の文章
There are two kinds of wall tokens - letter victims and hazmat signs. Terms 'WT' or 'wall tokens' will be used throughout this document to refer to both hazmat signs and letter victims.
壁トークンには、文字の被災者と危険物標識の 2 種類があります。 「WT」または「壁トークン」という用語は、この文書全体を通じて、危険物標識と文字の被災者の両方を指すために使用されます。
これまで、被災者は単に victim だったのですが、今回初めて letter victim と表記されました。（だったら、Rescue Maze も visual victim ではなくて letter victim に統一しましょうよ）
また、得点要素として、文字の被災者と危険物標識がありますが、これらをまとめて「壁トークン（wall token : WT）」と、表記することになりました。
この用語の整理で、ちょっとスッキリしましたね。
ただ、Scenario の長い文の中に（変更部分だから） wall tokens が赤色で記載されているのですが・・・他にもいくつか wall tokens の表記があるのに、赤色になっていません。
やっぱり、このルール、整理不足でしょうか・・・
で・・・この Scenario の下にあるフィールドの全体図（絵）ですが・・・
ルールにマッチしていませんよね。
ルール2.4で「エリア２とエリア３の接続タイルは紫」と規定されているのに、上の絵では赤になっています。 そして上の絵では、エリア１とエリア３の接続タイルが紫になっています。
ということで・・・ルールにマッチした絵を掲載して欲しいです。（逆に、ルールにマッチしていない絵を掲載してはダメでしょう！）
さらに・・・このフィールドの絵ですが・・・まじまじと見ると・・・銀のタイルと（エリア２とエリア３の間にある）赤のタイルは、ありえない（設置できない）位置にあると思います。
（そろそろ、ハチャメチャさが爆発してきます・・・）
2.1.4. * The organizers will collect all the teams' simulation software before the competition is recorded.
The recordings will be used as competition runs and showcased during the competition.
競技運営者は、競技が記録される前に、すべてのチームのシミュレーション ソフトウェアを収集します。
録画は競技の実行として使用され、競技中に披露されます。
この2.1.4ですが、競技前に各チームが作成したプログラムを集めると書かれています。 でも・・・2.1.3でチームはプログラムを提出するのではなくて、チームが使用しているPCをサーバにLAN接続することで競技を実施します。
なので、2.1.3で競技を実施するのなら、2.1.4でプログラムを収集する必要は無いよね！
2.1.3と2.1.4が全くかみ合っていません。
ということで、全く意味が分かりません！
2.3.6. Tiles that lead to the starting tile consistently following the leftmost or rightmost wall are called 'linear tiles'. The tiles that do NOT lead to the starting tile consistently following the leftmost or rightmost wall are called 'floating tiles'.
左側または右側の壁に沿って進むと開始タイルに続くタイルは、「リニアタイル」と呼ばれます。 左側または右側の壁に沿って進んでも開始タイルにつながらないタイルは、「フローティング タイル」と呼ばれます。
Rescue Mazeと同じように被災者の得点区分が壁からタイルに、整理されました。（実質的には、Rescue Simulation には立体交差が無いので、変更する必要は無かったのですが、統一感を持たせた変更として歓迎します。）
2.3.7. Black holes will affect the determination of the tile type (linear or floating) since they can be considered virtual walls.
黒の穴は仮想的に壁とみなすことができるので、タイルの種類（リニアまたはフローティング）の決定に影響します。
黒のタイル（穴があいている）は、通常は hole と表記されているのですが、なぜかここだけ Black hole と書かれています。 なんだかロボットが吸い込まれて二度と戻ってこないような感じですね・・・（笑）
まだまだありそうなので、今回はここらへんでいったん終了にします。
続く・・・
本日の昼食はバーガーキング
M&Y母が店頭で購入するので、各自食べたいものをLineします。
で・・・Yが注文したのが「ザ・ワンパウンダー」
もう、紙袋から取り出す時点で・・・「お、重い！」
左上のが「ザ・ワンパウンダー」
厚みと言うか、高さが凄い！
（右上のは、私が注文した「ビッグベット」）
M&Y母の、ワッパーJrと比べると・・・
これ、一口で縦に食べるの無理なんじゃない・・・
（私も、一口食べさせてもらいましたが・・・おいしい！）
で・・・さすがに、Yも食べきれずに、ちょっとだけ、「お残し」（笑）
残したものは、夕食においしくいただきました・・・
いや～、凄い迫力、凄いボリューム、でもちゃんとおいしい
ここのところ寒い日が続いていますが・・・
朝のゴミ出しで、ふと見ると、クルマのフロントガラスが凍っていました。
まじまじと見ると奇麗なのですが・・・寒い！
前の記事はこちら 親指シフトキーボードプロジェクト その39
決まった文字列を簡単に入力できるようにしたかったのですが・・・動的マクロでは（電源OFFでリセットされてしまうので）できませんでした。
ということで、今回は、まじめにマクロを設定します。
参考にしたのはここ
で・・・あっさりできました。
keymap.c
の中にある
enum custom_keycodes {
に KC_ID を追加します。
次に
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
の中に KC_ID を追加します。 私はFN+Qキーの位置に追加しました。
最後に
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
の中に
case KC_ID:
if (record->event.pressed) {
send_string("xxx@yyy.zzz.com");
}
return false;
if (record->event.pressed) {
send_string("xxx@yyy.zzz.com");
}
return false;
break;
を追加しました。（あれっ、これ break は必要？）
を追加しました。（あれっ、これ break は必要？）
これで、コンパイル＆書き込みをして・・・
FN+Qキーで「xxx"yyy.zzz.com」と入力されました。
「@」がうまく入力されません。
う～ん
いろいろ過去の資料とか見たら・・・英字キーボードと日本語キーボードの違いなのか、「@」を入力する場合は「[」を指定すれば良いようなので・・・
今度は
send_string("xxx[yyy.zzz.com");
と設定して、再度書き込みました。
はい、終了！
FN+Qキーで xxx@yyy.xxx.com が入力されるようになりました。
これで、毎回、長い文字列を打ち込まなくて済むようになりました。
続きの記事はこちら 親指シフトキーボードプロジェクト その41
前の記事はこちら 親指シフトキーボードプロジェクト その38
ネットを使用していると、IDやパスワードを入力する機会がたくさんありますよね。
しかも・・・IDにメアドを使用したり、長いパスワードを要求されることも多く・・・毎回同じような長い文字列を入力するのが面倒だったりします。
そんな時に、キーボードに、特定の文字列を記憶出来たら、便利です。
で・・・それを実現できるのかな・・・と思って実験してみたのが動的マクロです。
まず、rules.mk に DYNAMIC_MACRO_ENABLE = yes を追加します。
そしたらキーマップに DM_REC1 、DM_RSTP 、DM_PLY1 を割り当てます。
コンパイルして、キーボードに書き込みを実施してから
DM_REC1 覚えさせる文字列 DM_RSTP の後に
DM_PLY1 で、「覚えさせる文字列」が入力されます。
これは便利！
と・・・思ったら・・・
電源OFFでリセットされる機能でした！
ガックシ
続きの記事はこちら 親指シフトキーボードプロジェクト その40
久しぶりに洒水の滝に・・・
やっぱり、素晴らしい眺めですなぁ・・・
（渡れないけど）手前の赤い橋がいい味出してますよね。
で・・・いつの間にか、観瀑台なるものが出来ていました。
全部で226段の階段は、なかなか厳しいものがあります。（笑）
はぁはぁ息をしながら、やっと上まで上ると・・・
滝がすぐ近くに見えます。
うん、なかなか凄いです。
滝が、上から下まで丸見えです！
ただ・・・
観瀑台は、結構な高さなので、高所恐怖症の私には、下を覗くのも勇気が必要です！
来年（2024年）のロボカップジャパンオープン
今年（2023年）と同じ、滋賀ダイハツアリーナで、4/26～29で開催されるようです。
アクセス
トータル
ランキング
