Customizable Dashboard

[slavik262]

Don't like the look of the LabVIEW dashboard? Frustrated with dashboard examples not working how you want? Confused on how to pack packets for the provided dashboard? Want to customize the dashboard to better fit your needs and strategy or show more relevant information without having to mess around with the LabVIEW one?

I'm developing my own dashboard software that I plan to release to all FIRST teams once I have a stable beta out. My goal is to have it out in a few weeks from now in time for the last third of build season or so. Current features include:


Written in C++ with optional DirectX support. That means it runs fast, and it runs with a small footprint on your computer.

Customization made easy. For those of you who have ever worked with Microsoft Publisher, Visual Studio, or any other drag-and-drop designer, imagine this: Select a control type. Drag it onto your screen. Move it, resize it, and drag it just like you might with an image or text box in Word or Publisher. Set properties like appearance and behaviors. Then just drag and drop the control's data source onto a visual representation of the packet to tell the control where in incoming packets to get its data from.

A plethora of built-in controls. Meters, gauges, on/off lights, numeric printouts, video feed (using the webcam), direction indicators, battery power meters, and the list continues. Everything you see on the LabVIEW dashboard and a little more. Each control will have multiple appearances the user can select from, and while they will come with default color values, all colors in any control will be changeable by the user.

Fast swap. Want multiple dashboards, such as one for debugging and one for competition? Every dashboard you make can be saved to a file and loaded back, settings and all.

Fullscreen mode for maximum readability.

Full networking support. The dashboard receives data exactly like the official LabVIEW one. You don't have to change a thing in your robot code.

Full video support from the provided webcam system. Again, no changes to your robot code. Additionally, you can add controls over the top of the video with transparent backgrounds to act as overlays and show data such as a distance readout provided by an ultrasonic sensor.


I'm wondering how many teams out there would be interested in something like this, and what additional features they want to see. Feedback is greatly appreciated.

[Randy Forgaard]

Fantastic! We would LOVE to use your C++ custom configurable Dashboard. We are trying to stay in C++ for all of our FRC coding. We had been thinking we would try and dive in and do a C++ port ourselves, but we weren't sure how hard that would be, and from your description, it sounds time-consuming indeed.

Anyway, we'll watch for your C++ customizable Dashboard. Will you post it here to Chief Delphi? Wish we could have it earlier than the last third of build season, but we know how long software takes, and our team greatly appreciates your efforts!

[Greg McKaskle]

If you have any questions about the LV one, or if we can help in any way, feel free to ask, PM or otherwise.

Greg McKaskle

[slavik262]

I'll be sure to. Your support is greatly appreciated.

Let me clarify to everyone that while this is being written in C++, it is completely independant of robot code. It will work with a robot running in LabVIEW, C++, or Java, since they all communicate to the dashboard in the same way.

Again, I'm wide open for any additional features you guys want. This is for the FIRST community, not just my team, and I want to meet the needs all of you have.

[TheDominis]

I'll be sure to. Your support is greatly appreciated.

Let me clarify to everyone that while this is being written in C++, it is completely independant of robot code. It will work with a robot running in LabVIEW, C++, or Java, since they all communicate to the dashboard in the same way.

Again, I'm wide open for any additional features you guys want. This is for the FIRST community, not just my team, and I want to meet the needs all of you have.

Can it write my robot code for me?

[slavik262]

Yes, but it will involve lots of printf() calls and not too much movement.:rolleyes:

[TheDominis]

Yes, but it will involve lots of printf() calls and not too much movement.:rolleyes:

I like it.

On a more serious note, are you in a design or beta phase?

[slavik262]

I like it.

On a more serious note, are you in a design or beta phase?

Design. I know where I want to go with it and I'm pumping out code as fast as I can, but it's not in a usable state right now. As soon as more of it comes together, expect some screenshots.

[TheDominis]

