VEX U

Thanks for the clarification. If I were in branding, I wouldn’t make it as confusing.

If you are a college team and trying to do complex programming, stop using VCS. It isn’t made for you.

I’d love to, but PROS will not stay installed on our campus lab computers. The environment path is set to install to the appdata folder which gets wiped every night. I don’t have a laptop to use, so we have to use VCS. Else, we have to wipe pros/atom from the computers and so a fresh install every time we want to use it. So far, our IT department has not been able to fix this issue.

Are you the team that wants MSIs?

If that would work, I’d love to try it!

And we are the team that brought this up at your last competition this past February.

Here’s some example code that shows use of the low level C API for sending and receiving on a V5 port that’s configured as a generic serial port. The ports are RS485, you will need to figure out the physical connection using a suitable adapter. There are other C functions beyond these few, look in the header files, they should be reasonably obvious how to use.

and no, you cannot communicate with a V5 smart device using this API.


using namespace vex;

int receiveTask() {
    // enable port 18 as generic serial port
    vexGenericSerialEnable( vex::PORT18, 0 );
    // change baud rate, default is 230k
    vexGenericSerialBaudrate( vex::PORT18, 115200 );
    // allow vexos to reconfigure the port
    // the port will remain as a generic serial port until the brain is power cycled
    this_thread::sleep_for(10);

    // buffer for rx data
    uint8_t rxbuf[256];

    int totalRead = 0;

    while(1) {
      // check to see if we have any bytes in the receive buffer
      int nRead = vexGenericSerialReceive( vex::PORT18, rxbuf, sizeof(rxbuf)  );
    
      // yes ? then display
      if( nRead > 0 ) {
        totalRead += nRead;
        Brain.Screen.setCursor( 4, 2 );
        Brain.Screen.print("Bytes received %d", totalRead );


        if( nRead > 16 )
          nRead = 16;
        Brain.Screen.setCursor( 5, 2 );
        Brain.Screen.clearLine();
        Brain.Screen.setCursor( 5, 2 );
        for(int i=0;i<nRead;i++)
          Brain.Screen.print("%02X ", rxbuf* );
      }
    
      // read often
      this_thread::sleep_for(5);
    }
  
    return(0);
}

int main() {
    int msgCount = 0;

    // start the rx thread
    vex::thread rxThread( receiveTask );

    // enable port 20 as generic serial port
    vexGenericSerialEnable( vex::PORT20, 0 );
    // change baud rate, default is 230k
    vexGenericSerialBaudrate( vex::PORT20, 115200 );
    // allow vexos to reconfigure the port
    // the port will remain as a generic serial port until the brain is power cycled
    this_thread::sleep_for(10);

    char msg] = "Hello World";
    int  msglen = strlen( msg );
  
    while(1) {
      // send message
      vexGenericSerialTransmit( vex::PORT20, (uint8_t *)msg, msglen  );
      // 
      Brain.Screen.setCursor( 3, 2 );
      Brain.Screen.print( "Number sent %d", msgCount++ );

      // Allow other tasks to run
      // send message every 100mS
      this_thread::sleep_for(100);
    }
}

you can also use standard C stdio API, this examples shows how to do that


#include <stdio.h>
#include "robot-config.h"
          
using namespace vex;

int main() {
    // IO using stdio
    //**********************
    FILE *fp1, *fp2;
    fp1 = fopen( "/dev/port20", "wb" );
    fp2 = fopen( "/dev/port18", "rb" );
    while(1) {
      if( fp1 != NULL ) {
        fprintf(fp1, "Hello\r\n");
        fflush(fp1);
      }
      if( fp2 != NULL ) {
        char buf[128];
        int nRead = fread( buf, 1, 128, fp2 );
        if( nRead > 0 ) {
          for(int i=0;i<nRead;i++) {
            printf("%02X ", buf*);
          }
          printf("\n");
        }
      }
    this_thread::sleep_for(10);
    }
}

In this case the characters I’m reading are sent using printf to the second serial port (that’s USB serial, the V5 USB shows as two serial ports on your computer, the first is dedicated to admin and program download, the second is for user code to use) that the V5 has, you would need a suitable terminal program to see the output (for example, on OSX I use screen )*

@jpearman Thank you so much! I will have to post a thread showing what we will do with this later this season.

Would it be an option to install PROS on a Raspberry PI connected to V5 via USB and remote login into RPi wirelessly?

I haven’t done that, so I don’t know if drivers to upload to V5 are available for Raspbian. But if it is possible than you could have all your dev environment on RPi and could use any laptop/desktop to remote login into it.

@tabor473 is that what you meant?

Yup.

On this robot

I had PROS installed on the onboard computer and it built and downloaded to the V5. This was all done in March using my Beta unit. (wasnt a raspi) (thats autonomous)

I know some people have been working on getting the same thing setup with a raspi. The important parts are pretty easy and straight forward, PROS CLI is all in python and just works on arm processors running linux.

So to download compiled binaries it “just works”. The tricky part is being able to build binaries. You have to compile the compiler tools on your device. My onboard computer was an Arm Processor like a raspi but it had enough system performance I was able to do the compilation necessary, the raspi fails after several hours of compiling. People have tried cross compiling for the raspi but that avenue has failed so far. If anyone is able to finish the compilation they can distribute it and no one will have an issue again.

So the current workflow is compile on main machine and copy over the binaries to raspi, download on raspi. ( which can all be easily automated)

For reference this is @sazrocks 's robot, a HS team’s that set this up for wireless downloading.

Do they have take off that raspi unit before matches?

Sure but matches are less than 1% of time you spend using a robot.

Yes, but it isn’t really useful for matches anyway. Its main advantage is in quickly developing and tuning autonomous routines. It’s also really easy to remove since it’s just held on by a rubber band.

Right, I was more concerned with how refs in my state would take it.

I actually think I can really work with that, and come up with a system for some of my teams for downloading wirelessly.

As a slightly more interesting approach, but still using an RPi, I’ve been working on the attached script that monkey patches pySerial allowing you to use all the standard pros commands from a host computer that then transmits serial requests over WiFi to a server running on the Pi. Because it pretends to be a serial device, things like uploading directly from a computer not the Pi work too (as well as serial terminal, etc.) :stuck_out_tongue:

(I’m going to properly have it up on git once it’s tested and has niceties added)

In short, Your PC->PROS(SerialBridge) ~~~~~ WiFi ~~~~~ SerialBridge->USB
SerialBridge.zip (3.25 KB)

1 Like

It really depends what your goal is if that is more interesting. Some people can’t install PROS on the host machine so be able to run all of pros on the Raspi could be helpful. Ya this is another possible method.
The 3 of us should probably start a thread where we explain all the current work on this subject.

yes, they have their API that calls the low level functions, have a look at the PROS documentation, it should be there.

@tabor473 How well does PROS run on a Raspberry Pi? If you have not tried that yet, I may look into that this weekend.

So as I stated before PROS CLI itself runs totally fine. PROS is built using industry standard tools so its probably best to break the discussion of what works up into each component. I will list them in order from robot to user.

USB drivers to talk with device
PROS CLI for downloading binary files, running terminal etc
GCC Toolchain for building PROS source code into binary
PROS atom plugin

Separately the PROS kernel and library files is part of PROS but isn’t pertinent to this discussion.

The USB drivers and PROS CLI work right out of the box on a Raspi. The GCC toolchain has had some work put into getting it to run raspi which has been so far unsuccessful. No one to the best of my knowledge has tried getting the PROS atom plugin to work but it is not necessary.