Workshopにてサーボが大暴走！　リフターが満身創痍。
しかしトリガとなるメンバーは今回訪仏していない筈だが・・・。
取り急ぎ養生テープでご勘弁。

---

昨日までは機能テスト、今日からミッションがスタート。
台車を使ってWorkshopからUMADまで移動し、指定された場所に置くなんて所まで決められている。




思わぬところでパイプに接触したり、床の継ぎ目でクローラーのベルトが弾かれる音がUMADに響きわたる。
数々のタスクをこなし、疲れ果てスピードが落ちながらも、最終地点へ到着。
凛々しく、カッコ良かった！

---

Workshopにて早速反省会。


1stコンペはミッションをこなす事を優先したが故に、自ら強いた課題をこなし切れていないのは否めず。
目下の課題はATEX Directive 94/9 CE Zone1にどこまで近づけられるか。新たなる強力なメンバーの知見に期待を寄せて今日は終了。

前日の余韻が・・・

---

さてエネルギーを蓄えたので、本日のタスクを。
今日はオペレーションルームから遠隔操縦の機能テスト、プレゼンテーション、ナビゲーション等々朝から晩まで盛りだくさん。

おそろいのポロシャツでイザ出陣。


しかーし！　初っ端の遠隔操縦でトラブル発生。Wi-Fiがつながりにくい。
買い物品をあつらえただけなんだが、フランスの電波環境と合わなのか？
一度経験した事は繰り返す・・・。大体マーフィーの法則通りです。

一旦撤収。リベンジは最終日！

---

プレゼンテーションを挟んでUMADへ。ってかプレゼン10分、質疑35分ってどんだけ質問したいんだか。

UMAD内には2名だけ、ヘアネット、ヘルメット、グローブ、ビニールのソックスカバーを履いて、靴も履きかえる、というスクリプトルール。


ようやく我らのロボットの勇士をご覧いただける場が


着地するのも容易でない。

Good job

みんなもロボットも頑張ってくれました。
一日お疲れ様！

トレーニングセッションから程なく、ARGOS CHALLENGEの1stコンペティションを迎えたました。

しかし、何度も往復するにあたってはフランスは遠い国。
船で移動していた時代を考えると半日で到着するのはありがたいが、飛行機で座りっぱなしはある意味拷問。


ロボットは先に届いていたので、組み立てと早速動作確認。


今日はこの程度

1. Static test & Homologation(@workshop)
   -Sensors check
   -Body measurement
   -Mobility check
   -Emergency stop
   -Conflict avoidance
2. Training Session
   -Autonomous travel
   -Remote control
3. Boot Sequence
   

突然の嵐で雨漏りしたりと賑やかなワークショップ。

UMADのフロアを自立航行するのはエッセンシャルな機能。人を前提とした環境は、認識系にとって緩過ぎる。
我らは機能冗長による安心の担保を図るつもりでRTLSを使うが、今回はロボットに備わったセンサのみで自己位置推定の精度がイケている事が検証できた。
自重による床の撓みで直進すらままならないチームもあり、さながら鳶職人の足回りと軽さが必要かも。


最後に皆そろってはいポーズ。しかし、ワークショップから姿を見せられないロボットも。


束の間の休息をおいしいワインで。
皆さんお疲れ様でした。


後は6月以降の本番に向けて、未完部分のfixとコーディングを進めるのみ。

細切れののタイムスロットの割り当てをくじ引きで決めます。
我がチームは 朝一番。朝日がまぶしい！


揺動URGは予定通りのデータを吐いている。


急勾配にも程があるでしょう。
まだ必用なパーツがついてないので無理矢理ですが、本番の上物があったら・・・。


ちなみに、今回は実装に必用なデータ取りや動作の検証が主なので、特に優劣を決める事は特になく。

ARGOS CHALLENGEの試走会がフランスのポーで始まりました。
隣はもうスペインといったロケーションからか、初日はTシャツ1枚で十分。

我がチームの新型は足回りだけでもという事で、急あつらえの頭を装備。
とはいえ非常停止やら遠隔停止等々強いられる事はかなり多く。




必用な装備を概ね備えた従来機によるバックアップ体制も万全。
各チームに割り当てられた時間は多くないので、いそいそと保安チェックを済ませ現場へGO。


足場にしか見えませんが、これでも立派な消防訓練の設備。
ここで実証実験をします。


