C++ deploy code missing

[robat-mentor]

Well after much trouble I think I have found some things that might help. We have found a series of quirks and tricks that are required for deployment to work. In order to help other teams get past these major problems, here's a list of the things you need to know. We learned these the hard way but we're glad to help any other team and save them from the hell we went through.

First of all, it's crucial that you do not have multiple channels active. What I mean by that is that when you plug in the USB cable you MUST disable the wired and wireless LAN adapters in your laptop. This is the ONLY way that Eclipse will not become hopelessly confused and remove the deploy menu option.

Secondly, after you have deployed you MUST unplug the USB and then plug it back in again BEFORE you can deploy again, otherwise Eclipse throws an unrelated error which is very misleading.

Thirdly, after you deploy code you MUST find the "restart robot code" button on the drivers station and press it. Otherwise the drivers station erroneously reports that there is NO ROBOT CODE on the roborio.

Fourthly, don't expect the roborio to flash the RSL like the Crio did. There seems to be only 2 modes. ON SOLID or BLINKING. Neither of these modes seems to have anything to do with robot code or the readiness of the roborio at all.

Finally, As I mentioned, whenever you deploy you MUST disable both wired and wireless LAN adapters so that the USB connection is the ONLY choice that Eclipse has available. Once you have deployed you must unplug the USB connector and enable your wireless adapter so that the drivers station can connect to the roborio. I find this very annoying and time consuming.

We have NEVER been able to deploy using ethernet, wired or wireless at all so we stopped wasting our time trying to make it work. There are always challenges related to the setup and usage of the FRC IDE but this season seems to have magnified those challenges and made them a complete show stopper. Our team has lost 1 week of our build season due to these newly introduced problems. We've been unable to deploy any code and therefore unable to test anything. Is this supposed to be part of the challenge?

[bob.wolff68]

Wow - this is a VERY restrictive setup you seem to have. I think the information is GREAT for those having troubles. However, I will say that our team's experience this year is VERY different than yours. We are able to have ethernet and USB connected simultaneously - we are able to deploy via either. We are able to deploy repeatedly - we are able to do so without asking for a robot restart of code or system - and our deploy menu item almost always is present. I do remember seeing it disappear on me once or twice but it came back seemingly without intervention.

I hope your experience can be helpful to WPI/FIRST and to those having troubles, but I don't believe it should be the 'rule' on how to operate.

Good luck and I hope your prescription continues to work for you consistently!

bob

[robat-mentor]

Thank you for taking the time to respond. I am very glad to hear that you haven't faced the problems we and many other teams have. We have learned through bitter experience that to deviate from the hard learned rules only results in many wasted hours reloading Eclipse etc. Your posting actually helps me to highlight another point.

Due to the highly random nature of the problems with the FRC IDE, the playing field is most definately NOT level at all.

I hardly think that it is in the spirit of Gracious Professionalism that our team should lose 1 week of our build season whilst other teams happily have no problems at all.

On the other hand, Solving problems and dealing with all eventualities is what we do best.

If you Google these problems you'll find many that we are not alone.

[Alan Anderson]

Originally Posted by robat-mentor

If you Google these problems you'll find many that we are not alone.

In the vast majority of those problems (at least the ones I know of), turning off firewalls and antivirus programs (and following the instructions correctly) has been the solution.


The causes of other less tractable problems are slowly being identified and fixed. One team eventually discovered that their school networking was inappropriately responding to mDNS queries and had to disconnect from that network. Another found that their school networking was actively interfering with their robot's wireless connection as a "rogue access point". As Bag Day is approaching quickly, I recognize that taking time to do deep troubleshooting is a luxury, and I don't know how long it would take to find the underlying issue given your resources. I do know that finding and fixing it will make the development process a lot easier and faster afterward.

[robat-mentor]

First of all, Thanks everyone for taking the time to respond and offer your help, we greatly appreciate all of it.

I totally agree with everything you've said. Since I own my own industrial automation software development company with a large customer base I can relate to your suggestions and observations. We have already ruled out the things you mentioned including following the instructions properly. As you also mentioned debugging the IDE is a very expensive luxury that our team simply cannot afford. In the absence of working solutions, we have developed a series of workarounds that we are forced to use at this point. We are also happy to share those for all teams having the same troubles. In supporting my customer base I often find that nothing beats being on-site and seeing problems first-hand. Perhaps the best way for our issues to be properly understood would be to come and visit our location. We can demonstrate the problems we're having and the solutions we've found. We'd love it if you can point us in the right direction. Taking that experience away will hopefully lead to some more readily usable solutions for all teams in the future. After many years in the industrial automation software business I am never surprised by the problems that my customer base can run into. Step 1 is always to accept that the customer is actually having the problems they describe and to try accurately identify the swiftest solution that the customer is happy with. No software is ever perfect and no software is ever finished. Customers always find new and interesting ways to make things fail. It's no-ones fault, it's just the way the universe is. There is mind-boggling diversity in life and as we discover more about the universe we discover that we know even less and less, we have more and more questions. If anyone's interested we'd be happy to have you come and see what we've found, we're a sociable bunch so if nothing else we can have a good time.

Thanks again.

[wireties]

Originally Posted by robat-mentor

Well after much trouble I think I have found some things that might help. We have found a series of quirks and tricks that are required for deployment to work...

I hope that you find your real problems but these problems and workarounds are a glaring exception, not the rule. We can't be leading other students down this path. What are you going to do at a competition?

We had 5 student programmers (2 with zero experience) install development environments on their own machines (with no help from me) and one of them (mine) is running Linux for development. We have had no problems. All things work as advertised. Admittedly, I've been doing this for 30+ years and I teach others (in corporate settings) about operating systems including VxWorks and embedded Linux. But we've had no unusual issues.

So for teams out there experiencing problems, follow the lead of the consensus of experienced mentors on CD. The problems and solutions described in this thread are an unfortunate anomaly.