Closed Andyj4586 closed 1 year ago
Next observation: You should probably locate all the WheelBot models in WheelBot subdirectory. As it stands now, they will get mixed in with anything else that goes into the models directory. Also, the path to the include directory should be in the TRICK_CFLAGS and TRICK_CXXFLAGS. That will eliminate the need for relative paths in your code. (e.g. models/Vehicle/src/vehicleOne.cpp).
Do we have permission from the Trick team to reuse this model in TrickHLA? I don't expect it to be an issue but we should ask before including their models in TrickHLA.
I got it to build! ;-)
I may need some help with running it appropriately.
Question: Did you have to make any changes to either the 'Graphics' or the 'GUIControl1' Java interfaces?
Observation: There is no RUN_test directory in the WheelBot sim directory.
Did you intend to include an empty
sims/SpaceFOM/SIM_wheelbot/.zshrc file?
Have you merged against TrickHLA master and then tried running the code? I'm seeing evidence in the input.py files that it has not been run against the latest in master because an older API is used in the input file. You need to make the following changes in your input file since the function needs to take a number representing seconds: FROM: federate.set_least_common_time_step( 250000 ) TO: federate.set_least_common_time_step( 0.250 )
Who owns the copyright for the images your simulation uses? Did you create these images or did you get them from somewhere else? If from somewhere else, does the copyright allow you to redistribute the images. Does an attribution need to be included for the source of the images?
The filenames should match the capitalization of the class names. For example, models/Vehicle/include/vehicleOne.hh should have a filename of VehicleOne.hh and so on for the other source code files.
Follow the coding style of the TrickHLA code: 1) Class names are capitalized and the filename needs to match the class name including capitalization. 2) Function names use underscores between words and no camel case. FROM: getCurrentDestination() TO: get_current_destination() 3) Variable names also use underscores between words and do not use camel case. 4) Constants and enumeration values are all capitalized with underscores between words.
I got it to build! ;-)
I may need some help with running it appropriately.
I updated the instructions for running it in the README.md file in the SIM_Wheelbot directory. But I'm happy to help clarify anything if that doesn't clarify things.
Question: Did you have to make any changes to either the 'Graphics' or the 'GUIControl1' Java interfaces?
I modified the 'Graphics' Java interface so that if the user is running RUN_mouse, the images at the waypoints stop being drawn when the waypoint is reached. Did not make changes to the 'GUIControl1' interface.
Have you merged against TrickHLA master and then tried running the code? I'm seeing evidence in the input.py files that it has not been run against the latest in master because an older API is used in the input file. You need to make the following changes in your input file since the function needs to take a number representing seconds: FROM: federate.set_least_common_time_step( 250000 ) TO: federate.set_least_common_time_step( 0.250 )
I had not done that. I will incorporate this change into the appropriate input files. Thank you!
Did you intend to include an empty sims/SpaceFOM/SIM_wheelbot/.zshrc file?
No, I will get that removed.
Just to capture my comment from the meeting today. You should only use the XY of the PhysicalEntity class state attribute for position (translational_state) and for heading compute the attitude (rotational_state). The rotational_state is a quaternion so it may take a little investigation to work up the appropriate transformation. You should be able to find that in one of the Appendices of the SpaceFOM standard itself.
Do we have permission from the Trick team to reuse this model in TrickHLA? I don't expect it to be an issue but we should ask before including their models in TrickHLA.
I reached out to Sean H. and confirmed it is alright to use the models/images from the Trick SIM_Wheelbot in TrickHLA.
This looks good. I was able to build and run the simulations. A couple of observations:
• You might want to make 'localhost' as the default RTI host location. The JSC-ER systems are limited access. • You might want to start the two dependent WheelBot sims in freeze without SimControl panels. Just let the Master simulation mode the federation execution. See the RUN_pacer and RUN_RRFP input files as examples. • There seems to be some kind of performance issue with the JAVA displays. I see exactly the same stuttering behavior that was in your movies. I don't think it is a computer loading issue. • If you are adventurous, you can use the run the 'format_code.py' script on your source code to make sure that it complies with the TrickHLA formatting standards. './format_code.py --help' will give you the options.
Once you are done with your changes to WheelBot, I'll merge it into a new working branch off of the TrickHLA GitHub repo so we can Dan and I can take a closer look. Then we will merge it into the 'master' branch.
Good work!
I think I am finished making changes. If you find anything you want me to fix or update, I am working until Friday, 8/4. Removing the additional sim control panels seems to have fixed the lag we were seeing in the Java displays. Thanks for all the feedback!
That's great! I'm in the middle of a coding mess with PhysicalEntity. Once I get that resolved, I'll take a look at this and get it committed into a WheelBot branch in TrickHLA.
Very interested in this example- I am getting started with SpaceFOM and it is nice to see a SpaceFOM example with a simulation.
I am running trick-CP in the SIM_wheelbot directory and I get this error:
Error Could not find included file "Vehicle/include/VehicleOne.hh"
makefile:111: build/Makefile_swig: No such file or directory
make: *** [makefile:44: S_source.hh] Error 255
The Vehicle directory doesn't seem to be found. @Andyj4586
@simtheverse , just a word of caution here. This is a pull request that we have not fully vetted yet. At first I thought that this may be an issue associated with not having pulled the latest. I was able to build SIM_Wheelbot without an issue. However, upon further investigation, it appears to be an issue with having been developed on a Mac. The missing file is there but with a different case. Change the include path in models/Vehicle/src/vehicleOne.cpp to vehicleOne.hh. Note the different case.
We will work to get this pull request into an actual TrickHLA branch and eventually merge it in to master. Unfortunately, both Dan and I are wrapped up in other tasks and vacations. Thanks for pointing this out. We will get it fixed in the merge.
Thanks. I am running it in a CentOS Stream 8 linux container and cloned Andyj4586:intern_projects today. I updated the include path with no noticeable effect. I played with the include path in the S_define and it looks like that is what's throwing the error. Even changing the case in S_define, I got the same error. Below just shows putting in a dummy include path in the S_defines and it gives the same error with the dummy path.
Continuing S_define
Error Could not find included file "this is in the S_define/include/vehicleOne.hh"
makefile:111: build/Makefile_swig: No such file or directory
make: *** [makefile:44: S_source.hh] Error 255
For reference I can use trick-CP on the SIM_sine and SIM_Roles_Test/_Sync without any problems. I realize I am here pretty early though so no worries on my end. Looking forward to the merge to a branch, and I will be happy to help with any testing before merge to main.
Actually, your error messages are different. It looks like the S_define also needs the same fix.
I suspect that issue permeates the new code. Andrew changed the file name convention to match the TrickHLA naming convention and probably missed a few others in the process.
We would appreciate the help in testing when we get the new branch committed. Thanks.
Thanks again. Perhaps its out of the scope for this example but something I have been hoping to see in particular is how to set the PhysicalEntity's body reference frame relative to a frame in the reference frame tree, and do the translations between different reference frames in the tree. (If I am understanding what I am reading) I think when the wheelbot_hla_entity gets made in the input.py it doesn't set any reference frame for itself or need to translate a reference frame.
This has now been pulled into the 'wheelbot' branch within the TricHLA repo. We still need to clean it up to merge it into 'master'.
@simtheverse , From the SpaceFOM perspective, the PhysicalEntity parent reference frame is nothing more than a name string. However, there is a SpaceFOM requirement that the parent reference frame 'must' match exactly a frame in the SpaceFOM reference frame tree. In general, you should always check that a parent frame on anything actually exists.
I am currently in the process of creating some new ReferenceFrames, PhysicalEntity, and DynamicalEntity examples in the 'jeod_examples' branch. The 'jeod_examples' branch is most definitely a work in progress. I have also started an example ReferenceFrame tree in that branch.
I am going through the WheelBot sim now. I am going to put a collection of my findings as comments. My first finding is that you have a relative path set in the S_define to Trick files. If you set the TRICK_HOME, you should not have to do that. When I changed "../../../../trick/share/trick/sim_objects/default_trick_sys.sm" to just "sim_objects/default_trick_sys.sm" it gets past that error. The relative path will only work if the person has Trick in the same relative location that you do; which, is unlikely.