Get RAM and CPU usage in the roboRIO

[Alex Spataru]

For the moment, we have almost finished the DS library. We were able to move our robot without any issues, further testing regarding the joystick buttons and POVs will be done Monday.

I think that the only missing features in the library would be to get the RAM and CPU usage of the roboRIO (as the official Driver Station does).

In my opinion, this could be done by reading some files in the /dev/ folder over a SSH or FTP connection with the roboRIO, does anyone have any other idea or knowledge in this area?

[Tom Clark]

https://github.com/WinT-3794/QDriverStation/blob/master/lib/LibDS/src/Receiver.cpp#L72

Starting at data.at (8) there should be tagged data from the robot containing things like CPU and RAM usage. This is my understanding for how you would read it. I have no idea how QT networking works, so this is kind of pseudo-code, and as usual it's not really well tested.

socket.seek(8); // Assume you've already read the first 8 bytes

while (socket.has_more()) {
    // Each section consists of a size byte, a tag byte, and a variable
    // length piece of data.
    byte size = socket.next_byte();
    byte tag = socket.next_byte();

    if (tag == 5) {
        // CPU usage data
        uint8_t count = socket.next_byte();
        for (int i = 0; i < count; i++) {
            float normal       = socket.next_float();
            float timedstructs = socket.next_float();
            float timecritical = socket.next_float();
            float isr          = socket.next_float();

            report_cpu_usage(normal, timedstructs, timecritical, isr);
        }
    } else if (tag == 6) {
        // RAM usage data
        uint32_t free               = socket.next_int();
        uint32_t largest_free_block = socket.next_int();

        report_ram_usage(free, largest_free_block);
    } else {
        // Unknown, skip the rest of the section
        socket.skip_bytes(size - 1);
    }
}

[Alex Spataru]

Thanks for the information! I did not know about this feature in the robot packets.
I will implement your code and test it tomorrow, hopefully it will work without any major changes.

[Jessica Creighton]

@ThomasJClark Where did you get that information on the structure of those packets? I knew the first float was the percentage itself, but I couldn't find any information on the other ones (and two of them were always 0 during my testing). Also, the first uint of the RAM packets is always 0 for me, with the 2nd uint being the number of free bytes (same with 0x04 Disk Usage packets)

@alex-spataru I thought about opening a new issue but I'll just say here, I've done quite a lot of work the past few months reverse engineering the 2015 protocol. I'm not sure how much you have implemented (I know you don't have what I call Side Channel packets), but you can find all my documentation here: https://github.com/jcreigh/FRCDriverStation/wiki

[Tom Clark]

@ThomasJClark Where did you get that information on the structure of those packets?

I, uh... may or may not have an early draft of proposed changes to the protocol from 2014. If I did have such a draft, I'm pretty sure I shouldn't post it online. I'm also pretty sure some stuff has changed since then, which might explain the 0 bytes.

[Alex Spataru]

@jcreigh Thank you very much for the information, it will be very useful to make the QDriverStation more complete. For the moment, the development version is able to do most things that the official FRC Driver Station does, but it still has many rough edges (e.g it has problems moving the robot with two joysticks, and code on DS->FMS is inexistent for the moment).

[Jessica Creighton]

@alex-spataru Certainly. If anything is unclear, just give me a ping. I don't have a ton of information on the FMS part either, since I can only base it on what packets captured during competitions.

@ThomasJClark ...Fair enough. Supposing you did have it, I guess you wouldn't email it to the address I have on my profile ;p

[Alex Spataru]

I'll close this issue since we'll be moving to another DS library with support for the 2020 comm. protocol.