Design. I know where I want to go with it and I'm pumping out code as fast as I can, but it's not in a usable state right now. As soon as more of it comes together, expect some screenshots.

Awesome. I am also going to be working on a new camera class and video server and a dashboard to display the video. Should all be up by tomorrow. However, the dashboard won't be in C++ to increase development time (obviously).

[bronxbomber92]

Something like this would be amazing. I find it very frustrating that if I want to use the dashboard I'm forced to use LabView if I want to customize the dashboard or understand how it works.

Keep it up! :-)

[Nadav Zingerman]

Open source?

[slavik262]

Open source?

As soon as the source is somewhat stable and commented, of course.

[joshholat]

I'd definitely check it out!

[a kenny03]

how close are you to completion?

[mtndurbin]

Any updates on the C++ dashboard?
Need a beta site?
Source available yet?

[slavik262]

The designer mode is 90% done. Features that are done and working

Change any color on any control, along with all other properties of the control in a fully working properties bar.
Snap-to-alignment control movement (if a control is within a few pixels of being lined up with another, it will snap into alignment and a line is drawn between the two controls to show you that they are aligned. This system works just like the one in Visual Studio, if you've ever used it).
Ability to multi-select controls and move them all at once.
Holding shift while resizing locks the aspect ratio of the control.


I still have to:

Add a menu for the designer.
Add a few scroll bars.
Save/load ability. All properties of each control are already stored in structs. All I have to do is iterate through all controls on the form and save the structs to a file (and do the opposite for loading).
Create my UI element that binds each control to a part of the packet.
Use these bindings to update the controls during run mode.


Right now the only implemented control is a meter. However, I'm using an Object-oriented design, and most of the code for the meter is common to all controls and is contained in a base class from which all the other controls can be derived.

Would you guys like some screenshots and the code I have so far?

[Stimpy1901]

Would you guys like some screenshots and the code I have so far?

Yes, please! Thanks!

[Kingofl337]

This should be great!

[slavik262]

I'll get some screenshots out in a day or two when I have a bit more to show you.

[Radical Pi]

Awesome! I'll be giving this thing a spin as soon as I can!

On a secondary note, are you planning any functionality to process data inputs before being displayed? Our current dashboard needs a bit of calculation before it can be displayed on the classmate and I wouldn't want to tie up processing time on the cRIO

[slavik262]

On a secondary note, are you planning any functionality to process data inputs before being displayed? Our current dashboard needs a bit of calculation before it can be displayed on the classmate and I wouldn't want to tie up processing time on the cRIO

Explain what you mean by "process data" please.

[Tanner]

Explain what you mean by "process data" please.

Think he means that he needs to put the data from the robot through a few functions to get the results he needs and he'd rather not do that on the cRIO.

Not sure if doing it on a netbook is a better choice though.

-Tanner

[slavik262]

As of right now, the dashboard won't do any processing on the data. It will feed what it gets from the network packets straight into the controls. However, the meter for example, is not bound to a range of 0 to 1. You can set your own minimum and maximum values. That way, you don't have to do any scaling cRIO side.

[slavik262]

Both me (and the project) are still alive. I haven't posted because I've been so busy getting things done. ;) Our robotics team is going to get some major hours in this weekend. Expect a big update then.

[davidthefat]

If I were you, do it in OpenGL for multiplatforming

[EthanMiller]

Looking forward to it!

[slavik262]

If I were you, do it in OpenGL for multiplatforming

I can switch renderers with a single line of code, but all my networking functionality is using the Windows Socket Library, so the first few releases at least will be Windows only.

[TheDominis]

You could use boost's socket library.

[slavik262]

You could use boost's socket library.

After the initial release I'll go back and do all the cool stuff like multiplatforming. Right now I'm just focusing on getting it out to you guys before the competitions.

[slavik262]

http://img121.imageshack.us/img121/7754/dashss.png (http://img121.imageshack.us/i/dashss.png/)

