I’m started to get into understanding classes and objects for C#, hey how else would I spend my free time? After finally agreeing with myself that I understand the basics of classes and objects, I thought: how are classes and objects useful in VEX? I mean, they are very useful in software applications like games, websites, and other similar programs. Because it’s a software environment, you can track basically everything about a particular object during runtime. Now let’s look at VEX. It’s the real world. VEX sensors just simply cannot track every little detail of the environment. I tried wrapping my head around this idea of classes and objects in VEX, except the more I do, the less of a reason I see to even use classes and objects. So, my question is: is there any use of classes and objects in VEX?
I read up more about this and classes might not even be supported by RobotC… or maybe I’m looking at fake news… I need somebody to help me clear this out.
So examples of when it would be helpful
motor object
sensor object
mechanism object that takes in motors and sensors and controls them all together
Autonomous object containing a dozen Waypoint objects
OO is a very powerful tool BUT don’t forget any program that can be made with object orientated programming could have been made with out it.
Also yes ROBOTC isn’t C++ and doesn’t have objects, with PROS you can get full C++ to work and have fully object orientated design.
Some questions:
- Why would I need a motor object or sensor object? Isn’t that just what the pragma does (okay so maybe not exactly but it does the function of giving these things properties and info).
- What do you mean by “controls them all together”.
- What are waypoint objects and why are they useful.
- I primarily use PROS now, so how do I actually create c++ files? Do I just type in the file ending “.cpp” and not “.c”?
Thank you in advance.
So here is an example of a PROS C++ library that uses objects to help organize everything.
https://okapilib.github.io/OkapiLib/api/
made by @rbenasutti
-
You could have a PID loop that can take any sensor object regardless of what sensor it is. Inside that object could be the a minimum and maximum possible value and a function to zero the sensor, that worked on every sensor.
-
So you could say “chassis object move at 1 m/s” and it would handle all the motors and and sensors to make that happen. And other than the parameters to the object constructor you use no code would have to change. Logically an 8 motor chassis, 4 motor chassis, chassis with gyro, chassis with IME, chassis with encoder can all be controlled using the same high level “move at 1 m/s”.
-
It would be a clean way of defining the positions in the state space you expect your robot to get to. (state space being
lift location
mogo location
robot x,y,theta
intake state)
So instead of 1000 random movement commands you could say I have an autonomous object that contains 10 state objects I want to reach.
- No. Its complicated, you have to google it.
ROBOTC attempts to make a lot of their code work without needing objects but that doesn’t mean it isn’t useful at all.
OO is a very powerful tool BUT don’t forget any program that can be made with object orientated programming could have been made with out it.
For number three, the waypoint would be the object and you’d have a class called waypoint that has a bunch of variables like what you described in number three. Would you have the function countinueToNextWayPoint() in the class waypoint or would that just be somewhere else?
So the class autonomous would contain a list of waypoint objects and would be in charge of going from state to state, probably.
autonomous class
waypoint class
red tile with mogo intake up would be an instantiated object of waypoint class
get mogo and put 3 cones on it, return and score in 20 point zone would be an instantiated object of autonomous class
So your code at the top would just look like
MogoAuton.run()
Inside that run function would be
for waypoint in waypointList
goto(waypoint)
Or something. Its an organization technique. I am not going to tell you the right way to organize your tools in the toolbox, you can find something that feels natural.
Alright makes sense. Thank you for enlightening me with classes and objects (especially the waypoints idea).
Just bear in mind that the cortex has very limited memory resources when working with C++ and OOP.
The cortex isn’t all that small and C++ provides many no-overhead abstractions. I haven’t run into any problems with flash storage, RAM, or compute power when using my C++ library .
While RobotC isn’t object oriented you can get similar functionality that I would call “object based” using structs and function pointers. This is probably more complicated than many high school programmers want to deal with, but I didn’t have a choice since I started programming just before C++ became commercially available.
strings can get messy and some stdlib functions dont work. I agree that for 80% of what you want to do its not a problem but its easy to get lost in code and forget you are working on an embedded system. I mean the cortex is a pretty under powered system, pretty sure an Arduino Uno has more memory and higher clock speed.
The specs for the Arduino Uno are here: https://store.arduino.cc/usa/arduino-uno-rev3
The specs for the Cortex are here: VEX ARM® Cortex®-based Microcontroller - VEX Robotics
So not quite.
How do strings get messy? What stdlib functions don’t work? These things were not part of what I said, so I don’t know what you mean. This might be the part where we have to accept that C++ isn’t officially supported right now.