search

DroidPlanner / Tower

Ground Control Station for Android Devices
https://play.google.com/store/apps/details?id=org.droidplanner.android
Other
622 stars 554 forks source link

Allow connection via USB to ardumega #53

Closed JaredReabow closed 11 years ago

JaredReabow commented 11 years ago

Not everyone has Mavlink but they don't want to lug a laptop to the field to setup the ardumega, so if it is possible, could a USB link be implemented to allow direct connection to the board?

arthurbenemann commented 11 years ago

That is a good idea, i just need to see if it will work on the apm2 (since it does not use a ftdi ic). On apm1 there will be no problem since usb is connected directly to a ft232r. Em 07/04/2013 10:51, "JaredReabow" notifications@github.com escreveu:

Not everyone has Mavlink but they don't want to lug a laptop to the field to setup the ardumega, so if it is possible, could a USB link be implemented to allow direct connection to the board?

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53 .

JaredReabow commented 11 years ago

any updates to it?

arthurbenemann commented 11 years ago

Not yet, I have been busy studying the last couple of days

2013/5/15 JaredReabow notifications@github.com

any updates to it?

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-17971751 .

Arthur Benemann

helibot commented 11 years ago

Hi Arthur and Jared I wanted to try connection via USB cable as well. I tried using Android App 'usbterminal' and found that if I connected at 115200 baud I could see the MAVLink data and press enter three times to get CLI. This worked using Arducopter sw v.2.8.1 APM2 connected via USB cable to NEC LT-L Android 4.0.3 tablet. (But interestingly when I connected to a Asus Slider tablet, I could see the MavLink data , but could not get to cli?)

So anyway in DroidPlanner I tried modifying BAUD_RATE = 57600; to BAUD_RATE = 115200; in USBConnection.Java and it worked OK. I could connect APM2 to NEC tablet via USB cable. Havent tried on Asus yet ... But it seems that if DroidPlanner includes a user option to allow switch b/n Baud rates then connecting by USB may work OK.

arthurbenemann commented 11 years ago

That is nice, I was worried that the D20xx library that handle the communication to the USB/Serial IC wouldn't recognize the IC on APM2 (which isn't a FTDI IC).

Adding the option will be very easy, I'll do that for the next release. Of course if you do it I can just merge your changes (and you can brag of helping in the development of DP :)

helibot commented 11 years ago

Would be happy to have a further look and see if I can mod the code myself - (although my Android skills are not particularly good !!). I will have a go and at least test the USB cable operation further as well. (BTW I just setup a new dev environment using the latest ADT bundle and found I needed to make a few project settings changes before DroidPlanner would compile. Do you want to know about these changes? If so what best way to get them to you?)

arthurbenemann commented 11 years ago

Please let me know of any changes you needed to do to get the code to compile. That way i can fix it and it will be easier for everyone.

arthurbenemann commented 11 years ago

I tried to connect DroidPlanner directly to an APM2.5 but it didn't recognized the device. Did you used an APM2.5 or a APM2?

JaredReabow commented 11 years ago

He said apm 2 Arthur :)

arthurbenemann commented 11 years ago

Just checking. But I looked the schematics and both use an ATMEGA32U2 for the USB/Serial port, so it doesn't matter.

helibot commented 11 years ago

Sorry Gents, I was wrong, I have a Apm1.0 NOT 2.0. Sorry for the confusion....

Please let me know of any changes you needed to do to get the code to compile. After installing the latest ADT bundle (which comes with Android 4.2.2 SDK) and found I couldn’t get the DroidPlanner projects to compile. I added Google APIs and 4.1.2 SDK and Google APIs 4.1.2. ) But still kept getting a build error on MavLink project. On the Problems Tab it listed Description = “The project cannot be built until build path errors are resolved” , Type =”Java problem” and Location = “ unknown”. I believe I fixed it by modifying the JavaBuildPath for Mavlink to require google-play-services-lib. And modifying JavaBuildPath for FlightDataActivity to require Mavlink and google-play-services-lib Projects.

arthurbenemann commented 11 years ago

@helibot No problem, that explains why it worked (APM1 has a FT232 onboard). If you mod the code to a add a preference for setting the baudrate I will merge it, but it will not work with APM2 or APM2.5.

To make it compatible with all devices some work on the serial/USB library will be needed. Currently I'm using the D2XX library from FTDI, that's why it is only compatible with theirs ICs.

arthurbenemann commented 11 years ago

@helibot No problem, that explains why it worked (APM1 has a FT232 onboard). If you mod the code to a add a preference for setting the baudrate I will merge it, but it will not work with APM2 or APM2.5.

