search

Team2168 / 2014_Main_Robot

Code for the 2014 FRC season.
Other
2 stars 1 forks source link

Beaglebone #100

Open wshclth opened 10 years ago

wshclth commented 10 years ago

In CIAC many many times the bone was unable to get connected to the CRIO (or so it seems) Once in a while we got lucky and it connected. Need to find out what is causing it, why, and how to fix it.

NotInControl commented 10 years ago

what information can you share when you noticed this? What was the bone doing, were the lights flashing on the bone as well as the Ethernet? what was the dashboard doing, did you still notice the live stream of the camera? Were you ensuring that after each match the dashboard on the driver station was completely being closed and reopened? were you pushing code changes to the robot without killing the main breaker and restarting the robot? any one of those things would prevent the bone from starting up properly. looks like its going to be a fun week :)

NotInControl commented 10 years ago

The vision code on the Beglebone has a built in log file. It writes everything the code does to a log.txt file in the Beaglevison directory. We can look at that file to see what was going on on the bone side.

NotInControl commented 10 years ago

When I first learned about this problem today, i thought maybe it could have been because the venue FMS was blocking the port which the beaglebone communicated to the CRIO on (port 1111). But that should not be the case, we have a switch on board and are switching through the dlink. The bone packets to the crio should never be going through FMS therefore the FMS should not have the ability to block this communication. Something we were doing was more likely the cause. Was all other dashboard functionality working? Like tusk position status on the dashboard? Answers to the above questions in my earlier post would be helpful.

jcorcoran commented 10 years ago

If I remember correctly, the bone was communicating to the dashboard (on the field) twice the entire time we were there. I make that assumption based on the lights on the robot being red in disabled. They were otherwise yellow, which either meant a target wasn't detected or the vision code was not communicating with the bone. On numerous occasions we verified all red indicators on the dashboard.

You can't see the bone LEDs on the field, but have to assume that it was working properly since it would in the pits. I believe we did see solid LEDs on the bone (which I understand to mean there's an error) once in the pits, restarted the bone and dashboard and it worked again on all subsequent attempts in the pit.

The camera feed was working, pretty sure it was showing up on the dashboard fine.

Other dash functions were working as expected as far as I know.

Every time they set up on the field, the dashboard was launched fresh, and the robot came off a clean boot. No code was deployed to the cRIO the entire event.

Regarding the port not being an issue: Are you sure you understand how data is routed when the access point is in bridge mode? My assumption would be that it works the way you described (like a switch w/ wifi uplink), but I can't say for sure that that's how it actually is implemented on the DAP1522.