Does having a standard drivetrain with an inertial sensor (vs without one) help to keep the robot straight when driving forward programmatically? In other words, does the brain somehow leverage the sensor to maintain constant heading?
No, that is functionality roboteers need to implement
2 Likes
Drivetrain feature as of today uses the internal feedback for turns only, not for compensating for “straight” movements.
9 Likes
does the drive train feature when using the inertial sensor for turning use any sort of PID? or is it just base level turning? @tfriez
It is a simple P loop.
If you need advanced/better turning, then you will need to write that code yourself.
3 Likes
Does that imply in the future it may take inertial sensor feedback into account?
That’s not something we have discussed.
We could try and make the drivetrain class smarter, however, there are a couple of issues.
It’s very hard to make a generic class that works for all robots, driving straight and turning PID code needs tuning for a specific build, even now with our very simple internal control, it’s more successful with some designs than others.
I should not be writing the code for the students, we give them something basic that works ok for trainer robots in the classroom, but the students should be creating the code that gives their competition robot an advantage over others.
12 Likes
Definitely a lot of gray area here. Vex is now providing a GPS device which provides positional information previously only obtained by teams writing / using odometry, which was a clear competitive advantage. Is “driving straight” something that gives a competitive edge? Today, that seems to be the case. It’s also clearly frustrating to new teams that their robot doesn’t, in fact, drive straight. Does this frustration lead them to discover concepts like control theory and PID? Yes. Does it turn away some, especially those who assume “robot” means “always perfectly reliable”? Yes.
8 Likes
yea, I don’t know the answer.
When VEX introduced the IME for the 393 motor, RobotC added a feature to enable PID for motors. This is something I said in a post back in 2013.
The built in PID really does not replace what competition teams have been using in the past. I believe it’s more for classroom use where students were frustrated with simple robots that wouldn’t drive in a straight line.
There had been lots of complaints that robots would not drive straight in a classroom setting, the issue was primarily that left and right motors on the drivetrain were operating in an open loop fashion and not running at a commanded speed. The PID control in RobotC allowed the motors to run at a given velocity and used the IME as feedback to allow this.
All V5 motors already have this capability built in, so theoretically the robot should drive straight. If it doesn’t then I would initially look for all the known mechanical issues that could cause this before wanting to rely on a software solution.
The point I’m trying to make relates to my earlier comment about creating generic code to try and solve this. That code is only going to be able to do so much to compensate for low build quality, friction in the drive etc. and the robot probably still will not drive straight.
10 Likes
One way to improve the situation, without doing all the work for the students, would be to provide an easy to see and understand diagnostic information.
For example, there could be a UI widget that, in conjunction with drivetrain object, could plot on the same graph the velocity (or cumulative travel distance) of the left side vs the right side of the drivetrain.
Ideally, VEX wouldn’t have to write all those widgets but provide a framework where more experienced students could write and share snippets and widgets that could be plugged in even by less advanced programmers.
Then students could see one side of the drivetrain lagging and start thinking about what they could do to improve the straightness of the drivetrain.
I would love to see the drivetrain object having a plugin point for left/right side power balance/correction that would call an empty function by default. Then students could provide their own callback function that gives those corrections based on the gyro or other sensor readings.
6 Likes
I definitely agree that the VexCode tools could use better debugging/telemetry support. RobotC did a great job of allowing one to see data from the robot to the computer, and V5 has been a step back in this regard, IMO
I don’t know much about it other than what I’ve seen on the internet, but the FRC/FTC tooling looks light-years better than what is currently available in the Vex world. Not sure what would be involved (ROS-support, etc.), but being able to plug into Gazebo would be amazing. Being able to bridge the gap from VexVR to a physical robot would be incredibly helpful to programmers as well, as I’ve observed 90% of the time is spent building a robot and then 10% on programming (the night before the competition), usually because the robot isn’t ready to be programmed until then.
2 Likes
One of the many advantages of running a custom virtual machine instead of native code.
There was a plan originally for dashboards to be available in Vex Coding Studio, as we know VCS had some issues, and the original implementation in vexos was, shall we say, not exactly well thought out.
At this stage there would be some not insignificant amount of firmware needed to make sensor/motor data available over the USB link. My preference would be to use the USB serial port that’s dedicated to the user code rather than the admin port that used for program download etc. The user side cpu actually maintains far more state information about the attached sensors and motors than the vexos side cpu that deals primarily with device messaging, the UI etc. There are actually (disabled) remnants of a comms protocol I was planning to use way back when the project started still in vexos, perhaps one day we can resurrect that for some basic data logging.
The drivetrain class is extremely simple, it maintains a motor group for left and right side motors, a class member function such as drive() simply sends the required velocity to left and right group which in turn send to each motor that’s part of the group. It’s as simple as this.
void
drivetrain::drive( directionType dir ) {
lm.spin( dir );
rm.spin( dir );
}
where lm and rm are references to the left and right groups.
The smartdrive class which uses the inertial or gyro sensor for turns, is just a sub class of drivetrain with additional functionality to use those sensors.
Recreating a more advanced version of drivetrain is not complex, it only accesses motors and sensors using existing C++ classes. In fact, the Python version of the drivetrain is actually written in Python, no access to the VEX SDK is needed.
A few years back, when the forum was not so focused on memes, members would often share useful code that they had written that others may benefit from. I was hoping the same would happen with V5, it never has. I was hoping for nice libraries full of UI widgets and perhaps a much better drivetrain class. But I guess those days are gone, either members were more skilled back then or there really is just no interest from the current crop of students and mentors.
So there’s the challenge for the forum, write a better drivetrain class and share it with everyone.
8 Likes
I have something along these lines in the works. Need to complete some testing before publishing
6 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.