To make it compatible with all devices some work on the serial/USB library will be needed. Currently I'm using the D2XX library from FTDI, that's why it is only compatible with theirs ICs.

helibot commented 11 years ago

Ok , I have modded the code to add a preference, but still need to test it with an APM and a few devices, then will let you know so you can merge it.

The D2XX library is closed source right, so need to use a different library? Do you know a suitable one? A quick google showed these https://code.google.com/p/usb-serial-for-android/ Slickdev also have a library ,but it costs $$ http://slickdevlabs.com/slick-usb-2-serial-library/ Would either of these work with ATMEGA32u2 USB?

arthurbenemann commented 11 years ago

Yes D2xx is close-source, but FTDI makes it so it should be very reliable with FTDI ICs. But that is also where it fails, since APM2 or newer doesn't use an FTDI IC.

I tried to use usb-serial-for-android some time ago, but I wasn't able to make it work reliable. Maybe now that the mavlink parser is better implemented it may work. If it works, it works with every board :).

Using the Slickdev isn't a option IMO, since it is a closed library that would only add a small functionality to the app. It's different than a closed-but-free library like D2xx , because it would be complicated to distribute the source to everyone.

Anyway just do a pull-request with your changes and I will integrate them. Having the option to select the baud rate is valuable, even if we just use the telemetry board / APM1.

helibot commented 11 years ago

Arthur, I sent you a pull request for support preference setting of 57600 and 115200. Should we mention in the settings dialogs that it will only work for APM1?

Understand your comments about other libraries. If I get some time I will read up about usb-serial-for-android some more.

arthurbenemann commented 11 years ago

@helibot - I merged the pull request. I think we don't need to put all that info there (space is limited in a android device), and the only ones that will use it will be power users.

I'll let the implementation of the new usb library up to you, because I'm short on time and there are some other issues with high priority's that I need to tackle. But feel free to ask anything.

helibot commented 11 years ago

Ok. Glad you got the Pull OK.

I will check out the other library soon. (I have a few other things on right now, but will look at it sometime soon!!).

arthurbenemann commented 11 years ago

User: http://www.diydrones.com/forum/topic/listForContributor?user=1kike9iu6i0al has offered to test the modifications in this issue.

helibot commented 11 years ago

Hi Arthur and Herve, Great, two things I remembered. 1) I didn't commit the additions to the DroidPlanner\res\xml\device_filter.xml file. I have just committed the file now. Without these changes other USB devices (like APM 2 and 2.5) may not get recognised and connected when you plug them in. 2) I used the default source for the usb-serial-for-android library, the default source causes adb log messages to be sent for each packet received and sent. This will be helpful for initial testing/debugging, but we probably want to disable the log messages once we confirm its all working OK. Its possible (but nit likely) that the extra messages may affect the performance of the USB to APM communications. I can build a new library whenever we need it. Cheers Helibot

arthurbenemann commented 11 years ago

Well done @helibot , I just tested your code and it seams to work well. I just added a couple of devices to the "device_filter.xml", and merged my modifications from master to keep the code updated. I opened a new branch in my repository with this modifications, and also a pull request #203. I'll keep testing the code to see if it's stable since this is the core of the app, and I don't want to upset the current 3000 users.

helibot commented 11 years ago

Hi Arthur, Great to hear its working for you. Did you test it with APM2/2.5?
I was hoping to borrow a 2.5 and an Arduino Uno over last weekend but it didn't happen, so I couldn't test with any other devices. I agree that you shouldn't put it on main for a while. Definitely needs some testing!!

I see you added definition for USB ID 0x26ac / 0x0010 . The usb-serial-for-android library also maintains a list of vendor IDs (so it knows which type of interface to load- list is in src/com/hoho/android/usbserial/driver/UsbId.java). So I think the new ID will need to be added to this list as well before this device ID will work. I can do that on Wednesday night and also remove the verbose logcat outputs.

BTW - Do you know if Mavlink collect any stats on lost or corrupted packets? If so it would be good to see if ftdi libraries and usb-serial-for-android have same (if any) loss rates?

Cheers Helibot

arthurbenemann commented 11 years ago

I did the test with a APM2.5, but I had to add some devices to the device_filter.

The Mavlink library doesn't collect any stats right now, but we could implement it.

2013/7/29 helibot notifications@github.com

Hi Arthur, Great to hear its working for you. Did you test it with APM2/2.5?

I was hoping to borrow a 2.5 and an Arduino Uno over last weekend but it didn't happen, so I couldn't test with any other devices. I agree that you shouldn't put it on main for a while. Definitely needs some testing!!

