Hi we are unable to deploy code. The menu option is missing. We’ve reinstalled eclipse and all the plugins etc but nothing works at all. Does anyone know how we can get around this bug?
You deploy code by clicking the green play button (top left in image below) and selecting “WPILib C++ Deploy.” Do you have that option?
I will take a look and see if we have that option available.
OK, that menu option does exist. However it does nothing at all.
I have created a sample robot program from the supplied sample.
We have made no edits to the sample cope at all.
we picked, project, clean
then, project build all.
Then pressed green play button, selected WPILib C++ Deploy
and…
Nothing at all…
(We are connected with the USB cable).
Any suggestions how we can deploy any code to the robot?
(connected over the network) you can scp the code to the robot, login and run it yourself, something like this…
I do it like this from Linux:
scp FRCUserProgram lvuser@roborio1296.local:/home/lvuser
ssh lvuser@roborio1296.local
(on the robot)
./FRCUserProgram
HTH
Hi and thank you for the reply. Unfortunately I know nothing about Linux or scp. Are there any options within the new roborio web page? If the roborio has a webserver on it, can I upload the code like a web page instead? Would that be done using HTTP protocol?
Thanks
I tried disabling wifi and wired lan and then I got the deploy option to do something. Unfortunatly the Roborio still doesn’t work. The RSL is on solid, I assume this means there’s no robot code. Anyway, I couldn’t make the deploy option work again because it was no longer on the menus. I deleted all my robot code projects and created a new robot sample. I am now getting a brand new error and the deploy option refuses the work too. Here’s the error I am getting now.
Info: Internal Builder is used for build
arm-frc-linux-gnueabi-g++ -std=c++1y “-IC:\Users\Developer/wpilib/cpp/current/include“ ”-IC:\Users\Developer\workspace\Mecanum Drive\src” -O0 -g3 -Wall -c -fmessage-length=0 -o “src\Robot.o“ ”…\src\Robot.cpp”
arm-frc-linux-gnueabi-g++ “-LC:\Users\Developer/wpilib/cpp/current/lib” -Wl,-rpath,/opt/GenICam_v2_3/bin/Linux_armv7-a -o FRCUserProgram “src\Robot.o” -lwpi
c:/frc/bin/…/lib/gcc/arm-frc-linux-gnueabi/4.9.1/…/…/…/…/arm-frc-linux-gnueabi/bin/ld.exe: warning: libstdc++.so.6, needed by C:\Users\Developer/wpilib/cpp/current/lib\libFRC_NetworkCommunication.so.1.5.0, not found (try using -rpath or -rpath-link)
23:05:35 Build Finished (took 11s.170ms)
Does anyone know hoe to use the rpath- or rpath-link functions?
that is a warning, not an error
Are you getting anything in the Eclipse Console when you try to Deploy? Or does nothing happen at all? How about if you right click on the build.xml in the project and select Run As->Ant Build (I think that’s what it’s called, this computer doesn’t have Eclipse to double check).
Try connecting through the network - the first step (after imaging the roborio, did you do that?) is to see if you can ping roborioXXXX.local (XXXX is the team number). If you can do that then deployment from Eclipse should work. Can you post what is printing in the console window (one of the tabbed views in the bottom center of the perspective) when you try to deploy.
I can’t help much with the USB connection. We only did that once when we imaged the roborio. You have to connect it to a network eventually anyways - that is how you connect to the driver station. Try it on the network.
HTH
Our team is having a similar problem. we have been deploying from our team laptop for about a week now, everything was going fine. Last meeting however, something changed. When we tried to deploy I noticed that the normal option “WPILib C++ Deploy” had vanished. then after restarting eclipse it now says “WPILib Java Deploy” when clicked it does nothing. the plugins for WPILib java are not installed on this machine. The Ant build option does seem like its deploying (Ill be able to connect to the robot tomorrow.) I have the same problem on a second computer only this one has never populated a deploy option. Why is all this is happening, and is there a better “fix”?
Update:
after using the “ant build” option on PC 2 eclipse ran a brief “installing cpp” command, then the build option populated. Trying to replicate on PC 1, so far no such luck.
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?
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
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.
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.
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.
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.