Yeah geez, this thread really blew up overnight. Couple of points I think are worth reiterating:
We donât know how good this sensor is yet. It could be good enough to be a drop-in replacement for encoder/IMU-based odom. It could be good enough for most teams but the best teams will stick with their existing odometry systems, or combine the two. It could even be terrible (though I think thatâs unlikely). In any case, we wonât know how good it is until teams get it and start playing with it.
This sensor does not give you a better autonomous routine for free. It tells you where your robot is on the field, you have to decide how to use that information to get your robot from A to B. Getting good at that will still require a lot of practice and experimentation and learning.
This sensor is only useful if events are required to have the field code on all their fields, and there has been no announcement yet about whether that will happen. Iâm all for it personally, but it is one more thing for EPs, refs, and field resetters to worry about before and during the event â installing it correctly, making sure it stays in place, keeping the perimeter square to the tiles, etc.
And on the topic of âraising the floor without raising the ceilingâ, my view is, give teams more advanced functionality and let them take care of raising the ceiling as they find cool stuff to do with it.
It wasnât that long ago that implementing odometry cost 5225A âthousands of hours of time and most of their sanityâ and was a major contributor to them winning a world championship. That work, and the documentation they released about it, paved the way for other teams to implement the system, and now a few seasons later, odom is practically a requirement for any team that wants to be competitive at the highest levels. The ceiling rises naturally as the best teams get better and better.
I will say that as a professional software engineer, one of our constant decision points is: âBuy versus Buildâ.
Often times we find that there are existing solutions that provide 80-90% of what we want, some stuff we donât care about, and some stuff we wish they would have done differently. Do we invest the time âre-inventing the wheelâ (but gaining full control over the software), or do we use the labor of others to reduce the time-to-market. Is the functionality something âcoreâ to who we are? Do we think we can implement it âbetterâ than the existing solution? If we build it âbetterâ does that give us a competitive advantage?
When @jpearman requests prior year code submissions, and I see so many teams that use PROS and write their own PID/Odomentry/etc. I wonder what led them to decide not to use Okapilib (and whether that was even an active decision).
I know my opinion may be outside of the Vex mainline (and Iâm not an educator), but I donât see much value in re-implementing the wheel, when it comes to software. Do I think teams should take a crack at writing their own PID or odometry? Sure. Itâs a relatively simple concept that can teach some basic coding skills, and maybe allow them to apply what theyâve learned in math. Their implementation is likely going to have problems (straight up errors in math/logic) and probably wonât incorporate good software design practices. Without seeing better code, I think many roboteers wonât even know that there ARE better ways to program.
As a member of a team who spent a month and a half last season writing code for odometry and motion algorithms from scratch, I am excited to see this new sensor.
I donât think Iâll ever understand why some people balk at innovation, and I donât feel as though my work last season has been somehow invalidated by a new sensor. This sensor gives an opportunity for new and experienced teams to simulate encoder tracking in a more streamlined way (which you can already do, by the way, just use Okapi and plug in your numbers).
@Sylvie the main point youâve made is that three-wheel odometry is possible without understanding or applying trigonometry, This is valid.
@Connor the main point youâve made is that this sensor decreases learning by making three-wheel odometry irrelevant. However, consider the percentage of vex teams which used three-wheel odometry in their lifespan. 1%, perhaps 2% of teams have ever used odometry. Did you, Connor, during your time in vex, build a robot which utilized three-wheel odometry?
Anyway, with the implementation of this sensor and the corresponding field setup, the percentage of teams which use some form of odometry will likely increase tenfold. Is it really so bad for more teams to use odometry?
I agree with the many who think this is a really cool piece of functionality, and are looking forward to seeing how well it works.
I suspect the accuracy will be surprisingly good. I also expect that there will be some amount of lag in the data. Remember, the sensor has to do a fair amount of work to get a position fix:
Take a picture of the field
Isolate the field strip from the picture
Identify the position marking within the field strip
Run mathematical transforms to calculate the position of the robot on the field
Based on the fact that the sensor is relatively small and has a modest power budget, I am going to guess there will be a short, but not-trivial lag between capturing the image and returning an accurate fix. This lag can likely be ignored for a robot moving slowly, but will probably become an issue for a robot moving quickly.
As a result of this, motion profiling will become even more important for teams trying to move quickly in autonomous.
Also as others have mentioned, it is only useful if fields are correctly configured with the field strips.
I expect this will enable more advanced autonomous routines going forward. I also expect it to introduce new challenges for the more advanced teams.
In science and engineering, we are all standing on the shoulders of giants. None of us is developing things from scratch.
This new sensor should let many teams reach higher than before. More teams will be able to do position tracking, raising the bar for everyone. At the same time, I am sure we will have the top teams integrating this to reach levels never before seen in VEX. I look forward to seeing what they develop.
Taran, to be honest, you should be the last one talking about whether odometry is useful. You used time-based code.
That being said, I agree with Taran here. The GPS sensor gives you what looking at Pilonsâ documentation for 3 days wouldâve given you but more accurately. This allows teams to focus on more complex movement algorithms, which essentially raises the ceiling of the competition. There is a lot more learning to be had if the positioning was already given to the competitors. Sure, teams wonât HAVE to use encoders, but this doesnât mean that they donât have to use calculus or trigonometry or other âreal-life skills.â Movement algorithms require just as much, if not more, of these skills, with the only difference being that you have to actually make them yourself instead of copying what Pilons and hundreds of others have done for years.
My only problem with this is the $200 price tag and the lack of information about whether tournaments will be required to have the strips on their fields.
I know itâs already been brought up, but are we 100% sure itâs going to be legal? Sure, the website says itâs legal, but are VEX going to supply everyone with the $40 strips? Or is that more money weâre shelling out on top of a $200 sensor?
This might just be me being blind (and apologies if I am), but is there any documentation for the sensor? The only thing I see on the website is setting up the field strips. How does it work? With 3 other robots, and all the game objects, wonât the sensor be obstructed a good part of the time?
I feel like VEX kinda dropped the ball with the release of this sensor. I get thereâs a game manual update coming next week, but I feel that they should have either a) delayed the announcement to co-inside with the manual update or b) release a separate mini-update regarding this sensor specifically at the same time of the announcement.
Also of potential interest, as referenced in the AI Status Report from Change Up:
While it seems Vex wants this other (e.g. non-GPS) new sensor to be able to do robot detection, itâs not there yet. So, this GPS sensor may broadcast out the location of this robot to all other robots on the field. That would also potentially lead to interesting decisions / options with the new âNeutral Zoneâ area of the auton. Do you use this sensor and benefit, while also potentially giving away your location to the opposing alliance?
I would suspect (but again, no confirmation of this yet) that robot location broadcasting will be required in VAIC (where every robot will have to have the GPS sensor anyway) but not in normal VRC play.
Definitely a possibility, and, given the game formats, likely the ârightâ decision.
That said, that would require Vexâs code (not the teamâs code) running on the brain to know what type of competition (VexAI, VRC, etc.) the match was playing and either share or not share that data accordingly.
It could also be interesting if teams using this sensor in LRT matches would broadcast their position to the other teamâs robot.
Maybe Iâm looking too deep for interesting trade-offs in VRC, lately!
âVexâs code knowing what type of competition is being playedâ could just be as simple as a function call in user code to tell vexOS that the robot is playing a VAIC match (so it should broadcast the robotâs position), and VAIC events just have to confirm at inspection that every robot does that.
I donât think we know anything yet about robot position broadcasting in VAIC other than that it will be a thing â we donât know if the GPS sensors will talk directly to each other or if the info will go over VEXnet/VEX Link, if there will need to be some sort of âhandshakeâ between the robots in each match before it starts, etc.
We donât actually, we have some time based delays for running into the goal, but for turns and long movements across the field we use custom-made PID controllers with the inertial sensor, and the built-in motor encoders in the V5.
Regardless, Iâm not our teamâs programmer. I take care of the designing and building. Iâm more than capable of writing odometery algorithms (because I have).
I think you will find that our autonomous is more than consistent enough
Please use a correct set of facts before lobbing insults.
This actually counters that side of the argument. The foundation of this side of the argument is that odometry is easy and outdated so itâs okay to move on. If only a very small percentage of people have learned it then the argument is null. There is a lot more to learn from odometry right now and this sensor completely destroys the incentive to research odometry. Heck maybe the sensor works terribly, but to a rookie team looking at options, theyâre gonna see a GPS tracking system and a odometry system. One that supposedly keeps track of the bots position by itself, the other requiring trigonometry and calculus to calculate the position, on top of the fact that you have to design in and build the tracking wheel system.
Which do you think will be chosen, even if the sensor isnât as good as advertised it is still discouraging teams from researching other tracking and positioning options.
The best engineers can make anything out of nothing and thatâs what vex was meant to teach, to give us the bare minimum and see the amazing things we can create with that. But if they start giving us the tools to cut corners it will stunt our growth as engineers and hurt us in the long run, that is the ultimate concern.
Honestly, if someone is not confident enough to make simple odometry algorithms from scratch, how are they going to be confident enough to take the gps sensor input and then ramp up to motion algorithms? This sensor is not going to affect many teams, only the developing teams that already were planning on shifting to odometry already. The best will sit with their tested odometry, algorithms, and quality robots unless the sensor is crazy good and then they will calmly apply their motion algorithms to the new sensor with probably an extra 8 lines of code. This should not affect elite teams at all.
My team will not have the funding for this sensor. Does this make us at a disadvantage? I donât know yet. Time will tell. What I can say, is that with no pneumatics this year and now a sensor we canât afford, its looking like it.
RTFM
Only Appendix D specifies Field Position Code Strip and opaque field panels. Unless youâre competing in VAIC the VEX GPS sensor will do nothing for you aside from burn a $200 hole in your pocket and look pretty.
This is not the fear, the fear is giving rookie teams a false sense of skill because theyâre given training wheels. Allowing them to compete with teams that are far more advanced.