Announcement

Collapse
No announcement yet.

Wireless programming/debugging simplest way?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wireless programming/debugging simplest way?

    Is there a simpler way? I'd encourage someone to make the wireless connections seamless if possible.

    We've used the botbug (swerve robotics) service for the past two seasons, this worked nicely with the ZTE phones, (a second USB Network interface was also nice to keep internet connectivity simulatneously. The new G4 phones don't seem to work with this service, and the adb connection to the phone does not seem to be able to be done wireless and via USB simultaneously - thus there is a very regimented plug in, issue adb commands, unplug, issue more commands ritual. Yes, we've bundled this in a script and have different scripts for different phones....

    That being said, I still see very few teams that use wireless debugging. So the problematic usb/phone connection port just gets hammered with plug/unplug cycles of code deployment. There's probably a selective sample of teams here who can mostly handle the details of running a script etc etc, but this seems like an area where FIRST might put some effort into with great benefit. I imagine that they might be gearing toward the Rev Control Hub for next year, but there will still be a lot of legacy equipment, and saving students from abusing their phone's usb ports should be of great benefit.

    Of course we could be totally missing something, and there's an easier way? (onbot Java- but the team here is used to Android studio) So if there are easier ways to manage the wireless ADB connection, we'd love to hear about it. (not sure how/if any of this pertains to the Blocks/app inventor setup) TIA.

  • #2
    Originally posted by korimako View Post
    Is there a simpler way? I'd encourage someone to make the wireless connections seamless if possible.

    We've used the botbug (swerve robotics) service for the past two seasons, this worked nicely with the ZTE phones, (a second USB Network interface was also nice to keep internet connectivity simulatneously. The new G4 phones don't seem to work with this service, and the adb connection to the phone does not seem to be able to be done wireless and via USB simultaneously - thus there is a very regimented plug in, issue adb commands, unplug, issue more commands ritual. Yes, we've bundled this in a script and have different scripts for different phones....

    That being said, I still see very few teams that use wireless debugging. So the problematic usb/phone connection port just gets hammered with plug/unplug cycles of code deployment. There's probably a selective sample of teams here who can mostly handle the details of running a script etc etc, but this seems like an area where FIRST might put some effort into with great benefit. I imagine that they might be gearing toward the Rev Control Hub for next year, but there will still be a lot of legacy equipment, and saving students from abusing their phone's usb ports should be of great benefit.

    Of course we could be totally missing something, and there's an easier way? (onbot Java- but the team here is used to Android studio) So if there are easier ways to manage the wireless ADB connection, we'd love to hear about it. (not sure how/if any of this pertains to the Blocks/app inventor setup) TIA.
    While we completely agree that for some advanced programming the debugging routines in Android Studio might be a necessity. That said, we would STRONGLY recommend your team give Onbot a try. We were sceptical as well (and never got wireless ADB to work at all), but we were sold on Onbot from day one. Sooooo easy to make a quick change, click one button and go. Here's the link to an awesome video Philbot made to set it up: https://youtu.be/tRDSj2AZJuI
    Michael P Clark
    Founding Mentor, FTC 9958
    http://www.redfishrobotics.com
    "We're Hooked on FIRST"

    Comment


    • #3
      We have had experience using both Onbot and Wireless ADB and there are advantages to both. The reason we use wireless ADB over Onbot is you cannot push to github using Onbot. Even though it takes super long to download using wireless ADB, we think it is worth it. If you want to try out wireless ADB here are the steps.

      Open up Command prompt on the computer with the robot controller connected to the computer in USB Debugging mode
      Open the settings on the robot controller phone
      Click Wi-Fi settings
      Open the menu and click advanced settings
      Scroll all the way down and you should see IP Address followed by some numbers like 192.168.1.000 or something like that
      In command prompt type <b>adb tcpip 5555</b>
      Then type <b>adb connect 192.168.x.xxx</b> where the 192.168.x.xxx is the phone's IP address
      You should now be connected and to tell if you are you can uplug the phone type <b>adb devices</b> into command prompt and you should see the phone's IP address
      When you open android studio, it may disconnect your phones in which case you can just reconnect them using the previous steps.

      Hope this helped.

      Comment


      • #4
        Originally posted by korimako View Post
        Is there a simpler way? I'd encourage someone to make the wireless connections seamless if possible.

        We've used the botbug (swerve robotics) service for the past two seasons, this worked nicely with the ZTE phones, (a second USB Network interface was also nice to keep internet connectivity simulatneously. The new G4 phones don't seem to work with this service, and the adb connection to the phone does not seem to be able to be done wireless and via USB simultaneously - thus there is a very regimented plug in, issue adb commands, unplug, issue more commands ritual. Yes, we've bundled this in a script and have different scripts for different phones....

        That being said, I still see very few teams that use wireless debugging. So the problematic usb/phone connection port just gets hammered with plug/unplug cycles of code deployment. There's probably a selective sample of teams here who can mostly handle the details of running a script etc etc, but this seems like an area where FIRST might put some effort into with great benefit. I imagine that they might be gearing toward the Rev Control Hub for next year, but there will still be a lot of legacy equipment, and saving students from abusing their phone's usb ports should be of great benefit.

        Of course we could be totally missing something, and there's an easier way? (onbot Java- but the team here is used to Android studio) So if there are easier ways to manage the wireless ADB connection, we'd love to hear about it. (not sure how/if any of this pertains to the Blocks/app inventor setup) TIA.
        Hi korimako,

        I use wireless ADB when i need to do wireless debugging. On the G4 phones, the Motorola version of the Android OS does not allow you to have a connection to an infrastructure network (like your school or home wifi network) and a wifi direct connection (between the robot controller and the driver station).

        The Motorola G4 phones, however, will let your laptop connect to the WiFi direct network and that is a way for you to use wireless ADB. The idea is that you use your development laptop and configure its wireless adapter to connect to the Robot Controller's Wi-Fi direct network. This will allow you to use wireless adb, similar to what you did with the ZTE speed phones.

        You can look at the online wiki for tips on how to connect to the Robot Controller's wifi direct network:

        https://github.com/ftctechnh/ftc_app...Manage-Network

        In addition to wireless ADB, I like to use telemetry statements for wireless debugging, and also the RobotLog class to log statements in the logcat file (which can also be viewed in the Android Monitor of Android Studio if you have a wireless ADB connection).

        Tom

        Comment


        • #5
          I forgot to add something... if you only have a single wireless adapter on your development laptop, then when you connect to the Robot Controller's WiFi direct network, you won't have internet connectivity... you are only connected to the Robot Controller. If you want to have internet connectivity while you are also doing wireless ADB to your Motorola phone, you can consider buying a USB Wi-Fi adapter and having a second wireless network for your development laptop.

          I personally just jump back and forth between the Robot Controller's network and my work infrastructure network as I am debugging and coding on the Robot Controller.

          Comment


          • #6
            Originally posted by Tom Eng View Post

            The Motorola G4 phones, however, will let your laptop connect to the WiFi direct network and that is a way for you to use wireless ADB. The idea is that you use your development laptop and configure its wireless adapter to connect to the Robot Controller's Wi-Fi direct network. This will allow you to use wireless adb, similar to what you did with the ZTE speed phones.

            I personally just jump back and forth between the Robot Controller's network and my work infrastructure network as I am debugging and coding on the Robot Controller.

            So, we can run our zte script (this predated the Swerve Botbug service) and the G4 Play shows both connections in Android studio (wireless & via USB cable) but disconnecting the usb cable kills both connections. On the ZTE's the wifi adb connection would remain. We've always used the wi-fi direct route, usually use a second usb NIC.(have to dig those out and fiddle with the G4's yet). Right now we pause the script and disconnect the usb before making the adb connection. Our understanding is there is still a USB connection initally needed? If you jump back and forth, don't you have to unplug your phone from the robot controller and connect it to your desktop to establish the ADB connection again?


            And yes - this year the ADB wireless apk download seems to take WAY longer than years past - is the Controller app just that much larger?


            I was wondering how the OnBot Java fits in to the GitHub Scheme? do we develop on the phone and the end of the day push it from the phone to android studio and update that way? Have to investigate all this.



            Thanks for all the pointers, we can and have found ways to work with this, My real point is that I'd venture a (large?) majority of teams never worry about wireless connections, how many (dis)connection issues stem from the phone USB connection? And can this be made easier to help them out?

            Cheers, Rick

            Comment

            Working...
            X