This year we’ve decided to use the LabView stuff to get some debug/info data from our robot using the link between the operator interface and the computer. I’ve created a little dashboard interface for our little test robot that tells us batteries info and PWM output. We’d like to have sensor data too, ex: encoder counts, gyro angle, etc… However, I can not find a way to read that data in using this template/toolkit in our dashboard:
I’ve attached the file of my dashboard, as I still do not understand all the LabView lingo quite yet.
You have to understand what the Dashboard is doing - it is sniffing the communications between the OI and the RC. The sensor data doesn’t get transmitted between the RC and the OI.
However, there are 6 user bytes in the communications stream (the UserByteX bytes, where X is 1 through 6) that you can fill in yourself in order to get your data up to the OI. In your robot code, you need to fill in the data into the user bytes. Then, in your LabVIEW code, you can read those user bytes. And VIOLA! You’ve just gotten your data up and you can display the data.
If you need more of an explanation, just let me know.
Oh, also I noticed you are trying to use OI data as well as RC data in your dashboard. Realize you will only get the kind of data that your jumper on your OI allows (there’s a jumper on your OI to select between RC data and OI data). I recommend RC data so you can see user bytes and PWM data and the like.
If you run out of User bytes, another trick you can use is to stuff your sensor data into unused PWM data slots (i.e. make sure there is nothing connected to those PWM ports!). Then your dashboard can read the PWM data slots and make the conversion to sensor data.
Yes, that’s correct! Now, something very important to keep in mind about user variables - user variables are only 8 bits wide (one byte, range 0-255). If you pull in an analog sensor value, they are 10 bits wide (more than one byte, range 0-1023). If you want to preserve all 10 bits, you need to store the values in 2 user bytes - 8 bits in one, and 2 bits in the other. If you have multiples, you can “bundle” the 2 bits from 4 user bytes together (to send 4 analog values at once), but if you have just 1 then grabbing 2 8-bit chunks is easy enough. Here’s how you do it:
unsigned int analogValue = GetAnalogValue( rc_ana_in01 ); // analog input port 1
UserByte3 = (char)analogValue; // Pulls low 8 bits
UserByte4 = (char)(analogValue >> 8); // Grabs high 8 bits
and attached is what the LabVIEW code would look like on the other end to put it back together (remember, the values you pull out of the user byte are 32 bit representations, you have to cast each to 8 bits for the “Join Numbers” primitive to join them into a 16-bit value correctly). I have attached both an image of the code AND I attached the VI.
Yes! This is a useful little trick, especially for dedicating slots for data that changes rapidly (like gyro data). If you multiplex data using user bytes you really need to have some kind of key to let you know what data you’re seeing on the LabVIEW side - if you can dedicate unused PWM values that takes a burden off of the “cleverness” of your code. However, my team has found that we rarely have leftover PWM slots, though this year may be different since we’re using pneumatics and relays instead of PWM and motors for a lot of things.
