Closed JaredReabow closed 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 .
any updates to it?
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
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.
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 :)
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?)
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.
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?
He said apm 2 Arthur :)
Just checking. But I looked the schematics and both use an ATMEGA32U2 for the USB/Serial port, so it doesn't matter.
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.
@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 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.
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?
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.
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.
@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.
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!!).
User: http://www.diydrones.com/forum/topic/listForContributor?user=1kike9iu6i0al has offered to test the modifications in this issue.
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
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.
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
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
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
@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
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:
Adding those device IDs make it work. It seams 0x26ac is the PX4 board:
— Reply to this email directly or view it on GitHubhttps://github.com/arthurbenemann/droidplanner/issues/53#issuecomment-21885892 .
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
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.
Someone tested it on APM2.5, take a look here: https://github.com/arthurbenemann/droidplanner/pull/203#issuecomment-22020475
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 .
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.
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:
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
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
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?.
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.
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.
I just pushed version 0.12.0 with this modifications to Google Play as an alpha version.
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?
@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
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!!
@helibot They added it on this year Google IO.
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 .
@bradh79
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 .
@bradh79 You will need a WiFi link and a IPcamera. Or a standart analog FPV gear and a analog2digital video encoder.
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 .
@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.
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 .
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 .
@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
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?