I see you added definition for USB ID 0x26ac / 0x0010 . The usb-serial-for-android library also maintains a list of vendor IDs (so it knows which type of interface to load- list is in src/com/hoho/android/usbserial/driver/UsbId.java). So I think the new ID will need to be added to this list as well before this device ID will work. I can do that on Wednesday night and also remove the verbose logcat outputs.

BTW - Do you know if Mavlink collect any stats on lost or corrupted packets? If so it would be good to see if ftdi libraries and usb-serial-for-android have same (if any) loss rates?

Cheers Helibot

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-21722089 .

Arthur Benemann

helibot commented 11 years ago

Hi Arthur,

I started to make new usbserialforandroid library. I was going to include new USB IDs you specified. Can you tell me what this one is 0x26ac / 0x0010: APM 2.5 device. This isn’t mentioned in official USB ID lists like http://www.linux-usb.org/usb.ids http://www.linux-usb.org/usb.ids. Do you want me to include it in the usbserialforandroid library?

Cheers

Helibot

arthurbenemann commented 11 years ago

@helibot I had some problems running with APM 2.5 so I took a peak at Andropilot, here: https://github.com/geeksville/arduleader/blob/7fa1f8f9164a9fa6fe6dfe556d5eed2848094c71/andropilot/src/main/res/xml/device_filter.xml

Adding those device IDs make it work. It seams 0x26ac is the PX4 board: https://github.com/geeksville/arduleader/blob/7fa1f8f9164a9fa6fe6dfe556d5eed2848094c71/andropilot/src/main/scala/com/geeksville/andropilot/service/AndroidSerial.scala#L204

bradh79 commented 11 years ago

Can someone release an update with usb drivers done On 01/08/2013 2:48 AM, "Arthur Benemann" notifications@github.com wrote:

@helibot https://github.com/helibot I had some problems running with APM 2.5 so I took a peak at Andropilot, here:

https://github.com/geeksville/arduleader/blob/7fa1f8f9164a9fa6fe6dfe556d5eed2848094c71/andropilot/src/main/res/xml/device_filter.xml

Adding those device IDs make it work. It seams 0x26ac is the PX4 board:

https://github.com/geeksville/arduleader/blob/7fa1f8f9164a9fa6fe6dfe556d5eed2848094c71/andropilot/src/main/scala/com/geeksville/andropilot/service/AndroidSerial.scala#L204

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-21885892 .

helibot commented 11 years ago

Hi Arthur, I created a new library with extra USB ID and reduced logging for send recv data packets. Seems to work well for APM1.0. Can you veryify it with APM2.0/2.5? Please see https://github.com/helibot/droidplanner/commit/cee1601cba6f776ac905883dd35f654f84b1986a

Will now look at MAVlink in a bit more detail and see if there is any easy way to measure performance/packetloss.

Cheers Helibot

arthurbenemann commented 11 years ago

I'll test it, and do a merge to masters. That's the only way we can get a good sample of people testing it, if there is a problem I can always revert it before doing another release.

arthurbenemann commented 11 years ago

Someone tested it on APM2.5, take a look here: https://github.com/arthurbenemann/droidplanner/pull/203#issuecomment-22020475

bradh79 commented 11 years ago

Thanks where can I get a cord that will plug into my s4 and the flight controller On 03/08/2013 2:06 AM, "Arthur Benemann" notifications@github.com wrote:

Someone tested it on APM2.5, take a look here: #203https://github.com/arthurbenemann/droidplanner/issues/203#issuecomment-22020475

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-22023073 .

helibot commented 11 years ago

Hi Arthur,

To help verify if the new library is working OK I added some code to Mavlink/Parser.java. It counts any CRC errors in received packets and keeps a count of any lost packets. It then dumps the counts out to ADB logcat. If you want to see the changes check out https://github.com/helibot/droidplanner/commit/b89c56c0ad63ae1bee8f7f959ed0782d87aef528

With these changes I then did some testing using the FTDI library and the USBSerialForAndroid library (which I will now call USFA library)

Here are the test results:

Normal testing - -Using either library with the quad in normal default operation using USB or 3DRadio link ,then no CRC or Missed packets are received. Good news!! -Using either library in RC override mode (at default rate of 50Hz) with 3DR Radio I could get a trickle of lost packets. But this seems to occur equally on both libraries.