わ～高い


juryの皆さんの厳しい目が・・・。


これから4日間で精度の良いポイントクラウドの収集・オドメトリエンジンの検証・画像処理・音響分析などなど、時差に負けないようめいっぱいやりますよ。

最近のOpenOCDはCMSIS-DAPを活性化してあり、LPC-LINK2をCMSIS-DAP化したものが使えるので、LPC82xもOpenOCDから触れるという事になる。
既存のlpc8xx.cfgはワークエリアの指定が小さいので、そこだけ変えたlpc82x.cfgを使ってほしい。

openocd -s ./tcl -f daemon.cfg -f interface/cmsis-dap.cfg -c "adapter_khz 1000" -f target/lpc82x.cfg

GCC Developer Liteに同梱されるFlash Writerはデーモン化させたOpenOCDとお話しできるので、Flash Write用にスクリプトさえ用意すればこちらも1クリックで書き込みできたりする。

init
adapter_khz 1000
reset init
flash erase_sector 0 0 31
flash write_image erase unlock ($PGENE) 0 bin
dump_image ($PGENETMP) 0x0 ($PGENESIZE)
#verify_image ($PGENE) 0 bin
reset run
exit

GCC Developer Liteでサポートされるのはもうすぐかな？

NXP LPC824のフラッシュメモリへの書き込みを行う場合、LPCXPressoのデバッガを介してLPC-Link 2で書き込むか、標準で内蔵されているブートローダを使用してシリアルポートから書き込む(ISP)方法がある。
前者は統合環境が必要、後者はUSARTの端子が決め打ちされいる、といった感じでどちらもお気楽感がない。

分身を沢山あつらえたいとなると、ライセンスやら操作手順やらが野暮ったい事も多い。そこで白羽の矢が立ったのがCooCoxのCoFlashである。

CoIDEは色々なデバイスに対応しているのとフリーの統合環境という事も合って結構使われている方も多いがと思うが、CoFlashもフリーかつシンプルな書き込みツールで対応するICEも結構多い。

今回はデフォルトではCoFlashがサポートしていないLPC824を、LPC-Link 2を使って書き込めるようにしてみた。その手法が開示されているのと、LPC11xxシリーズと互換性があるので、そのままソースを流用すれば結構さくっとイケる。

詳しくは修正したソースをここに置いておくのでそれを見てもらえればと思うが、違いはセクタサイズやページサイズ程度である。ついでにページ書き込みのルーチンの中で書き込み後にコンペアを行った上で応答を返しているので、ツール上でベリファイを指定しなくても良い筈。
同梱のファイルをCooFlashをインストールしたフォルダにt適宜コピーすればDeviceツリーのNXPにLPC822とLPC824が追加される。後はSWDからガシガシ書き込むだけである。

なお、LPC-Link 2にCMSIS-DAPのファームを書き込んだ物を使用する事。

新しもの好きの作者の割には、パブリック向けの更新が滞っている様です。
カスタムターゲット向けのパッケージはそこそこ更新されていますが、ツール類は特段変わった様子も無く枯れたままだったり。

そんな中、作者より更新の案内がありました。
ソースの編集は1ファイルに限定している事もあって有用性は無いと判断し、公には活性化されていないタグジャンプ機能を、今後のリリースでは使えるようにするらしく。

既にターゲットによってはサポートファイル類が肥大化しており、それらを使用する場合はソースやヘッダファイルを参照せざるを得ない状況です。
また、シングルソースであっても、長大であれば短期記憶をアテに自分のソースを移動するのは骨が折れますし、数日もすればおぼろげな記憶のレイアウトはアテにならなくなってくるでしょう。

Eclipseをはじめ、最近のIDEの類はプロジェクト中のファイルを解析して、編集作業をしやすくする機能が当然の様に備わっています。
GCC Developer Liteは単なるテキストエディタと称している割に、そこそこ中途半端に変な機能が備わってはいますが、広大なソースファイル類を手に取る様に見渡す事はできません。

これらから、タグジャンプ機能の公開が迫られていたという背景がありました。

