Enabling Default Dashboard in C++

[Travis Hoffman]

I'm trying to get the default LabVIEW dashboard indicators to update (so I can then pursue some customizations). I'm using WindRiver C++. I'm borrowing our code template we used last season (shared online so it's rules-friendly, not that anyone would want to use it ). On the surface, I think I ported over the dashboard specific code from this year's template properly. I did get the dashboard to display the camera feed, but the IO status indicators are not updating. Can anyone set me down the right path? I use the IterativeRobot class.

 
//Stuff in .h file
 
#include"DashboardDataSender.h"
 
DashboardDataSender *dds;

 
//Stuff in .cpp file
 
#include"DashboardDataSender.h"
 
//Dashboard Data Sender
dds = new DashboardDataSender();
 
//Update Dashboard Data
 
dds->sendIOPortData();    

Should I be calling the sendIOPortData() method in a specific location? Am I missing anything else?


Thanks,

[Dave Scheck]

I've been meaning to create and release a whitepaper on how we do our dashboard customization, but haven't had time this season. Maybe in our off week next week I'll get around to it.

It sounds like you're in the beginning stages, so lets start there and learn from the example code. Based on your question, I think you did this already, but if not, create a new dashboard sample project if you haven't already (File->New->Example ... Downloadable Kernel Module Sample Project ... FRC Dashboard Data Example) The way packing the data up changed from last year, so you'll want to take a look.

Let's work from the top down and look at the key sections. The RobotMain method makes callse to sendIOPortData() and sendVisionData(). These functions are in DashboardDataFormat.cpp. Calling these functions does everything you need to interface with the default dashboard. So the quick answer to your original question is yes. Make a call to both of these functions every time through your loop. If you're not using vision data, you don't have to make the call, but you have to update the Labview side to not be expecting that data.

So, to dig deeper, lets look at the internals of sendIOPortData(). The first thing it does is get a reference to the low priority dashboard packer. The packer contains the data that will be pushed onto the bit stream. My understanding that the low and high priority packers don't actually have different priorities in the data stream itself. On the receiver side, if the buffer is too large, the low priority packet is truncated.

Once the reference is obtained, it is populated. If you're not familiar with Labview, a Cluster is the equivalent to a structure in C++. Calling AddCluster designates the start of a cluster. It is closed out when FinalizeCluster is called. Calls may be nested to create more complex data types. The AddFloat and AddU8 calls add a float or UINT8 variable type to the packer.

When everything has been added and all clusters have been finalized, Finalize() is called on the dashboard packer. This designates that you are done packing and the data is ready to be sent out the door.

A similar process is done in sendVisionData for the high priority packer.

Once you have that framework in place, you can change it however you like as long as the packet that you're filling in on the C++ side matches what the Labview side is expecting. If it doesn't, you'll get an error on the Labview side that the packet doesn't match the format. This error can be tricky to debug. A few things that I've learned 1. A float comes across as a single precision type. Make sure your orange constants use the "single" representation. 2. Order is critical. You can right click on a cluster to reorder/view its contents.

Once you get the default working I can help you with the customization.

[slavik262]

Originally Posted by Dave Scheck

So, to dig deeper, lets look at the internals of sendIOPortData(). The first thing it does is get a reference to the low priority dashboard packer. The packer contains the data that will be pushed onto the bit stream. My understanding that the low and high priority packers don't actually have different priorities in the data stream itself. On the receiver side, if the buffer is too large, the low priority packet is truncated.

This is correct. The UDP datagrams sent from the robot are a fixed size (1018 bytes IIRC). After the header, high-priority data is packed, followed by error strings, then by low-priority data. The low-priority data is truncated to the packet size minus eight bytes. The last eight bytes contain four bytes of padding (bytes with a value of 0) and a CRC 32-bit checksum (for error detection).

[mikets]

I haven't looked into the dashboard stuff in depth but I have a few questions myself. Is the dashboard application customizable? If so, how do I customize it? Is the source code to the dashboard application available? My understanding is that the dashboard application is expecting data packet stream of a certain format. So if I customize the data packer for a different format, I need to change the dashboard application correspondingly. In addition, I would like to customize the dashboard application with different controls, lights, knobs and graphs. I am trying to change dashboard application into a diagnostic tool.
Thanks.

[Alan Anderson]

Originally Posted by mikets

I haven't looked into the dashboard stuff in depth but I have a few questions myself. Is the dashboard application customizable? If so, how do I customize it? Is the source code to the dashboard application available?

The default dashboard is a LabVIEW application. You can create a new Dashboard project from the LabVIEW starting screen. You have full control over what it looks like and how it works.

If you don't already use LabVIEW, it will be a bit of a learning curve for you, but it's not particularly difficult.

[Dave Scheck]

To build on what Alan said, open up the dashboard example projects on both the Labview and C++ side. The packet that's filled in on the C++ side maps to the pink cluster on the left side of the Labview diagram. As long as you get them to match, you can change them to whatever you want. The next thing to do is to trace the pink line coming out of the data type. It leads to a block that converts the binary stream into data of that type. The output of that block is a cluster that you can use the unbundle by name block to get the data. My suggestion is to find where the unbundles are in the example and replace them with logic controls of your own. Once you get the hang of it and come up with a good way of packing your data, it's pretty easy.

[Radical Pi]

Originally Posted by Travis Hoffman

I'm trying to get the default LabVIEW dashboard indicators to update (so I can then pursue some customizations). I'm using WindRiver C++. I'm borrowing our code template we used last season (shared online so it's rules-friendly, not that anyone would want to use it ). On the surface, I think I ported over the dashboard specific code from this year's template properly. I did get the dashboard to display the camera feed, but the IO status indicators are not updating. Can anyone set me down the right path? I use the IterativeRobot class.

 
//Stuff in .h file
 
#include"DashboardDataSender.h"
 
DashboardDataSender *dds;

 
//Stuff in .cpp file
 
#include"DashboardDataSender.h"
 
//Dashboard Data Sender
dds = new DashboardDataSender();
 
//Update Dashboard Data
 
dds->sendIOPortData();    

Should I be calling the sendIOPortData() method in a specific location? Am I missing anything else?


Thanks,

The reason the indicators don't update is because the default code in C++ doesn't actually read the data. It just sends pre-set values. There are some blocks of commented-out code in DashboardDataSender.cpp that if are un-commented and the code mirroring them is commented, it should properly update the dashboard