Extreme Load testing- -Using USB with either library and ALL the stream rates set at 50 Hz we could successfully receive ~12000 packets per minutes with no errors! -Using 3DRadio with USFA library and ALL the stream rates at 50 Hz then we could successfully receive ~4800 packets per minutes with no errors! -Using 3DRadio with FTDI library and ALL the stream rates upto 50 Hz then we could receive ~5200 packets per minutes BUT with a slow but constant loss of packets (~90 in 1 minute).

So from these test results I conclude that the ‘USB Serial for Android’ library is working at least as well, and probably better than the FTDI library.

NOTES – -All above tests were done with Quad armed and motors running at low-mid speed (no blades though!). -All above test were done with APM1.0 Arducopter 2.8.1 code and MissionPlanner basecode of v092. -As expected when using the 3DRadio link and Quad is a long way away from android tablet (or the Radio aerials are covered in foil/shielding cloth), then I can see that missed packets are quite common. But this is expected, (in fact perfectly normal) and the MAVLink parser just silently ignores the errors !!

Cheers Helibot

P.S. I think it would be useful to be able to display the MAVlink CRC/Lost packet stats on the HUD. I considered doing this as well, but wasn't sure the best/correct way to pass the data from the Mavlink parser code upto the HUD Widget code. The other HUD data gets passed through as MAVlink messages, but this data doesn't arrive as a MavLink message. So would it be OK to make a fake message? or is there a better way? Let me know if you have any thoughts.

arthurbenemann commented 11 years ago

Nice work Helibot!

After this great analysis I don't see why not merge it to the current master code. Just a few comments:

As you stated there is a problem for passing the mavlink status data to the main app, since the MAVlink connection/parser runs in a service (not in the main app thread). He have two ways to do this:

arthurbenemann commented 11 years ago

I did some re-factoring in your code, ad merged master into it so it's updated. Here are my commits: https://github.com/arthurbenemann/droidplanner/compare/USB_serial

helibot commented 11 years ago

Hi Arthur, I agree it should be OK to move the new library onto master. I think testing shows it should be good to go!

