Team Fusion's take on cRIO and LabView

First off… Wow! What a complex system we have to work with.

Well, I went to Gulfport High School today to help the students on the team setup the new control system and play with it a bit. We had our problems and still have a lot to do before we can even think of putting it on a real robot.

We first started the day with firmware upgrades… this went well and according to plan. We were able to test the whole rig and found it to work. We shut the “robot” off and back on and found that the motors just started to run on their own!!! What the heck is going on? This is default code and its doing this. Reset it and it didn’t do it again. Later we were just trying to establish a connection and didn’t have any joysticks connected. Again, the motors started spinning! I’m not going to lie; I haven’t searched for this problem and don’t know if this is common.

I also noticed that our 5V LED indicator for the 5V output on the PD board does not work. I know for a fact that it is outputting at 5V and powers the camera just fine. I’m thinking the LED has reverse polarity from the factory or something… not sure… I’m not worried about the functionality, but I do want to know if the inspection people would be looking for this, as it’s not an error by us, but just a defect. The captain this year was saying that we would have to ship everything back if something was broken, so I don’t want to go that route. Here’s a picture:

The gray thing is the camera with the power light on, and below is the 5V LED off…

I’m also curious to how many teams are clueless on how to use LabVIEW. I’ve had no experience with it and had my first large dose today. My brain is drained and I have a headache…

Overall, this is a complicated and powerful system. It should really give teams with LabVIEW experience a great benefit. They’re holding a workshop at NASA this Saturday that I’m going to go to for a few hours until our family gathering begins.

I’ll post updates on our team’s progress or other members may post updates.

We have the exact same problem with the 5v LED. Controller and camera work fine, but no LED.


When your wheels started randomly running, did you have the Driver’s Station connected? Was it Enabled? Was it in Autonomous mode?

If the DS wasn’t connected or enabled, this shouldn’t have happened, and NI, WPI, and FIRST would probably all like to know exactly what you were doing to make it occur.

If the DS was in autonomous mode, the OTB firmware has an autonomous mode that runs the motors for 2 seconds. This might have been what you noticed.

If the robot was in Teleop, you might have run across one of the bugs with the USB ports. First, the kit joysticks center themselves when the DS boots. So if you’re leaning on the joysticks when you power up the DS, they’ll be horribly off-center. So your motors could start up on their own.

A different issue is if you unplug the joysticks. They’ll continue transmitting the old value even though they’re unplugged. As far as I can tell, the only cure is to reboot the DS.

Finally, in what’s probably a related issue, the joysticks sometimes transmit bad values after the DS starts up, until they’re moved. The solution here is to jiggle the joysticks.

So your start up sequence should be:

  1. Put Disable DS with dongle switch or by removing dongle.
  2. Plug in all joysticks, and don’t touch them until step 4.
  3. Power up the Driver’s Station.
  4. When DS is finished starting up, jiggle the joysticks.
  5. Enable robot and go to work.

The people responsible for the Driver’s Station are apparently looking into the bad values from the joysticks on boot and when unplugged, but there hasn’t been word on progress.

Connected to DS in Teleop mode. Thanks for the info, I’ll mention that tomorrow.

Just posted this in the FIRST forums. We are stuck in Arcade Mode. We performed the updates to the DS and the cRIO. We had tank drive working for a while (just randomly started working) but then it went back to Arcade style.

Motors moving by themselves sounds like one of two things. The first one that comes to mind is that the system runs its motors in autonomous mode out of the box – did someone perhaps flip the switch on the Driver Station from Teleoperated to Autonomous? The other possibility that occurs to me is that you might be reusing Victors that have a non-factory calibration, and what the Digital Sidecar presents as a “neutral” output is actually interpreted by the Victor as a little bit “forward”.

The 5v LED on our Power Distribution board flickered and died as we were preparing to connect some 12v wires this afternoon. This sounds like the start of an epidemic.

It was in Teleop for sure, and we were using the really neat new Jaguars! I’m going with Kevin’s idea.

Have you tried moving the throttle on joystick#1? After you update the cRIO image, that is the way you switch between arcade and tank drive. Move it all the way one way and you have tank, the other way gives you arcade (not sure which is which though)

I’m starting to learn how to use LabVIEW and figured out how to make it work. We now have live video going to the laptop wirelessly from a kitbot. We’re now working on camera tracking… Help? Haha…

Camera tracking was the hardest thing to get working. The Example programs look very complicated, so you hardly know where to start, let alone how to drive a robot with it.

I found out, through much experimentation, that you really only need two vision vi’s, IMAQ Color Threshold and IMAQ Particle Analysis Report. You wire the image from the camera and wire the color range you want into the Color Threshold vi. This vi looks for the color you specify and removes any pixels that are not in the color range. You can then wire the resulting image into the particle analysis. The Particle Analysis vi will give you an array of particle reports for every particle mass it finds. You probably want to make a global for the particle reports so you can access them in autonomous. The report with the highest area is the object your looking for. You can get the center of mass from the report and use it to compute how much to turn.

Hope that helps. There’s a lot there, I might have to make a tutorial if it doesn’t make sense.

I THINK this is what we are doing. I just keep the bot running and let the programers play. I am present for most of the testing however.

We have been amazed at how insensitive the camera is to variations in lighting. When you think about it a red ball in a dark space has not changed color, but our perception of its color has. We think it is a darker color. This camera is not fooled. If there is even a very little bit of light the camera will find the color it is looking for. The biggest problem is on the other end. If the light is too bright the color washes out.

With this system 2005 would have been a very different game.

Thanks for the help with camera tracking. I also cannot figure out how to use the buttons on the joysticks. I’ve spent a lot of time trying to figure it out, and I’m sure I’m looking over something very simple. I guess I cannot find the right vi.

Also, how many people are having trouble with laggy connections to the robot? We were able to get the live video feed to the robot, but could only run it on 160 x 140… or whatever the lowest setting was at 5FPS to keep it controllable. With the highest setting, the robot saw a 2 - 3 second delay.

Everything else seems to be working well. We’re bringing our test board and a kitbot to NASA on Saturday for training purposes. I’m happy with the space this system takes up, and was able to fit everything onto a pretty small board minus the gaming adapter and camera.

Here’s a video of the control system’s first trip.
Note: The video may not be up quite yet, but it should be soon.

Yeah, using the joystick buttons isn’t very intuitive. You have to use the Joystick Get Raw vi. One of the outputs is a cluster of button values. Use an Unbundle By Name vi and select which button you want. We are only using two buttons right now, the ones on the top. I think those are buttons three and two.

Laggy connection? When your pulling in data from the camera and displaying it on the front panel, it can be pretty slow. If you download your project to the cRIO as a start up program, it will run without a connection to the front panel, which I have found to be a lot faster. When I was trying to get camera tracking to work, the robot would turn for too long, and then would try to correct, overshooting again until it couldn’t see the object. Once I downloaded the project, it was much more responsive, and it could track better. We have our camera set to 320X280 and the fps to 30.

Good job on getting the robot running! It looks great.

Cool! I have it written up in LabVIEW, just need the robot now. Maybe I can try it tomorrow, and hopefully it works.