@gftabor If you're interested, this is what I've been up to.
I would like a way to visualize where the balls are (especially if they're in goals) without looking at gazebo to debug setModels.py and getModels.py. I am expecting it to be a image similar to a top 2d view of the game with circles for the balls, and a box for each goal to list what is in each goal (if anything). This will display all of the objects published in getModels.py. I was also thinking about having a 2d robot image that can move around with controller input (same as gazebo just less 3d and computationally intense). And as the robot moves around, it will automatically move balls into the intake and outake them when near a goal. Then, when the simulation of this is reasonable, the same logic can be applied to gazebo with 3d poses rather than 3d. The simulation will also be adequately simple enough for an AI to train on (when we have that working). This will essentially kill two birds with one stone.
I am thinking of using python to do this with a library like pygame. And just making colored boxes and circles be the field. It will subscribe to /gazebo/get_field which is published in getModels.py and will (eventually) publish to /gazebo/set_field which is defined in setModels.py. The idea with both of those files is to have a third file get from one and figure out what should happen based off of the robot driving program (whether ai or not) and set the models accordingly. This is made easy because all the information needed is published in /gazebo/get_field so that the logic can take place in a different file / node. Note that the actual driver may be in a different file than displayModels.py to avoid overcrowding of files.
I have officially decided that when I can, I am going to write these files in cpp, because I have much more expirence in it. This will make it much less frustrating for me.
@gftabor If you're interested, this is what I've been up to.
I would like a way to visualize where the balls are (especially if they're in goals) without looking at gazebo to debug
setModels.pyandgetModels.py. I am expecting it to be a image similar to a top 2d view of the game with circles for the balls, and a box for each goal to list what is in each goal (if anything). This will display all of the objects published ingetModels.py. I was also thinking about having a 2d robot image that can move around with controller input (same as gazebo just less 3d and computationally intense). And as the robot moves around, it will automatically move balls into the intake and outake them when near a goal. Then, when the simulation of this is reasonable, the same logic can be applied to gazebo with 3d poses rather than 3d. The simulation will also be adequately simple enough for an AI to train on (when we have that working). This will essentially kill two birds with one stone.I am thinking of using python to do this with a library like pygame. And just making colored boxes and circles be the field. It will subscribe to /gazebo/get_field which is published in
getModels.pyand will (eventually) publish to /gazebo/set_field which is defined insetModels.py. The idea with both of those files is to have a third file get from one and figure out what should happen based off of the robot driving program (whether ai or not) and set the models accordingly. This is made easy because all the information needed is published in /gazebo/get_field so that the logic can take place in a different file / node. Note that the actual driver may be in a different file thandisplayModels.pyto avoid overcrowding of files.