I reviewed your re-factoring - looks great (I haven't run it though). Only one comment - the log.d in newPacket() should be at the end of the function not the start - as we want to log the variables we just updated. Also wonder if the Log.d command should be commented out by default - as it creates quite a stream of messages in logcat?. Or Maybe it can be turned on only if MAVLink Logging is enabled in the user preferences?

Agree that errors at 57600 are expected and OK.

Agree that something simple for user would be good, but not sure what is best to show. Some users may like to see an running average of error rate , where others may want a warning every time there is a packet loss or bunch of packets lost?. Will have a look at MP and see what else I can think of.

Agree that either "Create a new MAVLink message just for Radio stats" or "a serializable object" will work. I also just noticed that there is already a MAVLink message for 'radio' status (See in ardupilotmega.xml). I wonder if we could extend/reuse this to include our new stats?

One big problem is define how often we want to send the MAVLinkStat

I don't think the update rate has to be very fast, the backend will accumulate stats and we can send them to the UI at a default (or configurable) Hz rate - maybe once every 2 secs is enough?.

arthurbenemann commented 11 years ago

the log.d in newPacket() should be at the end of the function not the start

I did just a refactoring, so I try to not alter the code behavior.

Also wonder if the Log.d command should be commented out by default - as it creates quite a stream of messages in logcat?. Or Maybe it can be turned on only if MAVLink Logging is enabled in the user preferences?

It can be commented by default, if we have problem is just a matter of uncommenting. Even between the developers this has little use, but of course it's indispensable when working with the MAVLink connection code :)

Agree that something simple for user would be good, but not sure what is best to show. Some users may like to see an running average of error rate , where others may want a warning every time there is a packet loss or bunch of packets lost?. Will have a look at MP and see what else I can think of.

Yes, I think it's best to just take a look on how they did it on Mission planner. Probably a running average of the last X number of packets error ratio, with can be updated within the MAVLinkStats object.

Agree that either "Create a new MAVLink message just for Radio stats" or "a serializable object" will work.

I implemented the "serializable object" option, take a look on this commit: https://github.com/arthurbenemann/droidplanner/commit/a497e11ce228cb8f475e30716142db62fa481c95 .

I also just noticed that there is already a MAVLink message for 'radio' status (See in ardupilotmega.xml). I wonder if we could extend/reuse this to include our new stats?

I don't this we should use this message, at my understanding it is generadet by the SiK firmware on the telemetry module and it gives info on the radio stats. Maybe it is another good source of info, because the lost packets will probably be good until it drops suddenly. The radio RSSI will drop more linearly.

One big problem is define how often we want to send the MAVLinkStat. I don't think the update rate has to be very fast, the backend will accumulate stats and we can send them to the UI at a default (or configurable) Hz rate - maybe once every 2 secs is enough?.

Thinking about it the code I added in https://github.com/arthurbenemann/droidplanner/commit/a497e11ce228cb8f475e30716142db62fa481c95 will probably not take too much processor time, so we can keep it updating at every new message. What takes a lot of processing is the update of the HUD. So maybe instead of forcing the update with every new update in the stats (like it's done for a Attitude message for instance) we can rely in the fact that other messages will be updating the HUD.

arthurbenemann commented 11 years ago

The pull #203 its closed, and so it's this one. Great job!

@helibot It's better if we can continue our discussion on the MAVlinkStats on issue #41.

arthurbenemann commented 11 years ago

I just pushed version 0.12.0 with this modifications to Google Play as an alpha version.

helibot commented 11 years ago

Hi Arthur, I can only see ver 0.11.4 on play store? Does it take awhile to be approved and released? Or should it be there by now?

arthurbenemann commented 11 years ago

@helibot Version 0.12.0b is on google play as a alpha version. To get it you need to join the Alpha testers community here: https://plus.google.com/u/0/communities/103503332685575912934 And also you have to sign in here too: https://play.google.com/apps/testing/com.droidplanner/join

helibot commented 11 years ago

Cools, I signed uyp and have got it OK now... This is great - I didnt even know you can do 'beta' releases via the play store!!

arthurbenemann commented 11 years ago

@helibot They added it on this year Google IO.

bradh79 commented 11 years ago

If I buy that sender receiver thing from 3dr can I use my tablet or phone for telemetry with osd? Or can I just program the board with no direct video feed On 08/08/2013 5:31 PM, "helibot" notifications@github.com wrote:

Cools, I signed uyp and have got it OK now... This is great - I didnt even know you can do 'beta' releases via the play store!!

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-22312406 .

arthurbenemann commented 11 years ago

@bradh79

bradh79 commented 11 years ago

Like a camera and tx rx for video but wouldn't it need to be able to plug into the phone or maybe over Wifi or Bluetooth On 08/08/2013 5:39 PM, "Arthur Benemann" notifications@github.com wrote:

@bradh79 https://github.com/bradh79

  • You can program the board using just a usb cable if you download the alpha version.
  • With a telemetry module you can program on flight, and have a lot of information about the flight (like Mission Planner).
  • FPV isn't yet implemented in the app yet (but we have something being developed), but you will probably need some dedicated hardware

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-22312791 .

arthurbenemann commented 11 years ago

@bradh79 You will need a WiFi link and a IPcamera. Or a standart analog FPV gear and a analog2digital video encoder.

bradh79 commented 11 years ago

So Wifi hotspot on s4 with advert iconia a500 should work On 08/08/2013 5:44 PM, "Arthur Benemann" notifications@github.com wrote:

@bradh79 https://github.com/bradh79 You will need a WiFi link and a IPcamera. Or a standart analog FPV gear and a analog2digital video encoder.

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-22312990 .

arthurbenemann commented 11 years ago

@bradh79 If you find a way to stream the data from the camera via wifi. Also the range would be very limited because you are using a adhoc network.

bradh79 commented 11 years ago

Finding a 12v Wifi router may be a challenge though On 08/08/2013 5:53 PM, "Arthur Benemann" notifications@github.com wrote:

@bradh79 https://github.com/bradh79 If you find a way to stream the data from the camera via wifi. Also the range would be very limited because you are using a adhoc network.

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-22313403 .

bradh79 commented 11 years ago

THIS WOULD WORK NICELY HUH http://cgi1.ebay.com.au/ws/eBayISAPI.dll?MakeTrack&_trksid=p2047675.l1360&rt=nc&item=281123998815&pt=AU_Home_Personal_Security&sourcePage=4340&ssPageName=VIP:watchlink:top:en&SubmitAction.AddToListVI=x&wt=1d3edf1186a3711c45c9d53cce6e3e24&tagId=-99&etn=Watch%20list

On Thu, Aug 8, 2013 at 5:55 PM, brad hazeldine bradhazeldine@gmail.comwrote:

Finding a 12v Wifi router may be a challenge though On 08/08/2013 5:53 PM, "Arthur Benemann" notifications@github.com wrote:

@bradh79 https://github.com/bradh79 If you find a way to stream the data from the camera via wifi. Also the range would be very limited because you are using a adhoc network.

— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-22313403 .

arthurbenemann commented 11 years ago

@bradh79 I have a similar camera, but when I was developing the FPV overlay I got stuck because they use MJPEG video compression. To do this we need something like H264