So a team I’ve been working with for the past few weeks has recently received their Vision Sensor and has started messing around with it. They wanted to be able to use the Vision Sensor to track distance from flags and use that distance to calculate the target RPM for a flywheel and use a custom control loop to get the motors to that target RPM.
After a little bit of playing around with the sensor, it was realized that PROS does not yet have functionality for color codes, only object signatures themselves. This led them to look back to VCS, but then it was also quickly realized that because VCS for some reason only lets you control motor velocity instead of just motor power, which uses the motor’s internal PID which is not accurate enough for the loop we’d like to create. We’ve tested out the optimal control loop in PROS (which does let you set raw motor power) and it works perfectly.
The problem here is that VCS doesn’t let us have our control loop, and PROS does not let us detect color codes. I can understand the argument for PROS since it isn’t developed by VEX itself, but for VCS to not even have the option of setting raw power even in C++ Pro is rather ridiculous. Is there any way to work around this in either program? Also, are there any plans (that anyone knows of) for either PROS to roll out color code functionality or for VCS to let us set raw power for a motor? If there’s something simple that I’m missing here, please feel free to point it out. Thanks!
VCS will have open loop control of the motors in the next release, we chose not to expose that in the C++ API for V1.0.
PROS may be able to use color codes. A color code uses signatures that are setup in a particular way but the vision sensor reports a color code object in the same way as a single color object. I’ll have a look if there’s time this week.
As @jpearman just mentioned, PROS should just play nicely with color codes. You can set them with the VCS Utility or the bundled vision sensor utility from VEX. I don’t personally deal with exposing functionality within the vision sensor, but I can forward this onto the correct people. What functionality are you expecting PROS to have that it doesn’t currently have? I’ll see what the PROS team can to do to get it included in a future release.
The way vex utility works that I can see is that you set signatures but color codes are based on that code and are not stored on the vision sensor. When I use vcs to set the color code it doesn’t carry over to if I made a new vcs program or if I used pros
Color codes are a special combination of signatures.
A signature will have an identifying number that ranges from 1 through 7. A color code is a combination of two or more signatures but the type of the signatures that the Vision sensor includes in the color code has to be set so it treated as a color code. So color codes are effectively stored in the vision sensor (as well as the VCS program) and should be able to be used by PROS.
yes, I understand, but if a color code is returned by the vision sensor that, for example, is the code for signatures 1 & 2 as a combination, the id returned will be 0x0A (color code is returned using 3 bits per color, so signature 12 becomes 001 010 in binary). I would expect PROS to return an object with id 0x0A for that combination, it’s just been a while since I tested their API and I would need to check to be certain.
This is where my not having a Vision Sensor myself makes my understanding a little hazy, but here goes. I understand what you’re saying, but my issue isn’t at all with the id returned by the vision sensor in regards to which code it is identified, my issue is with setting the color code itself. You have to set the code in order for the Vision Sensor to be able to detect it, right? I don’t have a Vision Sensor myself, but @Steve1442 (the team I was working with that does have it) from testing it has told me that the color codes that the Vision Utility creates are only stored within the file it was used in, not within the Vision Sensor itself. He was able to remedy this by using
vex::vision::code
in other VCS files to manually create codes, but in PROS there is no such thing available, therefore he is not able to create a designated color code. The specific id of a color code doesn’t matter if the sensor can’t even return color codes because they were never able to be defined in the first place. Unless the color code is indeed stored within the Vision Sensor (which doesn’t seem to be the case from testing), the code must be defined programatically before the sensor can identify that code, which is possible in VCS but not in PROS.
tl;dr How can the vision sensor even return a color code with a certain ID if you can’t even define that color code in the first place?
Ok, I’ll check tomorrow.
My recollection is that we store everything in the vision sensor still. We may change that in the future but for now I though we had left it alone.
We do also store everything in VCS, the idea there is that in a classroom environment students may not be using the same vision sensor for each class and that their program should have all necessary information to configure the sensor.
If everything is stored in the vision sensor then that solves everything, at least as long as it stays that way or until PROS supports manual definitions for color codes. Thank you for checking, hope to get to the bottom of this soon haha
@jpearman Thank you for the workaround in order to set motor voltage directly in VCS, it’s extremely helpful for now until the next VCS update rolls around. Any update in terms of whether or not the Vision Sensor stores everything?
It does, but it looks like the PROS team will have to add some additional functionality to use it.
We will also probably have an updated vision sensor utility for the PROS team next week that will help a little with color codes. Because the vision sensor utility was primarily for use with VCS, we have found that launching it as a standalone application will tend to delete any stored color codes, we cannot completely solve that, but it will at least leave anything currently saved as a color code on the vision sensor alone.
PROS Kernel Version 3.1.4 is out, and addresses a number of the concerns on this thread. It adds the following updates:
New Features:
Vision Sensor Signature Read/Write, you can now configure signatures in your PROS project (though the existing method of saving signatures through the Vision Utility still works)
Vision Sensor Color Code functionality, you can now configure color codes for the sensor (this must be done programmatically, not through the Vision Utility) and filter objects by their color code with the get_by_code() and read_by_code() functions Usability Impovements:
The errno values for Vision Sensor object retrieval functions are now more clear.
Upgrade your projects by running prosv5 c u in the project directory.