RoboDS First Test

[raystubbs]

Just ran first test of RoboDS (2015 Android Driverstation), seems to work pretty well. Buttons and joysticks work. The app still needs some work, but if I can find some free time I should have it finished in a week or so.

[Whippet]

Would you like some volunteers to beta test before the official release?

[raystubbs]

Would you like some volunteers to beta test before the official release?

Beta testers would be great. If anyone is interested PM me your emails and I'll send you an APK when the app is ready (maybe a few days, maybe a week). Thanks.

[raystubbs]

Here is a brief description of my app, and a prompt for some suggestions. Currently the app supports a 'drag n' drop' interface builder with 'Basic Button' and 'Basic Joystick' components. The app was designed so that new widgets of each category (joystick, button, slider, switch, throttle, etc.) can be easily added, so by the time the app is finished I hope to have a collection of widgets in different styles, and to allow users to import their own. The app's action bar contains a voltage indicator, connection indicator, enable button, mode switch, and a menu with settings and layout editing options. When a new widget is added to the layout a dialog comes up asking for the widget settings (joystick number, axis number, size, etc.). I plan to add support for multiple layouts that can be quickly switched out, but that'll have to wait until after the first release. Also in updated versions I'll add support for video and hardware joysticks. Video streaming is NOT currently supported in the app.
I also plan to add indicators to the widget collection, these'll include gauges, LEDs, and a few others. But to use these components the robot will have to include some RoboDS specific code, I don't want to use Smart Dashboard code because I want it to be a little smaller and lighter then the full Smart Dashboard implementation.

So here is a prompt:
I prefer to use RoboDS in landscape mode since I have a tablet. I do NOT want the app to change orientation with the sensor. So does anyone want an option to set the orientation of layouts to portrait? Is it easier to use a phone in portrait?

Any other suggested features?

The source code will be put up on Github after the first APK release, so if you'd like to branch it and add your own features feel free to do so.

[pribusin]

That sounds awesome - can't wait to test it out. Nice Job!!!

[nathannfm]

This would be for driving at home, not connecting to the field, right?

[raystubbs]

This would be for driving at home, not connecting to the field, right?

Definitely would not be legal for competition.

[Ben Wolsieffer]

I also plan to add indicators to the widget collection, these'll include gauges, LEDs, and a few others. But to use these components the robot will have to include some RoboDS specific code, I don't want to use Smart Dashboard code because I want it to be a little smaller and lighter then the full Smart Dashboard implementation.