今回の機能解放では、外部のコマンドを併用してソースファイル中の単語の関連性を簡易的に調べて、宣言されている場所を渡り歩く事ができる様になります。
タグファイルが生成されてさえいれば、カーソル位置の単語をタグファイルから検索させ、その単語を含むソースファイルの該当位置へジャンプ(タグジャンプ)させる事ができますし、ジャンプした履歴を逆に辿る事もできます。
背反事項として、設定によってはタグファイルのサイズがソースファイルのサイズとは関係なく大きくなる事がありますが、ハードディスクもSSD化が進み速度的に有利な環境が整いつつあるので、本ツールを活用されている方向けに活性化する事としました。

ちなみに、ゼロからプログラムを書き進める時よりも既存のソースファイルを読み進めるための機能なため、とりあえずは大きめのサイズになりがちのFDIII-HCやUD3のサンプルプログラムを読むには良いでしょう。

近々公開されるであろう更新版では、この機能が活性化していると思います。

NXPのMCUにはROM APIなる機能が備わっている物がある。内蔵ROM上にいろいろなルーチンが予め書き込まれているので、そのルーチンを使えばFLASHメモリ上にそれらの機能を別途作り込む必要が無いという事の様だ。

トラ技の付録だったLPC810の様に、FLASHの容量が少ないデバイスではこのROM APIの恩恵に与る事も多いはず。UART・I2C・SPI・ADCといったペリフェラルは、ROMに用意されたルーチンに任せる事でFLASHの容量を消費せずに利用できるという物。

特にROM APIの中でありがたいのが割り算で、ソースに「/」や「%」を使ったとたんに数キロバイトしかないFLASHの大半をライブラリが占めてしまうのを解消してくれる。
使い方はマニュアルに書いてあるが、何やら特定の環境を前提としている様でよく分からないので、今回はたぶん公知の情報でしょうがLPC82xを前提としてちょっとだけ簡単に使える方法を備忘録として書いておく。
概ねAPIの名称はマニュアルの記述を踏襲しつつ、まずはAPIへの入り口を作る。APIの呼び出しにいちいち変数なんぞ作って初期化して使うのは野暮ったいので直接アドレッシングで。

typedef struct { int quot; int rem; } idiv_return;
typedef struct { unsigned quot; unsigned rem; } uidiv_return;

typedef struct {
  int (*sidiv) (int numerator, int denominator);
  unsigned (*uidiv) (unsigned numerator, unsigned denominator);
  idiv_return (*sidivmod) (int numerator, int denominator);
  uidiv_return (*uidivmod) (unsigned numerator, unsigned denominator);
} TLPC_ROM_DIV_STRUCT;

typedef TLPC_ROM_DIV_STRUCT *pTLPC_ROM_DIV_STRUCT;

typedef struct {
  const uint32_t p_dev1;
  const uint32_t p_dev2;
  const uint32_t p_dev3;
  const uint32_t p_dev4;
  pTLPC_ROM_DIV_STRUCT pROMDiv;
  const uint32_t p_dev6;
  const uint32_t p_dev7;
  const uint32_t p_dev8;
} TROMAPIs;

#define LPCAPI      (*(TROMAPIs **)(0x1FFF1FF8UL))
#define LPC_DIV_API ((LPCAPI)->pROMDiv)

これらの宣言をしておけば後は使うだけ。
割り算をしたければ、

int ans, numerator, denominator;
ans = LPC_DIV_API->sidiv (numerator, denominator);
// ans = numerator / denominator;

余りが欲しければ、

int ans, numerator, denominator;
ans = LPC_DIV_API->sidivmod (numerator, denominator).rem;
// ans = numerator % denominator;

それすらも野暮ったかったら、gccであれば

int __aeabi_idiv (int numerator, int denominator) {
  return LPC_DIV_API->sidiv (numerator, denominator);
}

unsigned __aeabi_uidiv (unsigned numerator, unsigned denominator) {
  return LPC_DIV_API->uidiv (numerator, denominator);
}

idiv_return __aeabi_idivmod (int numerator, int denominator) {
   return LPC_DIV_API->sidivmod (numerator, denominator);
}

uidiv_return __aeabi_uidivmod (unsigned numerator, unsigned denominator) {
  return LPC_DIV_API->uidivmod (numerator, denominator);
}

としておけば、「/」やら「%」を使用するとリンクされる除算のライブラリ自体を置き換える素地となる。

割り算に限らずペリフェラルを扱うAPIもこの様なマクロを介して呼び出せるので、お気楽感が増すでしょう。