Robots not under driver control- does it happen- do you determine why?

[boomergeek]

Originally Posted by Mark McLeod

The easiest most efficent way is to just take the summary from the DLink statistics page. At least that's what I prefer to use since the DLink is made to collect that kind of data. It's nice because it's also the point that divides the transmission statistics into wireless (DLink<->field router<->DS) and Ethernet (DLink<->cRIO). We actually get additional results that the FMS logger doesn't have. In the past I've been able to identify a specific bad pin on the cable between the bridge and the cRIO this way.

Either captured by a query script (maybe while disabled after Teleop is over), or just examined via a web browser after a match. To examine it after a match be sure to leave the robot powered to preserve the match data until you can hookup your laptop.
Of course, if your DLink is rebooting then the data does get lost, but at least you'll have proof that it's rebooting.

I'd hesitate to log too much data too quickly on the cRIO, because of the potential for overload
If you're running a more powerful laptop as the driver station, logging the majority of the data back there might have less system impact, as well as being more easily accessable.

Do you have an existing query script you would be willing to share that we could work from for accessing the DLink?

Is there a description of the various modes of WiFi that the FRC field will use?
(E.g., 2.4G versus 5G, 802abgn)
Is hunting between modes ever supposed to occur?
Does the FTA check to see that team have provisioned other modes consistently other that bridge/AP?

The document How_to_Configure_Your_Radio_Rev_A on page 11 seems to imply 2.4/5G, 802abgn, no autoscan, channel 6, channel width 20MHz is standard competition configuration.

E.g., do all team need to be using auto chan scan or are teams allowed to provision their DLink to camp on the unshared channels?

[Greg McKaskle]

A comment on the difference between Run as Startup and pressing the run button using LV.

Running LV with only the run button is quite similar to running as startup, but because the panel(s) are open, the cRIO and development computer are both working a bit harder communicating info back and forth about panel values.

This protocol is typically lightweight, just sending binary values, usually from robot to dev computer. If you change a panel value such as a PID gain, the dev sends a small packet to the robot. Obviously, the more windows you have open, the more traffic. The more probes you add to your VI, the more traffic. Vision is a case that is not lightweight. It is extremely useful to be able to probe and view panels with camera data on them, but to get the data to the laptop, the image has to be compressed by the cRIO and transmitted as part of the protocol. This only happens if the image is visible on a probe or panel. Scrolling the image offscreen won't help, and I doubt that minimizing helps. To lighten the load, you close the panel with images when you aren't using them.

I develop with the run button all the time, but then again, I like debuggers. Also, I usually don't run the dev stuff and DS on the same computer, and almost never run both on a Classmate. Hopefully this helps explain why panels can indeed cause dropouts, but it doesn't have to force the Startup approach too early.

Greg McKaskle

[quinxorin]

Our team has had some problems.
Our 2009 robot was always a little sluggish - we know it to be a bug in the programming.
Our 2010 robot usually worked well. There was one match where our robot began behaving eratically without control of the drivers. The entire alliance did, so we believe it was a field fault.
Our 2011 robot has not had any problems yet.