In my opinion, I would rather have a bigger app that used NetworkTables (which I don't think is that big, anyway). I would likely use your app out of convenience at events where I did not want to lug around our full driver station. I don't think I would take the time to maintain code (even if it was useful), that wouldn't be used that often and also wouldn't be able to communicate with the normal DS. Also, by using NetworkTables, you would be working with a thoroughly debugged and reliable protocol. Otherwise, I think its a good idea to have custom indicators and widgets.

[cgmv123]

Definitely would not be legal for competition.
Unless the rules change.

[raystubbs]

In my opinion, I would rather have a bigger app that used NetworkTables (which I don't think is that big, anyway). I would likely use your app out of convenience at events where I did not want to lug around our full driver station. I don't think I would take the time to maintain code (even if it was useful), that wouldn't be used that often and also wouldn't be able to communicate with the normal DS. Also, by using NetworkTables, you would be working with a thoroughly debugged and reliable protocol. Otherwise, I think its a good idea to have custom indicators and widgets.

You'r right, it would be convenient to use network tables; but unfortunately I don't have much, or any, knowledge on the subject and I'm graduating this year (May), so I don't have much time to put into researching and implementing the feature. If anyone else has the knowledge to implement this feature I'm sure it would be appreciated. I'm a young, inexpirienced, and somewhat unskilled programmer; so please don't blame me for not wanting to "bite off more than I can chew." Thanks for the comment; if I find the time, and no one else is willing, I'll probably add full Smart Dashboard compatibility eventually.

[Aero]

You'r right, it would be convenient to use network tables; but unfortunately I don't have much, or any, knowledge on the subject...

NetworkTables are super easy! http://wpilib.screenstepslive.com/s/3120/m/7912/l/80205-writing-a-simple-networktables-program-in-c-and-java-with-a-java-client-pc-side

[raystubbs]

NetworkTables are super easy! http://wpilib.screenstepslive.com/s/3120/m/7912/l/80205-writing-a-simple-networktables-program-in-c-and-java-with-a-java-client-pc-side

Easy to use the library, but how easy to write it?

[raystubbs]

I have the app working good with a static IP, but when I try to use DHCP with InetAdress.getForName("roborio-2657.local") I get an UnknownHostException. If any of you Android developers knows what the problem is please help.

I used the same code in a desktop Java app and it worked perfectly.

The INTERNET permission is declared in my manifest.

[raystubbs]

Also I'd like to include a moderate collection of widgets in the app, so if anyone wants widgets to match their teams you can send me some graphics or post them as attachements. The graphics should be PNGs with the following elements:

Joysticks: inner graphic, outer graphic, (optional) pressed inner graphic, (optional) pressed outer graphic. All graphics should be approximately square or circle shaped.

Sliders: Same as joysticks, except these should NOT be square or circular. They should be longer than they are wide.

Throttles: Same as sliders.

Buttons: Pressed and depressed graphics. Graphics should not include text since text will be dynamically added when a button is created.

Other: Give me a description of what you want.

Displays: Not yet supported.

[fsilberberg]

I have the app working good with a static IP, but when I try to use DHCP with InetAdress.getForName("roborio-2657.local") I get an UnknownHostException. If any of you Android developers knows what the problem is please help.

I used the same code in a desktop Java app and it worked perfectly.

The INTERNET permission is declared in my manifest.
I'm going to guess that InetAddress doesn't look at mdns on Android, so you'll have to take a look at this: http://developer.android.com/training/connect-devices-wirelessly/nsd.html. If you've installed the NI update on Windows, it sets up an mdns responder. You need to look up by mdns as well.

Edit: taking a second look at that article, it doesn't appear to talk about mdns. Android does not appear to have an mdns responder, so you probably won't be able to get dynamic ips working.

[Ben Wolsieffer]

It seems like NSD does support mDNS. See here: http://www.dodgycoder.net/2015/02/setting-up-bonjourzeroconfmdnsnsd.html?m=1

NSD is only available in API 16 and above, but there also seems to be a library called jmDNS that might work.

[raystubbs]

It seems like NSD does support mDNS. See here: http://www.dodgycoder.net/2015/02/setting-up-bonjourzeroconfmdnsnsd.html?m=1

NSD is only available in API 16 and above, but there also seems to be a library called jmDNS that might work.

Thanks, I'll look that up.

[raystubbs]

Has anyone verified that the app works, if so please post what device you have verified.

[Ben Wolsieffer]

Has anyone verified that the app works, if so please post what device you have verified.

You released the app?

[raystubbs]

You released the app?

I sent the apk to those who wanted to test it, but I haven't heard back from them so I don't know if I should release it or not.

[Ben Wolsieffer]

I sent the apk to those who wanted to test it, but I haven't heard back from them so I don't know if I should release it or not.

I thought I sent you a pm saying that I would be willing to test it, but I just looked and I guess it never got sent. I'm still willing to test it, though, if you want.

[raystubbs]

Just a reminder, I don't know if any of you have artists on your team, but if you do I can put your custom artwork into RoboDS widgets. If you want me to integrate your art just post it here or email it to me.

[raystubbs]

I know that other teams are working on other DS projects, if anyone needs the protocol let me know.

[Whippet]

Team 4301 has some beta test results:

Motorola Moto G (2nd Gen):
-Functional
-Occasional app crash related to adding joysticks. We haven't been able to reliably reproduce it. It just happens sometimes, and not very often.

Samsung Galaxy S5 and S6:
-Functional with no issues.

iPhone 4s, 5, 5c, 5s, 6+:
-Does not install
-Better programming training implemented for mechanical students. :D

[raystubbs]

The app is only for Android, it is not expected to work on any apple devices. Thanks for the test results.

[Mschmeh144]

Did a few runs with the app, mainly to test different functions of our (yet to be completed, work in progress) testbed. Only tested in tank drive configuration with one cim per side of the robot, having some glitchy comms with the watchdog triggering and going ballistic making the robot spaz, but that is not the apps fault. This happens when the frc driver station is active while the robods app is also connected to the roborio.if at all possible, support for a Usb external joystick would be great, as I have a tablet with a USB port. Also, I would love to see a dedicated e-stop button or a function that disables the robot if the connection drops. Other than that, I think the app is great.

[raystubbs]

Did a few runs with the app, mainly to test different functions of our (yet to be completed, work in progress) testbed. Only tested in tank drive configuration with one cim per side of the robot, having some glitchy comms with the watchdog triggering and going ballistic making the robot spaz, but that is not the apps fault. This happens when the frc driver station is active while the robods app is also connected to the roborio.if at all possible, support for a Usb external joystick would be great, as I have a tablet with a USB port. Also, I would love to see a dedicated e-stop button or a function that disables the robot if the connection drops. Other than that, I think the app is great.

Support for external joysticks is coming. Now that you guys have confirmed that the app actually works on other devices, I can start working on it again. Thanks.

[Whippet]

The app is only for Android, it is not expected to work on any apple devices. Thanks for the test results.

That was the point, we needed to implement better programming training for our mechanical members so they would know that. :D

[raystubbs]

That was the point, we needed to implement better programming training for our mechanical members so they would know that. :D

Oh, OK, I thought you were serious. Sorry.

[raystubbs]

I'm graduating so after today I will no longer have access to a RoboRio, so I wont be able to test the app anymore. I'm gonna clean up my code a little and try to add some features, which will not be tested, then I'll put the code up on github if anyone wants to pick this project up. Sorry I was unable to finish it, and I'll keep trying to add features, but everything I do from here on out will be untested so if anyone wants to test or develop, I'll post a link to the github repo in a few days.

[Ben Wolsieffer]

I installed the app on my Galaxy S4 running 5.1.1, and tried to control our robot, but I ran into a few problems.

Here is a list of the problems I could find, in rough order of severity:

IP address setting does not save when changed. I'm not sure if the IP address is actually being changed, but when you open the settings dialog, it is still set to the default and I was unable to connect to our robot.
The same thing happens with the portrait/landscape setting, therefore I cannot create a portrait layout.
Joysticks seem to be in editing mode when the app is started with an existing layout. They turn green when touched instead of allowing control. Workaround: enter and leave editing mode.
When editing fields in the joystick and button creation dialogs, the first digit of each number field is not shown in the editing popup, and the none of the characters of the text fields show up. Interestingly, backspace will delete the these characters even if they are not shown.
The bottom of the joystick creation dialog is cut off in the landscape orientation. Could be fixed by making the dialog scrollable.
Pressing and holding on a joystick while driving causes the phone to vibrate.
The bottom two editing drawers are cut off somewhat in landscape.
It might be a good idea to allow only one drawer on the editing screen to be open at a time.
Loading and saving multiple layout doesn't seem to work; there is no way to create a new layout. I'm not sure if this just hasn't been implemented yet.
The joystick creation dialog should probably be initialized with sensible defaults.
"Comming" is misspelled in the bottom two drawers of the editor.
"Partrait" is misspelled in the layout settings.


I can upload some screenshots if you want. I hope this is helpful.

[raystubbs]

Wow, that sounds pretty bad. I have already listed some of these bugs, like portrait mode not working and only one layout. But I haven't heard o fthe others yet. Some screenshots would be extremely helpful and you android device also. Sorry for the UI mistakes, I'm guessing you are using a phone, I only have s 7" tablet to test on.

[raystubbs]

IP address setting does not save when changed. I'm not sure if the IP address is actually being changed, but when you open the settings dialog, it is still set to the default and I was unable to connect to our robot.


This is something I can work on. I never tested if the IP saved or not because the default IP is my robot's IP. I just tested the app on my device and found that it does not save, so I'll have that fixed in a few minuts, but my not have the time or internet access to upload it for a while, 'cause I'm going home to Mexico for a week.

[raystubbs]

Joysticks seem to be in editing mode when the app is started with an existing layout. They turn green when touched instead of allowing control. Workaround: enter and leave editing mode.


Does this happen every time you start the app? If not can it be reproduced? I used an android feature to switch back from edit mode, but this feature is only available in higher APIs, is your android device version 4.1 or higher?

[Ben Wolsieffer]

Sorry if I sounded overly negative in my last response. I'm just trying to suggest ways to improve the app.

My phone is a Samsung Galaxy S4 running Android 5.1.1, the absolute latest version, so it definitely has every API you use.

The editing bug occurs every time the app is cold started (ie. it has been deleted from the recent apps list), but not when the app is minimized/backgrounded and then opened again. When the app is minimized and then opened again, the joysticks start working as intended.

I attached screenshots of some of the bugs:

drawer_cut_off.png: Shows the bottom editor drawer being cut off by the bottom of the screen.
editing_bug.png: Shows how the joystick can be selected and turn green when not in editing mode.
field_editor.png: On phones (I'm not sure if this happens on tablets), an editor pops up when a field in the joystick/button creation dialogs is selected. The field actually contains "-1", but the editor does not show the "-", so it appears as "1"
joystick_dialog_cut_off.png: Shows how the last few fields in the joystick editing dialog are cut off by the bottom of the screen. It is still possible to edit them though, by pressing next in the editor.


If you release the code, I'll take a look and it and see if I can help with some of the bugs.

[raystubbs]

Sorry if I sounded overly negative in my last response. I'm just trying to suggest ways to improve the app.

My phone is a Samsung Galaxy S4 running Android 5.1.1, the absolute latest version, so it definitely has every API you use.

The editing bug occurs every time the app is cold started (ie. it has been deleted from the recent apps list), but not when the app is minimized/backgrounded and then opened again. When the app is minimized and then opened again, the joysticks start working as intended.

I attached screenshots of some of the bugs:

drawer_cut_off.png: Shows the bottom editor drawer being cut off by the bottom of the screen.
editing_bug.png: Shows how the joystick can be selected and turn green when not in editing mode.
field_editor.png: On phones (I'm not sure if this happens on tablets), an editor pops up when a field in the joystick/button creation dialogs is selected. The field actually contains "-1", but the editor does not show the "-", so it appears as "1"
joystick_dialog_cut_off.png: Shows how the last few fields in the joystick editing dialog are cut off by the bottom of the screen. It is still possible to edit them though, by pressing next in the editor.


If you release the code, I'll take a look and it and see if I can help with some of the bugs.

Thanks a lot. You didn't sound overly negative, I was expecting to have some problems with smaller screens. Your feedback really helps. I've now fixed the IP and orientation settings. The problem is that I cannot reproduce your editing bug on my device, so that may take a bit longer to fix. I would love to share the code and get some help, but unfortunately it is extremely ugly. I was in a hurry when writing it so I got really messy. I don't think you want to go mucking through it. Thanks again for the info, it will really help.

[Ben Wolsieffer]

I would love to share the code and get some help, but unfortunately it is extremely ugly. I was in a hurry when writing it so I got really messy. I don't think you want to go mucking through it. Thanks again for the info, it will really help.

Even if the code is ugly, I would really appreciate it if you released it. Especially if you are not going to have much time to work on the app, I would like to get it working, and it would help a lot to be able to work on it myself.

[raystubbs]

Even if the code is ugly, I would really appreciate it if you released it. Especially if you are not going to have much time to work on the app, I would like to get it working, and it would help a lot to be able to work on it myself.

Sorry for the lack of response, I've been in Mexico. I'll put the code on github as soon as possible. Just a warning, the code is quite a mess, but if you would pick up the project and finish it I would appreciate it. I have tried to clean up the most important classes so if nothing else the rest could be completely rewritten.

[raystubbs]

The repo is here https://github.com/raystubbs/RobotDS, I've made some changes after my last test so the app may not work at all, please test the binary before playing with the code to make sure I didn't break anything . The binary is located here https://github.com/raystubbs/RobotDS/blob/master/app/app-release.apk.

[Ben Wolsieffer]

Thanks!

[Ben Wolsieffer]

I forked the project (https://github.com/RobotsByTheC/RoboDS) and starting working on fixing some of the bugs. The first major change was to create a .gitignore file and remove all the autogenerated code from the repository. I also upgraded all the plugins, tools and targetSdkVersion to the latest versions.

As far as the code itself, you made it sound like it was much more messy than it is. :)

So far I have fixed:

Negative signs not shown in joystick editor
Make joystick creation dialog scrollable
Sensible defaults (I think*) for joystick creation
Joystick vibration on long press (sort of)
Misspellings


*Are the joystick/axis indices are 0 or 1 based?

Also, I should mention that the bug fixes have not been pushed to the repository yet, as I am still working on them.

[raystubbs]

I forked the project (https://github.com/RobotsByTheC/RoboDS) and starting working on fixing some of the bugs. The first major change was to create a .gitignore file and remove all the autogenerated code from the repository. I also upgraded all the plugins, tools and targetSdkVersion to the latest versions.

As far as the code itself, you made it sound like it was much more messy than it is. :)

So far I have fixed:

Negative signs not shown in joystick editor
Make joystick creation dialog scrollable
Sensible defaults (I think*) for joystick creation
Joystick vibration on long press (sort of)
Misspellings


*Are the joystick/axis indices are 0 or 1 based?

Also, I should mention that the bug fixes have not been pushed to the repository yet, as I am still working on them.

Buttons and axis' are 0+. Thanks for the work you have done, sounds great. One other thing you could do if you'd like is change the joysticks and buttons to extend AxisControl and ButtonControl, where AxisControl has .getAxisCount() and .getAxisArray() and ButtonControl has .getButtonCount() and .getButtonArray(). If the PacketFactory class' register method's were then changed to registerAxisControl() and registerButtonControl() it would be much easier to create new controls such as slider, throttles, etc. since they would just have to extend AxisControl or ButtonControl.

I was planning on changing this, but don't want to mess with it since I can't test it and might just break everything. I know you have other things to work on, I just thought I should share my plan.

[Ben Wolsieffer]

I just pushed all the work I have done so far to the GitHub repo. Most of the changes have been internal, so the app doesn't have many new features yet.

The biggest visible change is that I removed the drawers for creating controls and replaced them with a floating action button menu. The two main reasons I did this is because I was having trouble getting the drawers to work with RelativeLayout and I wanted something that fit better with Android. I realize that it won't work when there are more types of controls, but I am working on an another design for when that happens.

Here is a list of the bigger changes I made to the internals of the app:

Use RelativeLayout instead of AbsoluteLayout, because it is deprecated
Add support for saving multiple layout files and renaming layouts
Move all I/O code off the UI thread, just because it is correct, not because it improves performance
Create a new property system based on HashMap for saving layouts
Convert some strings to resources


I have not touched the communication code at all, but I will try to test it this week and fix any problems I come across.

I attached the latest build of the app (not signed or anything), in case you want to test it. I tried to test the UI as much as I could, but I probably missed some bugs.

From now on, I will try to make smaller commits and list my changes there, rather than on CD.

[raystubbs]

Wow, you really know what you are doing, I have a lot to learn.

[raystubbs]

[QUOTE=lopsided98;1486748]

Add support for saving multiple layout files and renaming layouts


[\QUOTE]

I tested out the UI, it is much more attractive than that I originally had. But I don't see any options for adding multiple layout files.

[Ben Wolsieffer]

[QUOTE=lopsided98;1486748]

Add support for saving multiple layout files and renaming layouts


[\QUOTE]

I tested out the UI, it is much more attractive than that I originally had. But I don't see any options for adding multiple layout files.

Sorry, I should have clarified that. I added support in the backend for multiple layouts, but there is no UI yet. I'm currently working on one right now.

[raystubbs]

[QUOTE=raystubbs;1486768]

Sorry, I should have clarified that. I added support in the backend for multiple layouts, but there is no UI yet. I'm currently working on one right now.

Oh, I see. Well thanks for what you're doing, the project would probably be dead by now if you hadn't started working on it.

[Ben Wolsieffer]

I tried to test the app today with our robot, and I was able to get control, but I ran into a problem. After somewhere between 5-10 seconds, the robot would disable and I would have to toggle the enable/disable button to get it to start again. Also, sometimes it seemed to emergency stop and the only way I could get control again was to restart the robot. Do you have any idea what could be going on here, because I don't have much experience with the protocol? I'll try to dig through the network code soon and see if I can figure out what's going on.

I also pushed an update with the ability to switch layouts and a packet capture from while I was testing.

[raystubbs]

I tried to test the app today with our robot, and I was able to get control, but I ran into a problem. After somewhere between 5-10 seconds, the robot would disable and I would have to toggle the enable/disable button to get it to start again. Also, sometimes it seemed to emergency stop and the only way I could get control again was to restart the robot. Do you have any idea what could be going on here, because I don't have much experience with the protocol? I'll try to dig through the network code soon and see if I can figure out what's going on.

I also pushed an update with the ability to switch layouts and a packet capture from while I was testing.

I made some really big untested changes to the comm code before releasing it. I have an idea of what could be the problem, but since I can't test it I'd rather start off with making a smaller change: in the PacketManager class there is a constant that controls connection timeout delay, try giving it a higher value.

I don't remember what the constant is called or its default value, and can't check right now because I'm typing this from an ancient, phone with a tiny keypad. Ijll look at the code when I get the chance and try to give a better reply.

[raystubbs]

I looked at the code, the constant

private final int DISCONNECT_DELAY = 1000; //Two seconds


controls how long the connection can last without receiving a valid packet from the rio, if the rio waits longer than 1000 (1 second) then the manager disconnects. Though the comment in the above code says "Two seconds" the code was changes since then and I guess I neglected to change the comment.

The other major untested change I made is in when the packets are sent. In the original system I made the DS send a packet every 20 ms regardless of whether it received a packet from the rio or not, in the current system the manager establishes connection with the rio, then it waits for the rio to receive a packet from the rio and responds with a packet of its own. This system could move the packets time-stamp outside of when the rio expects to receive a packet. I don't think this should happen, but it might. So I recommend changing the DISCONNECT_DELAY to about 3000 and testing it before messing with the comm code.

[raystubbs]

I looked at the code, the constant

private final int DISCONNECT_DELAY = 1000; //Two seconds


controls how long the connection can last without receiving a valid packet from the rio, if the rio waits longer than 1000 (1 second) then the manager disconnects. Though the comment in the above code says "Two seconds" the code was changes since then and I guess I neglected to change the comment.

The other major untested change I made is in when the packets are sent. In the original system I made the DS send a packet every 20 ms regardless of whether it received a packet from the rio or not, in the current system the manager establishes connection with the rio, then it waits for the rio to receive a packet from the rio and responds with a packet of its own. This system could move the packets time-stamp outside of when the rio expects to receive a packet. I don't think this should happen, but it might. So I recommend changing the DISCONNECT_DELAY to about 3000 and testing it before messing with the comm code.


I took a look at your capture, communication seems to continue throughout the first 10 seconds, of course I could not look at every packet. The packets seem to be enabled throughout and there doesn't seem to be any estop. If you could capture while you connect to the robot up to when the app disconnects, and not restart the connection then I might be able to figure it out.

[Ben Wolsieffer]

I'm working on a Wireshark dissector for the protocol, so I'll see if I can find anything unusual, and I'll try to get better data next week when I can test the robot again.

[Ryan Reliford]

Any update on this app?

[raystubbs]

Yes. I stopped developing it since I lost access to a Rio. Bot
lopsided98 has been developing and last I've heard the app should be working, but is yet untested. His repo is here https://github.com/RobotsByTheC/RoboDS. You can download the code and build it or you can ask him for an APK. Let me know how it works will you.

[Ryan Reliford]

Thanks.

[Ben Wolsieffer]

I would be careful, though, as I can't guarantee that it won't cause unintended behavior. Now that school has started again, I should be able to test it fairly soon.

[Ryan Reliford]

Sure. Thanks for opening this up for others and continuing to work on it. I've begun forking the code because I want to use static joystick configuration. Did you find anything via wireshark that might cause issues? Did the 3 second timeout prevent the disconnects you mentioned a while back?

[Ben Wolsieffer]

Sure. Thanks for opening this up for others and continuing to work on it. I've begun forking the code because I want to use static joystick configuration. Did you find anything via wireshark that might cause issues? Did the 3 second timeout prevent the disconnects you mentioned a while back?

If you forked my code, then most of the discussion in this thread is not that relevant, as I have rewritten a lot of the connection logic. Last time I tested the app, it connected correctly, but there were a couple of problems that prevented it from being able to control the robot. Those problems are theoretically fixed now.

Also, what do you mean by static joystick configuration?

[Ryan Reliford]

By static joystick I mean doing away with the joystick editor and having axes and buttons hard coded.

Have you committed the theoretical robot control fix to your git?

[Ben Wolsieffer]

Have you committed the theoretical robot control fix to your git?

The code on GitHub is completely up to date.

[Ben Wolsieffer]

I tested the app last week, and sadly it still does not work. I am quite confused by what it is doing currently, as it appears to be crashing the communication software on the robot.

When I start sending packets to the robot, it never sends anything back. Afterward, when I try to drive the robot with the normal driver station, the robot does not respond until it is rebooted. As far as I can see, there is nothing wrong with the format of the packets being sent, but something is obviously wrong.

I'll try to figure out more when I get time.

[raystubbs]

How many connection packets do you send at the beginning? How long do you wait for a response? Also you can look for errors and restart the program by ssh-ing into the box and manually relaunching the binary.

The binary is probably in the default home directory, but otherwise it can be found in the program's build script on your workstation.

[raystubbs]

Found a problem in PacketManager:


if (connected && !timeSent) {
driverStationPacket.addTime();
timeSent = true;
}


This sends the connection/time packet as the first packet, the RIO never actually processes it. You need to send normal packets until the RIO responds for the first time, after the first response THEN you send the time packet and the RIO will accept it.

Here is my implementation:
https://github.com/raystubbs/RioComAPI/blob/master/RioComAPI/src/com/litlebot/rioapi/proto2015/ComManager.java lines 171-197

[Ben Wolsieffer]

Found a problem in PacketManager:


if (connected && !timeSent) {
driverStationPacket.addTime();
timeSent = true;
}


This sends the connection/time packet as the first packet, the RIO never actually processes it. You need to send normal packets until the RIO responds for the first time, after the first response THEN you send the time packet and the RIO will accept it.

Here is my implementation:
https://github.com/raystubbs/RioComAPI/blob/master/RioComAPI/src/com/litlebot/rioapi/proto2015/ComManager.java lines 171-197

I don't think that is the problem, because the connected flag is not set until the first packet is received from the robot, so the time is not sent until this happens. Also, my packet captures show that the time is not being sent.

[raystubbs]

Oh OK.

[ShotgunNinja]

Wow, I'm looking forward to this app being more complete; maybe if I convince a nearby team to let me mentor, I'll be able to get access to a bot and start testing this out. I'm a software engineer by trade, and I've been looking to get involved with something FIRST-related and 'Droid-y.