たった19ドルの920MHz 3D Radio（互換品）で以前ポストしたものです。この3D Radio（互換品）は、Droid planner2との相性は抜群で、USBーUARTのブリッジICにはCP2102が利用されていています。アンドロイドのバージョンは4.1なのですが、仮想ポートの設定の為のReBuild不要どころか、root化さえ不要で、単純にDroid planner2を導入するだけで何の苦労もなく、APM2.5.5と繋がってしまいますが技適がないので、実戦導入出来ず、xBee pro S2Bの導入準備中です。そこで、皆様のご経験上、xBeeとアンドロイドのマイクロUSB端子を接続するためのブリッジでDroid plannerやTowerからの制御が可能であったUSBドングル又はブリッジをご紹介願えませんでしょうか？アンドロイドに利用できるUSB-UARTブリッジICはかなり限定されると思いますが、3DRadio互換品に利用されているのと同じCP210xでxBeeもブリッジしたほうが良いでしょうか？または、このUSBドングルではアンドロイドでは繋がらなかったという情報でも結構です。よろしくお願いします。
You need to be a member of diydrones to add comments!
CTS制御に踏み切ったのは、同じくWay Point を機体側APMからPC側のMission Plannerに読み込む際にエラーが発生することがあったためです。50か所のWayPointwoを設定して両方向で実験しましたが、CTS制御のマイコンプログラムのバッファリングのみで、エラーが発生しなくなっていますので皆様のいわれるとおりにCTS制御の効果はあると考えています。
Replies
JDC KK様
レスポンスありがとうございます。
CTS制御に踏み切ったのは、同じくWay Point を機体側APMからPC側のMission Plannerに読み込む際にエラーが発生することがあったためです。50か所のWayPointwoを設定して両方向で実験しましたが、CTS制御のマイコンプログラムのバッファリングのみで、エラーが発生しなくなっていますので皆様のいわれるとおりにCTS制御の効果はあると考えています。
単純なバッファリングをするのであれば、少なくとも500バイトくらいは要りそうです。
MavLink プロトコルを見極めててデータを捨てる処理をすれば、確かにATTINY 2313あたりでも処理できるかもしれません。
CTSがハイになるのはほとんどが機体側のxBeeですし、マイコンによるバッファリングで通信エラーは起きなくなっていますので。GPS信号とそれ以外の信号の衝突を避けるためにGPSの更新レートを下げればよいのかなとも思っています。
いくつかチャレンジしてみて、通信速度が向上すればご報告します。
楽しく拝見させていただいております。
当方 xbee-pro とMissionPlanner でやはり四苦八苦した覚えがあります。
38.4k で通常の飛行データはパソコンに取得できるのですが，AutoModeのデータをパソコンから送信したときに
通信が間に合わないことがありました。
1~2点の座標データならば問題ないが，4点以上の場所を指定するとだめでした。
APMのバージョンは 3.2.1を使用しています。(APMはこれが最終版です）
APMはバージョンアップが無いので安心して長年実用使用できそうです。
提案ですが，APMからのMavのデータを選別して急いで必要なものだけ送る方法はどうでしょうか？
0xFEから始まるデータで高度やGPSなどはたまに（2～3秒おき）送れば済むと考えたいます。
そうすると何が忙しくて，何がゆっくりで良いのか？悩む必要はありますけど。
2ポートのUARTを持ったCPUならば，メモリーが少ないものでも良いと思います。
当方 APMのTeleポートから 何点かのデータだけを抜き取って使用しています。
高度とGPS-HDOP，水平速度 のデータです。
Mavデータ はなかなか難解で，仕様書どうりになっていないような点も多々あります（当方が理解できないのか?）
が，試行錯誤で取り出しています。
MPでもAndroideでも，新規データが無いときはこれまでのデータを継続表示するので，あまり気にならないかと
考えます。
（飛行中は 人間がデータを見る機会のほうが少ない？）
Wifi経由での通信も何種類か試しました。速度は速くて申し分ないのですが，通信距離がどうしてもだめです。
（やっと 100m程度）Xbeeと違って，アンテナ系のゲインが稼げないのが 残念です。
また 楽しい投稿 お待ちしています。
APM2.5では、ArduCopterを最新版に更新してしまうと、テレメトリーできなくなってしまいます。
ですが、Arducopter 3.2.1-custom (Telemetory修正済)のHEXファイルがネット上で見当たらない様です。
私の手元にはありますが、今後APMでxBeeによるテレメトリーを挑戦される方は、自力でコンパイルする必要があるかもしれません。
どなたか、APM用のArducopter 3.2.1-custom (Telemetory修正済)の保存されているURLをご存じの方がいらっしゃればコメントお願いします。
バッファリングプログラムを試行錯誤している間に解ったのですが、
xBeeによるテレメトリー通信時にCTSがハイになりxBeeがデータを受け取れなくなる頻度が結構あります。
38.4kbpsの通信においても3秒に１回程度CTSがハイになります。
それに合わせて今回紹介したATMEGA8のバッファも400バイト程度埋まります。
ですが、CTSがローになるとATMEGA8内部のバッファは0バイトにまで戻ります。
残念ながら通信速度の改善はあまり体感できませんが、データロストによるエラーは発生しなくなりました。
以下の環境です。
APM 2.5
Arducopter 3.2.1-custom (Telemetory修正済)
GPSデータ更新レート defaultのまま
通信速度 38.4kbps
xBee Pro S2B (レンジ1.5km 国内技適品)
以上
超カメのコメントなのですが、
xBee によるテレメトリー時に通信データのロストを防ぐためのCTS制御バッファリングのマイコンプログラムのソースコードです。
試行錯誤の上、MavLinkプロトコルのデータ長を考慮しない単純なCTSフロー制御データバッファとなっています。
xBeeと電圧変換基板の間でUSART信号をCTSの状態に応じてバッファリングします。
ATMEGA-8用ですが、ATMEGA系のマイコンならわずかな修正でAtmel Studioで再コンパイルで利用できると思います。
このバッファリング用マイコンは、機体側と地上局側の両方のxBeeに必要です。
配線（機体側・地上局側共通）；
xBee用電圧変換基板のGround → ATMEGA8 8番Pin, 22番Pin (GND)
xBee用電圧変換基板のVCC(5V) → ATMEGA8 7番Pin(VCC), 20番Pin (AVCC)
xBee12番Pin(CTS) → ATMEGA8 23番PIN(PC0)
xBee用変換基盤のDINにつながっている基板上のパターン→ATMEGA8 2番PIN(RXD)
(注意：変換基板側からのxBeeのDINまでの基板上配線はパターンカットしておく)
ATMEGA8 3番PIN(TXD)→xBee 3番PIN(DIN)
ATMEGA8のクロックは内部発振で8MHz。
Mission Planner / Tower (Android)およびAPMのSerialのスピードはすべて38400bpsです。
Atmel Studio用プログラム
/*
* ATMEGA8_xBee_Buffer.c
*
* Created: 2017/01/03 10:28:33
* Author : うまく飛ばしたい
*/
#include<avr/io.h>
#include<avr/interrupt.h>
#include <string.h>
#define F_CPU 8000000UL
#include <util/delay.h>
#define sbi(BYTE,BIT) BYTE |=_BV(BIT) //BYTEの指定BITに1をセット
#define cbi(BYTE,BIT) BYTE &= ~_BV(BIT) //BYTEの指定BITをクリア
/**動作設定**/
#define FOSC 8000000 //8MHz
/**UART設定**/
#define BAUD 38400//bps
#define MYUBRR FOSC/16/(BAUD/2)-1 //UART分周率(倍速)
#define size_of_SRAM_Array 768
volatile unsigned char uc_SRAM_Array[size_of_SRAM_Array];
volatile int i_Num_Of_BYTE_in_SRAM;
//volatile int i_Counta_of_RSSI;
/*PORT設定 PD2はxBeeのCTSに接続 */
void port_init(void)
{
// DDRB = 0xFF;//sbi(DDRB,PB0);//PB0を出力に
// PORTB = 0xFF;
cbi(DDRC,PC0);//PC0を入力に
sbi(PORTC,PC0);//PC0をプルアップ
// cbi(DDRD,PD2);//PD2を入力に
// sbi(PORTD,PD2);//PD2をプルアップ
// cbi(DDRD,PD3);//PD3を入力に
// sbi(PORTD,PD3);//PD3をプルアップ
// sbi(GICR,INT1);//INT1を許可
// sbi(MCUCR, ISC11);//立ち下がりで割り込み
}
/*USART設定*/
void usart_init(unsigned int ubrr)
{
UBRRH = (unsigned char) (ubrr>>8); //ボーレート上位8bit
UBRRL = (unsigned char) ubrr; //ボーレート下位8bit
UCSRA = 0b00000010; //倍速
UCSRB = 0b10011000; //RXEN TXEN RXCIE 受信許可、送信許可 受信完了割り込み許可
UCSRC = 0b10000110; //非同期通信8N1
}
int main(void)
{
port_init();//PORT設定
usart_init(MYUBRR);//USART設定
i_Num_Of_BYTE_in_SRAM = 0;
// i_Counta_of_RSSI = 0;
sei();//全割り込み許可
for(;;)
{
if(bit_is_clear(PINC,PC0) ) //xBeeのCTSがLowならば送信
{
if(i_Num_Of_BYTE_in_SRAM > 0)
{
loop_until_bit_is_set(UCSRA,UDRE);//送信データレジスタ空きまで待機
UDR = uc_SRAM_Array[i_Num_Of_BYTE_in_SRAM-1];
i_Num_Of_BYTE_in_SRAM --;
}
// sbi(PORTB,PB7);
}
// else //xBeeのCTSがHigh
// {
// cbi(PORTB,PB7);//LED7を点灯
// }
/*
if(i_Num_Of_BYTE_in_SRAM == 0)
{
cbi(PORTB,PB0);
}
else
{
sbi(PORTB,PB0);
}
if(i_Num_Of_BYTE_in_SRAM >= 200)
{
cbi(PORTB,PB1);
}
else
{
sbi(PORTB,PB1);
}
if(i_Num_Of_BYTE_in_SRAM >= 400)
{
cbi(PORTB,PB2);
}
else
{
sbi(PORTB,PB2);
}
if(i_Num_Of_BYTE_in_SRAM >= 600)
{
cbi(PORTB,PB3);
}
else
{
sbi(PORTB,PB3);
}
*/
}
}
/**UART受信割り込み**/
ISR(USART_RXC_vect)
{
unsigned char ucRead;
while(bit_is_set(UCSRA,RXC))
{
if(bit_is_clear(UCSRA,FE))
{
if(i_Num_Of_BYTE_in_SRAM < size_of_SRAM_Array -10 )
{
i_Num_Of_BYTE_in_SRAM ++;
for (int i = i_Num_Of_BYTE_in_SRAM ; i > 0 ; i--)
{
uc_SRAM_Array[i] = uc_SRAM_Array[i-1];
}
uc_SRAM_Array[0] = UDR;
}
else
{
i_Num_Of_BYTE_in_SRAM = 1;
uc_SRAM_Array[0] = UDR;
}
}
else
{
i_Num_Of_BYTE_in_SRAM = 0;
ucRead = UDR;
}
}
}
/*
ISR (INT1_vect)
{
while(bit_is_clear(PIND,PD3))
{
cbi(PORTB,PB6);
i_Counta_of_RSSI++;
if(i_Counta_of_RSSI == 0)
{
cbi(PORTB,PB0);
}
else
if(i_Counta_of_RSSI >= 20)
{
cbi(PORTB,PB1);
}
if(i_Counta_of_RSSI >= 40)
{
cbi(PORTB,PB2);
}
if(i_Counta_of_RSSI >= 60)
{
cbi(PORTB,PB3);
}
}
i_Counta_of_RSSI=0;
sbi(PORTB,PB0);
sbi(PORTB,PB1);
sbi(PORTB,PB2);
sbi(PORTB,PB3);
sbi(PORTB,PB6);
}
*/
自己RES（中間報告）です。
以下の条件での接続をテストしました。
アンドロイド側
アンドロイド バージョン 4.1のマイクロUSBにUSBアダプタ経由でxBee Pro S2Bを接続
ドロイドプランナー２
USBドングル：２種類
・スイッチサイエンス XBee USB アダプター(リセットスイッチ付き) FT232RLが使用されています。
・Spark Fun XBeeエクスプローラUSB FT231XSが使用されています。
xBeeの設定は、前回ポストした、PCでの接続と基本的に同じです(http://diydrones.com/group/japan-arducopter-group/forum/topics/xbee...)
結果として、うまく行きません。
PCとのLinkでは安定している、xBeeのBaud Rateは38.4kbpsですが、そのままでは、Connectionできませんでした。
アンドロイド側のxBeeのBaud Ratenの設定を57.6kbpsに変更すると、Connectionは完了し、APMの情報がドロイドプランナー上はアップデートされるのですが、Droid Plannner のスピーキング機能が、頻繁にData Link LostとかRestored(Rest armed?)とか言ってくるのです。おそらく、MavLinkのエラー訂正処理が入っているのではないかと推測しております。
先日、JDC KK様より教えて頂きました38.4kbps以下にするか、CTSとバッファ処理回路の付加が必要なのだと思います。
なお、USBアダプタはスイッチサイエンス、Spark FunともにDroid Plannerともに認識はされていますのでFTIのUSB-UARTブリッジICであればDroid Plannerからは見えている様です。
アンドロイド側のUSBのLink Speedが57.6kbps固定の様なのですが、これが変更可能であるかを試して、それでも駄目なら、CTSとバッファ制御をAVRマイコンにさせる様にしたいと思います。
うまく行ったら、また報告させていただきます。
xBee単体でのDroidePlannerによる制御では、エラー訂正やデータ欠損が頻発することが考えられますが、先輩方のご経験では、実際の運用上では問題ないのでしょうか？
ご教授頂ければ幸に存じます。
また、AVRマイコンによるバッファリング回路については、再度ポストしたいと思います。
そのあと、わずかですか、xBee用バッファリング回路の作成が進みました。
920MHzにも共通する技術だと思います。
AVRでは大きめのSRAMサイズがある古いATMega8が家に転がっていたので、これを材料に用いました。
メガではありますが、プログラム領域もあるので、800kByte程度のバッファを確保できます。
ここで大きな問題に直面しました。
xBeeのCTSがbusyだからといって、ずっとバッファリングしていては、どんどん遅延が発生するのではないかという問題です。幸いにもMavLinkのプロトコルが公開されていて、１つの命令の長さが判るので、命令ごと間引く必要性があるのではないかと気づいた次第です。結局は、空間転送量に見合ったAPM側からの情報量の均衡が保てる様にするロジックが必要そうです。ここからはトライアンドエラーになるとは思うのですが、遅延が何マイクロ行以上になった場合は、データを命令セットごと切り捨てるべきかで非常に悩んでいます。
57.6kでの単純なバッファリングでは、依然ドロイドプランナーのスピーキング機能のData Link Lostを黙らせることができていません。
xBeeでのバッファリングのご経験のある先輩方のアドバイスをお願いします。
こんばんは。
去年書いたことなので今とはちょっと事情が違う箇所があるのですが、今も試しましたが使えますよ。
WindowsタブレットにMission Plannerを主に使っているので深いところまでは使っていないのですが問題ないと思います。
droidplannerについて
ここにも書いたように私の手持ちでは
auスマホ HTC HTL21(Android4.1.1) 動かない
auスマホ Sharp SHL24(Android4.2.2) 多分問題ない
Lenovo B6000-F(Android4.4.2) 多分問題ない
です。
スマホなのかタブレットなのか知りませんが知人にちょっと貸してもらうかして端末を疑ってみてはどうでしょう。
Tomi Mizya様
アンドロイドのバージョンによる違いの情報ありがとうございます。
アンドロイドのFTIドライバの通信速度を変更方法があるなら教えて頂けませんか？
-
1
-
2
of 2 Next