Like what you see?

Features to note:

Auto-alignment: Notice how the selected control (on the left) has lines being drawn to all controls that line up to it (top bottom, and center. The sides also line up if there are controls above or below it). When you get within a few pixels of being aligned with another control, your selected control instantly snaps into place
Control options: See all the options in the "Properties" bar? You can change every single one, for every single control. They're saved in your dashboard file so that when you load up and run your dashboard, everything is just how you want it.
Packet data bar: While not complete yet, notice the "Packet Data" bar at the bottom? Add and remove controls as much as you want. Change where they get their data in the packets from the robot. Unlike other dashboards you've seen floating around on Chief Delphi, you can change around your dashboard without ever touching the dashboard source. Just drag and drop your controls onto the screen, and drag and drop their data sources into the "User Data Byte" bar. Yes, the data sources will be labeled soon.
High performance: See the number in the upper left-hand corner? That's how many times per second the controls are being drawn. Granted, I'm cheating by running this on my gaming PC, but welcome to the power of C++ and hardware rendering via DirectX or OpenGL (you choose). What does this mean to you? A fast running editor, and an even faster running display when you switch to display mode (which, by the way, is in full screen). No need to worry about frameworks slowing you down on low-end PCs and laptops.


As you can see, I still have a bit to go, but I thought I'd give you guys a sneak peek for being so patient. I promise you all that this will be well worth the wait. ;)

[Huskie65]

Wow this is lookin great. Can't wait to see final product!

[misko]

This sounds like good stuff. Does anyone know if FIRST will allow this to be used during a competition? Or are we going to be required to use their drive station/dashboard infrastructure?

[slavik262]

You can use whatever dashboard you want, provided that you don't change how the robot sends data to the dashboard. That's why the FIRST Driver Station software has a "remote dashboard" option.

[slavik262]

This weekend I did a lot more work on it. You can now save and load the entire dashboard, including control properties, names, locations, and packet data offsets (in short, everything). The packet data toolbar at the bottom is completely done, letting you drag and drop data sources straight into the packet bar.

I'm not putting up screenshots because the system doesn't look any different from when I last posted some, but the things you saw before work now :D

Both of the things I finished this weekend are big steps towards this project losing vaporware status. All I have left to do is make the actual run/display mode where the dashboard interacts with the robot. This will be developed a lot faster than the other components due to the lack of user interaction.

[~Cory~]

I would be very happy to help to port a version to linux...

[Robototes2412]

SO would I

[slavik262]

