@ hatboro everything worked fine in autonomous. ( in fact in practice round we hit both high goals)
While Tethered in the pits we had full control of our drive wheels, lift and shooter.
Our issues began and ended while we were in teleop on the field.
Our driver reported, and it was obvious that our bot would suddenly launch into reverse at the beginning of teleop and the oss of drive control quickly ensued.
Ironically everyone who looked at our code had a different take, and although all the suggestions were appreciated none of these ideas seemed to be glaring issues.
we did take several suggestions which were incorporated into our labview code.
With little time (6 hrs) to work on our bot between now and our next mar event (in week two!) I’d like to know if it’s possible to recreate the wireless situation that’s experienced on the field while we’re testing at school this week?
I should add that during testing last week @ school our robot worked flawlessly issuing our wireless router!!
Please keep in mind that I’m the structural guy and not well versed in labview
I have done some research about the field and can get you close to what you are going to experience on the field. It won’t be exact as what you are experiencing is the network lag. There are many devices on field that work on the network. From the DS to the robot it must pass through almost 4 switches till it gets to the AP on the robot.
However this could also be caused by a few other errors.
Can you get into any more detail about the problem such as if you are losing comms or any errors in your diagnostic tab?
Have you tried running your Driver Station in Practice mode? When you select Teleop or Autonomous, there is a Practice option. It will run the robot similarly to the field – 15 seconds of Autonomous mode and then 2 minutes of Teleop.
I worked with a team that had a similar problem at Boston last year. For the first ~30 seconds of Teleop, their drivers would have no control, then suddenly it would come back, and they were unable to replicate it in the pits either. The problem was that their Autonomous code ran for too long (specifically 30 seconds too long) because a loop in their program ran for 45 seconds. I’m guessing a similar thing is going on here, just for the entire match. You wouldn’t notice it in the pits because you’re skipping over the autonomous code when you click Enable and you’re not in Practice mode. Make sure you don’t have any loops in your autonomous program that last longer than 15 seconds.
Sorry if I’m sounding kinda vauge here, I only know the C++ and Java APIs.
The DS logs some information about the field communications. Have you reviewed it? If you go to the Program Files/FRC Driver Station folder, you’ll find a log file viewer, and it will automatically show you the log files by date. Look through them and perhaps compare them to some practice matches from your school. And I’ll second the Practice match run-through. It shouldn’t be that common for the LV framework to have auto run into tele, but with enough modifications to the framework, it can happen.
If you don’t see any issues with the comms, I’m curious to see what they look like. The log files aren’t very large, so you may be able to post them raw, otherwise the screenshot of the interesting parts may work better.
This may sound a bit in left field but something similar happened to us in 2010. We discovered a ground wire had come loose in our driver controls and caused all the joystick readings to go haywire. Happened in teleop mode even though autonomous worked fine.
I’ll third this! I’ve seen issues multiple times, including in LV, where teams are doing something in Auton that does not transition properly into Teleop. Doing the practice match simulation will tell you real quick if it’s in your code or in the field. If it happens consistently, I’m real inclined to believe it’s in your code.
Hi everyone. I am also on MrYeagle’s team and can try to add more details as to what we’ve done and what we’ve seen…
We have run it in Practice mode and typically it functions wonderfully. Once it didn’t (tethered), but the other 9 times it did.
The errors we’re getting are that teleop is running too slow and the robotdrive isn’t getting called fast enough. We didn’t have much in teleop in the first place, but we moved most of it out to PeriodicTasks, but still had the problem once (but not all the time???)
The weirdest thing about this is that there is no call in autonomous to the drive wheels at all. we shoot, load and shoot again in autonomous. We don’t drive at all, yet once switched into teleop (on the field) the robot flies backwards and can’t be driven.
In the pit, on the practice field and even wirelessly at home, we haven’t experienced this problem at all so we’re having a hard time fixing the issue. We only seem to have the problem in the competition when we can’t debug… very frustrating!!!
Did it happen every time your robot was on the competition field? It’s possible that your joystick/gamepad was bumped at an unfortunate time while the Driver Station computer was starting up, and the system might have gotten a bad calibration and thought that the full forward position was “neutral”.