We usually place our radio somewhere exterior on the robot, but protected by a sheet of Polycarbonate. Our 2011 robot has it completely unshielded (it is in a position where it would be very difficult to be hit) but our 2010 robot had a piece of 3/8in Polycarbonate armor (yes, that's bulletproof).

[Joe Ross]

Originally Posted by boomergeek

Does the FTA check to see that team have provisioned other modes consistently other that bridge/AP?

The radio gets reset and reprogrammed at the Radio Kiosk automatically. There's nothing for the FTA to check, unless a team went in and changed something after the radio programming.

[boomergeek]

Originally Posted by Joe Ross

The radio gets reset and reprogrammed at the Radio Kiosk automatically. There's nothing for the FTA to check, unless a team went in and changed something after the radio programming.

So if the radio is "factory reset" to defaults and then specific parameters get set at the Radio Kiosk.
Which parameters end up being different than the factory default, besides Bridge mode and IP address and mask and gateway?

http://www.usfirst.org/roboticsprogr...t.aspx?id=8632

The FMS Delta software will be pre-installed on a laptop and shipped with the playing field electronics. FIRST will also ship a lower cost field access point, a Linksys WRT610N or similar, configured for 802.11N @ 5GHz.

I'm trying to figure out if 802.11N @ 5GHz is the only mode that a field access point will ever use. If it is, then why does the competition settings of the DLINK DAP-1522 not specify these particular options?

The shaded picture in the document How_to_Configure_Your_Radio_Rev_A on page 11 seems to imply 2.4/5G, 802abgn, no autoscan, channel 6, channel width 20MHz is standard competition configuration.


I think we had been using 2.4G in our practice: it might give us better range for practice, but won't uncover weak signal issues we might have when using the lower range 5GHz in real competition.

[AndrewN]

Originally Posted by willishf

In theory the gearing ratio could be 2.166667 from the wheel to the rotation of the optical encoder shaft and the reason for the non integer multiplier. Always feel better when you have nice integer multipliers.

The output shaft of the gearbox has a 12 tooth sprocket, the wheels have 26 tooth sprockets: 360 (encoder counts) * (26/12) = 780

Note: An encoder labeled "360" will give 360 counts at 1X as it counts only the leading edge of A, 720 using 2X, counting leading edges of A&B (or leading and trailing edges of A), and 1440 using 4X which counts leading and trailing edges of both A&B signals.

PS. The cRIO FPGA handles the signals from the encoders and does not cause interrupt overload. Some teams have the encoders wired into CAN controlled jaguars - these do not cause interrupts either.

[Ankit S.]

Losing control has never happened to us when not on the field, but when we were on the field we lost control twice, and one of those two times the e-stop would not register either, and our robot kept running after endgame.

The second time, the e-stop did trigger.

[Owen Meaker]

In our first match at Seattle Cascade (which was qualifcation match 1), we had no control of our robot. about 30 seconds into the match we realized that we had forgotten to plug in our joysticks . after we plugged them in, they didn't connect till after the match. the next couple matches we had issues of burning out jaguars, which with mecanum wheels causes driver control. after replacing a few and remounting them to prevent overheating, we were fine the rest of the regional.

[Greg McKaskle]

Once the match starts, the DS no longer enumerates looking for changes to joystick connections. It just takes too long. If you change joysticks in a match, hit F1. It will force an enumeration and you should be good to go.

Greg McKaskle

[edzenitis]

We had similar problems as team 935 during the Sacramento Regional. The robot seemed to work for one round, then we would come back to the pits, and in the next round, autonomous worked but teleop did not. We would redeploy the code and it would exhibit the same pattern. It would work once and then next time it wouldn't work. At one point the controls, when working, were sluggish.

We were not able to get field time to diagnose the problem on the field. It worked fine tethered in the pits or on the practice field. Finally the field operators collected some data that showed that we were lagging in field communications compared to the other teams. In the pits we were allowed to use the old radio to try and diagnose the problem. We were able to show that there was not a lag with this set-up.

We use PWM for our motors, no CAN, and no camera (although there was still some initialization code in the begin.vi).

We are still desperate to fix this problem before San Jose Regionals on 3/31. Any insight would be appreciated.

[Maxzillian]

We ultimately found a number of problems that could have effected our robot. Going down the list:

1) The classmate PC had a broken ethernet port that prevented the cable from clicking into place. If memory serves, the cable only needs two specific wires to be connected for it to think there is a proper connection (even though some data wires may not be connected). This may explain our dead robot during teleop while the field showed we were connected.

2) In labview there is no error handling in the CAN-Jag VIs. The potential is that if there is a CAN error and the cRIO does not at least accept the error (it doesn't necessarily have to do anything about it), it could cause the cRIO to freeze or lead to partial functionality of the CAN network.

3) During autonomous it was evident that the robot was not being fully killed when autonomous ended. At the end of one of our autonomous routines the robot is commanded to rotate at the very end of the period. Often times this command is chopped by the end of the period. After reviewing replays we found that on some occasions the robot would stop rotating once the period ended, then after a brief pause would finish the command as teleop was starting. This, however, did not coincide with our occasional loss of comm or occasional loss of some of the CAN-Jag controllers.

Ultimately we decided to not roll the dice and took a number of precautionary measures in the week hiatus between Kansas City and Oklahoma:

The autonomous was no longer commanded to rotate at the end of the period.

We rewired all but one of our Jaguars to PWM control. The one remaining Jag was now technically operating off RS-232. This one was necessary as it used an encoder to determine arm position and we did not want to reprogram the cRIO to incorporate an internal PID control.

We replaced the classmate with one of our development laptops, a run of the mill Dell or Toshiba, to resolve our connector issue.

Ultimately these changes resulted in a flawless performance of the robot at Oklahoma, but does not necessarily provide any answers to our previous problems. It is evident, however, that we had at least two problems (loose ethernet connector and no CAN error handling) that should have been addressed before Kansas City and potentially would have quenched all of our problems. However, it was not worth potentially ruining another regional to test that theory out.

We may attempt to do more testing next year with the CAN control. Additionally we found that during testing in the build season, the laptop was never operated in practice mode (so we never truly simulated "field" conditions) and we never used the classmate in testing (potentially our biggest mistake).

Regretfully, after observing numerous Jaguar failures for other teams, and a few of our own, we may end up moving to the more bulletproof Victor controllers unless a hardware change is implemented in the Jaguars to improve their reliability.

[boomergeek]

After significant trouble at BAE which we primarily chalked up to using 2CAN and seeing many CAN timeout messages during every match: For Boston this week, we had moved to PWM.

We also pulled a chain and isolated a tan Jaguar that would work in forward but not in reverse.

We moved our radio to a higher place on our robot.

Control worked perfectly through all qualifying matches and three quarter-final matches. HOORAY!

In the first semi-final match that we played, about 30 second in we lost complete control- we rebooted the robot from the driver station and regained control for the last bit of the match.

The Field Tech immediately came over and started to help us try to figure out the problem. His initial hunch was a bad power wire to the cRIO. I thanked him and told him we had rebooted from the DriverStation. At that point, he asked if we changed our software, which we had because of a change requested for autonomous. He then suggested to run a simulation match while we waited for the other semifinal match. We did: and it ran with no problems.
We visually inspected and yanked on the cRIO wiring with no impact.

We played the second match and the Field Tech stood next to us for the entire match. We again lost communication for 20 seconds. This time we did not attempt to reboot from the Driver Station and got control back more quickly. The Field Tech at that point was fairly confident that it was a power to the cRIO problem.

And he was exactly right!

After the match, in the lighted area of the pits, after wiggling the power connections to the cRIO for about a full 5 seconds: the cRIO lights blinked and it reset.

SPEND TIME GETTING YOUR cRIO POWER CONNECTIONS RIGHT and TEST them periodically!

My advice: Use Checklists rigorously!

[huberje]

Twice during the elimination rounds in the VCU regional this weekend our robot would not respond for roughly two seconds. This had not happened at all during the qualification rounds or in our previous regional. Everything was fine otherwise, though, so I'm not sure what I should blame it on. Maybe some testing will help clear that up.

[Greg McKaskle]

Dick, can you give more info on how the connection was done, and what was wrong with it. The reason I ask is, I hope to get an NI engineer to write a best practices article and specifically include this connector. I want to include images of common approaches and explain what is likely to fail.

Thanks,
Greg McKaskle

[boomergeek]

Originally Posted by Greg McKaskle

Dick, can you give more info on how the connection was done, and what was wrong with it. The reason I ask is, I hope to get an NI engineer to write a best practices article and specifically include this connector. I want to include images of common approaches and explain what is likely to fail.

Thanks,
Greg McKaskle

I'll post pictures next week after we get the robot uncrated.

My imperfect memory believes the stranded wire was not twisted tightly nor was it pushed in deep enough and thus sort of connected mostly as a right angle into the connector- making contact only with the top contact and the middle contact (by the sides of the blades but not the knife edges) and did not make it down to the bottom contact.

After I had wiggled two wires roughly for 5 seconds and got it to lose power, I was then able to pull one all the way out and its length into the connector was much shorter than I expected.

I'm always debating with myself if these types of connectors are better with a light solder to hold the twisted wire or the greater mechanical flex of a tightly twisted wire. I'm fairly certain a poorly twisted wire is a bad choice.