I have the dashboard running, fullscreen, and went today to test the networking side of it, only to find out that FIRST has changed the network protocol around, making my white paper on the protocol (http://www.chiefdelphi.com/media/papers/2330) completely useless.

If anyone has newer documentation on the dashboard packet, the sooner I get it, the sooner I can get this out.

[Vikesrock]

If anyone has newer documentation on the dashboard packet, the sooner I get it, the sooner I can get this out.

Not sure when the packet changed or when this info was compiled, but this might help you:

http://www.chiefdelphi.com/forums/showthread.php?t=83667&highlight=dashboard

[EHaskins]

Not sure when the packet changed or when this info was compiled, but this might help you:

http://www.chiefdelphi.com/forums/showthread.php?t=83667&highlight=dashboard

That information should be accurate as of now. If you have any issues with it let me know.

I assume the following code is what you're looking for, but if you need information on the structure of the default data packets I can help with that as well.

(C#)

public void Parse(byte[] userData)
{
using (var stream = new MemoryStream(userData))
using (var reader = new MiscUtil.IO.EndianBinaryReader(new MiscUtil.Conversion.BigEndianBitConverter(), stream))
{
var packetNumber = reader.ReadByte();

var highDataLength = reader.ReadInt32();
var highData = reader.ReadBytes(highDataLength);
if (highDataLength > 0)
StatusData.Update(highData);

var errorString = reader.ReadFrcString(); //ReadFrcString is an extension method which

var lowDataLength = reader.ReadInt32();
var lowData = reader.ReadBytes(lowDataLength);
if (lowDataLength > 0)
ioData.Update(lowData);
}
}

public static string ReadFrcString(this EndianBinaryReader reader)
{
int length = reader.ReadInt32();
if (length < 0 || length > (reader.BaseStream.Length - reader.BaseStream.Position))
return string.Empty;
byte[] bytes = reader.ReadBytes(length);
return System.Text.Encoding.ASCII.GetString(bytes);
}

[slavik262]

Not sure when the packet changed or when this info was compiled, but this might help you:

http://www.chiefdelphi.com/forums/showthread.php?t=83667&highlight=dashboard

This is what I was looking for. Thanks Vikesrock for finding it and Eric for making it. I was going off the old format which has a key differences that was causing problems
(There used to be dedicated space for error and user strings before the user data).

My net code should just require a few tweaks. Expect an initial release in a few days. :D

[CardcaptorRLH85]

I'm going to hazard a guess that this won't be ready for week 1 events (this Weekend) Just wondering since I'm heading to Kettering University in about an hour to setup the field and all so, my time to integrate a new dashboard into our robots program will be quite limited until the competition actually starts.

[slavik262]

I'm going to hazard a guess that this won't be ready for week 1 events (this Weekend) Just wondering since I'm heading to Kettering University in about an hour to setup the field and all so, my time to integrate a new dashboard into our robots program will be quite limited until the competition actually starts.

Probably not. I'm really sorry to those of you who were hoping to use it then. The initial release (with just the meter control) should be out by Saturday *knock on wood* with subsequent controls following shortly thereafter. For those of you who just want video, a full-screen video dashboard is also currently in production (since I would use all the same code to incorporate a video display into this dashboard project anyways).

[slavik262]

The initial release is finished. It's 1:30 AM on Saturday here, so I'm going to get some sleep now. Tomorrow (well, technically today, but after I get some sleep) I'll put together some basic documentation (a basic instruction guide, known bugs, planned improvements, etc.) and throw the dashboard and the dox on this thread for you guys to check out. :D

Please be understanding with this release and think of it as an early beta. It's feature-complete, but there's a few minor things missing (keyboard shortcuts, prompts to save if you've made changes to the dashboard before closing the window, etc.). Rest assured, these features will be added very quickly. My goal here is to give you guys something concrete that you can start to play with in anticipation of the more finished project, instead of making you wait with nothing while I finish things.

[EHaskins]

The initial release is finished. It's 1:30 AM on Saturday here, so I'm going to get some sleep now. Tomorrow (well, technically today, but after I get some sleep) I'll put together some basic documentation (a basic instruction guide, known bugs, planned improvements, etc.) and throw the dashboard and the dox on this thread for you guys to check out. :D

I'd be nice if you had it posted before 10am, so I can test it when I have access to our control system tomorrow.

[slavik262]

The dashboard is live!

As you can see, the difference between this dashboard and other dashboards released such as ZomB is that this is a complete package requiring no other software. You make your dashboard in the program, and you run your dashboard in the program. Simple, and no need for Visual Studio or other development tools.

Using it is simple. To create meter controls (the only type implemented so far - more to come soon), click on the meter button on the toolbar then just click, hold, and drag meters into existence (click where you want a corner of the meter to be, drag to where the other corner should be, and release. The meter will pop into being). Make sure you click the meter button again when you're done creating meters, switching the cursor back to multi-select mode (drag a box around controls to select them). You can also select multiple controls by holding the Control key and clicking the other controls. Holding shift while dragging a corner of a control will cause it to keep its current aspect ratio.

Once you've created your controls, tell them where to get data from. In the Packet Data bar at the bottom of the screen will appear a box for each control you've created. Hovering over each box will tell you the name of the control it belongs to (if this doesn't work at first, just click in the Packet Data bar to give it focus). Drag the box into the "User Data Byte Number" line to tell the control where in the packet to get its data from. Each space represents a byte, and since a float (the data type the meter control takes) is 4 bytes, it is 4 spaces wide. The box will turn green to indicate you have successfully placed it in the packet. At the current time you cannot have multiple controls receive data from the same byte(s) - this will cause the box to turn red until it has enough space for itself.

In your robot code, simply use the high-priority packer to pack the packet with the data in the same order you laid out in the dashboard.

Hit the green run arrow. If you have not saved your dashboard yet, you will be prompted to do so (the dashboard must be saved to run). The display mode will automatically start up, displaying your dashboard in fullscreen. To exit display mode, simply hit Alt-F4 and you will return to edit mode.

I realize that right now there's only one control type (the Meter), but rest assured, more will quickly follow. Think of this as a demo. Feel free to provide suggestions, and together we can keep making this system better and better.

If you have any further questions, please read the text documents included with the program. If you still have questions, post them here, PM me, or email me at slavik262@gmail.com

Enjoy!

[byteit101]

When I run it, the mouse flickers, CPU usage goes up to nearly 100%, and it is a bit slow (it claims the frame rate is 3-9FPS)
what data do you send from the robot side?
GetDashbaordDataPacker()->AddI32(55)?

is there a way to not have full screen dashboard? the set resolution fails

[slavik262]

When I run it, the mouse flickers, CPU usage goes up to nearly 100%, and it is a bit slow (it claims the frame rate is 3-9FPS)
what data do you send from the robot side?
GetDashbaordDataPacker()->AddI32(55)?

is there a way to not have full screen dashboard? the set resolution fails

Are you running it on the Classmate? I haven't tested it yet on the Classmate - and the combination of a lack of discrete graphics hardware and slow processor might cause that low of FPS. If you'd read the planned updates, I'm going to release a configuration utility that lets you specify what renderer you want to use. It's possible the software renderer might help you. Also, if you had the window minimized our out of focus and bring it back up, the FPS will shoot down for just a few seconds. This isn't because the FPS actually decreased, but because the program sleeps to conserve processor usage when it's not the selected window and the FPS counter averages FPS over the last few seconds. Therefore, when you bring the window back up, it averages the 0 FPS it had while sleeping with whatever the current FPS which causes the drop.

What we're doing is using a separate laptop to run the dashboard and connecting it to the Classmate using a USB to Ethernet adapter. It works quite well, and you have the added benefit of not just a faster computer, but a larger screen so your drivers don't have to view the dashboard in Squint-O-Vision. On a fairly standard laptop that our team bought for programming, we got 90 fps on average.

The CPU is pegged not because of a problem, but because the dashboard runs as fast as possible. I can have it sleep in the render loop if it's that huge of an issue, but it shouldn't be. Remember that this isn't an event-based system, but a real-time render loop. If you're worried about running other programs while you're designing the dashboard, don't worry as the dashboard sleeps and uses almost no processor when its window isn't selected.

Could you please explain what you mean by "The set resolution fails?" In the edit menu, you can set the resolution to whatever you want. While at first I was going to limit options to the possible resolutions of the computer the dashboard is running on, I decided to let the user set it to whatever they wanted in case they wanted to design a dashboard on one computer and run it on a different one. When you run the dashboard, it checks if the computer supports the desired resolution, and if it doesn't, returns to edit mode after displaying an error message.

On the robot side, you use the high-priority packer to pack the dashboard with floats (as I stated in my previous post).

[TheDominis]

I ran this on my MacBook (w/ Win7) and my FPS was ~130 until I added controls when it dropped to ~80 at 5 controls and ~60 at 13 controls. When displaying properties with 13 controls the FPS is ~60 +/- ~10.

I tried to resize from 1280x800 to 800x600, but the resolution did not change; however, it did remove some components.

[byteit101]

Are you running it on the Classmate?
no, my desktop w/ 2GB Memory, 2GHz Intel Processor, and XP. I ran it, with no controls, in design mode, for about 1 minute, and that was the (approximate) average FPS.

Could you please explain what you mean by "The set resolution fails?"

When you run the dashboard, it checks if the computer supports the desired resolution, and if it doesn't, returns to edit mode after displaying an error message.

It's displaying this message for all but the native (1440x900) and 800x600 It's also resizing all the windows to 800x600 when in that mode

[slavik262]

I'm not sure what's going on with the fullscreen mode. I'll take a look at the code as soon as I get home.

Byteit - I have no idea what could be causing FPS to drop so low. Could you give me more details as to what you were doing when it happened?

A note on FPS - the entire system is texture-based (since this it runs on a graphics engine after all). The arrows on the Numeric Up/Down controls are textures, the text in the controls are textures, etc. I sped up performance by making each of the labels in the Properties windows solid textures, but that's sill a lot of texture changes (I ran some diagnostics and I think there's like 90 textures in the properties window). Now for those of you who know anything about graphics processing, switching textures, meshes, and shaders is expensive for the graphics card. So having the properties window open will cause the FPS to drop.

Also, adding controls not only adds the need to draw the controls themselves, but the data source boxes, etc. Just know that display-mode performance will be much higher than your edit performance - even by a factor of 2 or 3 according to initial tests.

While I obviously want designer mode to run fast, I care much less about optimizing the designer mode than the display mode, since during a match you'll be looking at the display, not editing it. :p

[bronxbomber92]

You should be able to get a performance boost by switching to power-of-two textures. Also, I'm not very familiar with Irrlicht, but you should make sure the quads are not being drawn in immediate-mode, and instead thrown into VBOs (or at the very least, vanilla vertex arrays).

[slavik262]

You should be able to get a performance boost by switching to power-of-two textures. Also, I'm not very familiar with Irrlicht, but you should make sure the quads are not being drawn in immediate-mode, and instead thrown into VBOs (or at the very least, vanilla vertex arrays).

I'm already using power of two textures for almost everything :)
As for VBOs, I'm using their built-in 2-D rendering mode, which is in the process of being switched over to VBOs (I think in the next update). The video system, which I'm working on right now, will use VBOs. :D

[Robototes2412]

Can I have the source code so I can attempt to port it to Linux?

[slavik262]

I'll have a source release in a day or two after I comment it a little bit.

[Robototes2412]

ok, thanks

[slavik262]

I found some more bugs (they'll be fixed by the time you read this).

Changing stuff around in the Packet Data area didn't register as a change - as such these changes wouldn't be saved when you ran the dashboard.
Upon loading a dashboard file, names would get some bonus characters because I forgot the null terminator. :o
Deleting a control with data in the packet would not remove the control's data rectangle, causing the program to crash if you clicked on it.


I'm looking into the issues with different resolutions now. Also, for planned updates, I also plan on highlighting the data rectangle of selected controls in some way.

[byteit101]

Byteit - I have no idea what could be causing FPS to drop so low. Could you give me more details as to what you were doing when it happened?

running it!
no controls, just running the exe, and looking at the FPS!

[slavik262]

running it!
no controls, just running the exe, and looking at the FPS!

I'll keep an eye out for whatever could be causing this. Is anyone else experiencing that low of FPS?

[slavik262]

I'm working on the video control next, which will also come out as a stand-alone program (like TheDominis's C# one). I had a few issues with the networking, but thanks to TheDominis, things should be smoothed out now.

My team is playing at the Wisconsin regional this weekend and I'll just be working on the dashboard all competition, so expect some further progress by Sunday.

[jhersh]

I'll have a source release in a day or two after I comment it a little bit.

You should definitely request a project on firstforge.wpi.edu for this. It would be a great place for everyone to look for file releases, source code, report bugs, etc. Way easier that using a forum for all of that.

-Joe

[slavik262]

I'll be sure to do so.

This weekend was the Milwaukee competition - the following things happened:


I got video working perfectly. It's in a stand-alone program now, but integrating it with the rest of the dashboard should be a piece of cake. Wait until you guys see it. :D
I have a second release ready for you guys. It has bug fixes for all the problems I'm aware of along with a new control type - a static text label. The "T" button next to the meter button actually does something now. Options include horizontal and vertical centering, setting text and background color, and optionally drawing the background.
I found out that the FMS locks out your robot if it detects two laptops are on the same subnet (i.e. 10.5.37.x). This doesn't present a problem for dashboard data, but causes video to require a forwarding program on the classmate. I know there's a few of these floating around in .NET and Java, but I plan on making a simple one in C++ using Winsock for maximum speed.


I haven't gotten anything out since because I've been playing catch-up for my calculus class, and school comes before robotics, but expect some stuff within the week. I'll definitely work on getting a FIRST Forge project page and getting the source out to you guys too.

Oh, and here's a sneak-preview of the video dashboard: :p

http://img517.imageshack.us/img517/6294/connectings.png

[CardcaptorRLH85]

Nice work so far ^_^ even though my teams 2 competitions this year are done (unless our point total can get us into the Michigan State Championship *fingers crossed ^_^*), I can probably still use this for next years bot. Thanks for taking the time to do this.

[slavik262]

I applied for a project on FIRSTForge a day and a half ago and still have no response. Should I try again or wait some more?

[slavik262]

The dashboard, now known as CARDS (Charger Advanced Robotics Dashboard System), is live on FIRSTForge. Expect the source and latest builds to be uploaded today or tomorrow.

[CardcaptorRLH85]

The dashboard, now known as CARDS (Charger Advanced Robotics Dashboard System), is live on FIRSTForge. Expect the source and latest builds to be uploaded today or tomorrow.

I don't see it there unless I'm just missing something. Could you give us a link or if I am just overlooking it could someone help me out ^_^ Thanks!

[slavik262]

Expect the latest builds to be uploaded by tonight. I'm just going to put the project and binaries in some self-extracting archives and upload them to the files section. What I'd really like though is to get the source up on an SVN repository. Does anybody know any free online services that let you host one?

Also, once the source is up, I'm completely open to any help with the project. The more people we have writing code, the faster CARDS can get added functionality and the faster it can be useful to teams out there. Let me know in a PM or email if you're interested in helping - all that's required is some basic C++ and Object-Oriented Design skills.

Our team has our next regional April 8, so that's my target date to have a solid release. Things I want done by then:

Dashboard system with the following controls: meters (done), labels (done), and printouts (just text that prints out a float value from the robot). More to follow.
Video feed: stand-alone program (done) and integrated into the rest of the dashboard.
Video forwarding system (currently in development - about halfway done): Routes the TCP stream from one network (a robot-Classmate network) to another (a Classmate-Dashboard Laptop network) thanks to FIRST never mentioning that having multiple laptops on your 10.xx.yy network causes your entire robot to lose comms, making it a tiny bit difficult running video on a different laptop. I'm aware other programs like this exist, but I want a lightweight one done in native Winsock for maximum speed.

[Bharat Nain]

It would be nice to have a "fully loaded" version with video and a "light" version without. I have a feeling that a project like this will go a long way...

[slavik262]

The initial release packages for both the dashboard and my video system are out. Packages include the programs themselves, required resources, and the source for each. They can be located here:

http://firstforge.wpi.edu/sf/frs/do/viewSummary/projects.cards/frs

This release should be much more useful to everyone due to the fact that the bugs that made the last one somewhat unusable have been fixed. :D

[slavik262]

FIRST Forge seems to be down, but I just wanted to give you guys a quick update:

The forwarding program (so that you can run video on a second laptop at competitions) is almost completely finished. There's a couple of bugs I have to work out, but expect an initial release this weekend.

[slavik262]

FIRST Forge is back up. Feel free to continue downloading the dashboard and video components. The forwarder will be up soon.

[slavik262]

The forwarder is done (enough for its first public release anyways). In about five minutes from when I type this I'm heading off to the North Star regional today. I'll try to put it up if I can get internet access at the hotel. If anyone wants to check the forwarder and video system out, find me (Matt Kline) in the Team 537 pit and I'll be happy to set you up with it and any of my other software.

[slavik262]

Both the forwarder and a launchpad program that ensures that the Driver Station starts a single instance of your dashboard are released and available on the CARDS FIRST Forge site (http://firstforge.wpi.edu/sf/projects/cards).

[slavik262]

Hi everyone. Sorry for not posting anything in a week - I've been badly sick. The forwarder and the video display system underwent a trial by fire in Minneapolis, so I have some new versions for you guys that I'll put up later today.

Changes to the forwarder include some changes to the networking sockets so that data flows through it more smoothly.

Changes to the display include a lot of optimizations to make it run faster and with less overhead on a low-end system like the Classmate.

[slavik262]

Sorry for the delay, but new versions of both the video system and the forwarder are up for download on FIRST Forge:

http://firstforge.wpi.edu/sf/frs/do/viewSummary/projects.cards/frs

Both have been battle-tested at the North Star regional and run extremely smoothly on the Classmate (or any other laptop you care to run them on).

I realize that I haven't made as much progress with the main CARDS dashboard as I'd hoped, but that's mostly due to the fact that I've been busy improving the video system. Our team decided that active video feedback was much more important to our drivers than other sensory data, so that's been my focus during the two regionals we've attended.

Team 537 will be at nationals in the Curie division. I'd love anybody else who's going to Atlanta to stop by our pits and have a chat with me about any of the CARDS products. CARDS has always been and will always be about more than just Team 537 so it would be great to hear from any of you who will be there. Talking to you guys really helps me meet your needs and make needed changes to the programs. The end of this competition season will certainly not mark the end of the development of CARDS - it will continue into the off-season and hopefully next year we can see a lot more teams using it! It's crazy to see how far it has come already. I'm really excited to watch this project mature.

[BigJ]

I know the UPS control systems group has talked about this since it got linked to our email list and I want to look more at it this off-season when we have access to the cRIO. Sounds like good stuff from our friends slightly to the northwest :)

[slavik262]

Live from nationals, it's

CARDS Video Version 0.3!

http://firstforge.wpi.edu/sf/projects/cards

Changes:

Added options to configuration program that allows users to select a renderer. Choices include DirectX9, DirectX8, and OpenGL.
Fixed settings loader to work in Windows 2000 and XP (version 0.2 only supported Vista and 7)
Fixed bug that caused user replacements of Connecting.png and StandBy.png to not display if they had 24 bit color depth instead of 32 bit color depth.
Fixed error displaying Connecting.png and StandBy.png after receiving video with a smaller resolution than 640 x 480


Download:
http://firstforge.wpi.edu/sf/frs/do/downloadFile/projects.cards/frs.cards_video_system_releases.v_0_3/frs1120?dl=1

[Tim Skloss]

Does your dashboard support sending feedback commands to controllers (xbox, ps3, gaming joysticks)? We really wanted to give our drivers force feedback in the controllers this year but couldn't make it work. In Atlanta I talked with the NI guys and they said the only way to make force feedback work was to create your own dashboard where you can insert direct-x commands to send feedback signals to the controllers.

Have you tried this?

Many teams could this feature as useful as--if not better than--video.

[slavik262]

That's a really cool idea. I'll play around with DirectInput and add it as a control.

Right now I'm drowning in AP Calculus prep (the test is next Wednesday), so I haven't done a lot of work on the dashboard. I'll pick it back up soon after.