Xmera Known Issues#

Version 2.3.0#

  • A bug was introduced at 2.2.1 (2dc0a35) to the SimulationBaseClass AddModelToTask function when it was refactored to use the updated module variable logging. The bug manifests as no data being logged for a variable when there are more than one task, a module in each task, and the variable being logged is from a module assigned to a task added to a process after the first task has been added to a process.

  • Doing a clean build on Windows appeared to complete, but when running python simulation scripts, errors came up about not finding Xmera packages. The python version number checking on Windows had an issue that is now corrected in the current build.

  • swig 4.2 was causing run-time errors with Xmera. The latest version of Xmera now added support for this version of swig.

  • Xmera no longer builds on Windows with the opNav flag turned on. The opencv related conan settings are updated in the current release to address this.

Version 2.2.1#

  • There was an issue with thrusterStateEffector where if there are multiple instances of the thruster state effector then the last effector will over-write all the state of the earlier thrusters. This is corrected in the current release.

  • Doing a clean Xmera build with opNav flag on fails building openCV. The conan install script is updated this is corrected in the current release.

  • We found a slow memory leak if messages with arrays or vectors were accessed from python. The swig issue has now been fixed in the current release.

  • The facetSRPDynamicEffector module was double counting a cosine term in the SRP force calculation. This is corrected in the current release.

  • The facetDragDynamicEffector module was missing a negative sign in the drag torque calculation. This is corrected in the current release.

Version 2.2.0#

  • VizInterface has been updated to use 4.5.0 version of ZMQ library. Be sure to use Vizard 2.1.5 or newer.

Version 2.1.7#

  • The way to include effector bodies in Vizard has changed in this release.

  • The streaming between vizInterface and Vizard was not reliable because of a ZMQ compatibility issue between the two code bases. xmera is reverting to using ZMQ 4.3.0 for now to avoid this issue.

  • Building Xmera with opNav mode was no longer working as a conan package dependency issue came up. This has been corrected in the new version by specifying xz_utils/5.4.0 in conanfile.py. Note that building with opNav now also appears to require conan>=1.59.0, but less than 2.0.0.

Version 2.1.6#

  • in boreAngCalc, the variable boreVecPoint is now called boreVec_Po.

Version 2.1.5#

  • In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

  • hingedRigidBodyStateEffector and dualHingedRigidBodyStateEffector module inertial state outputs are relative to the central gravity body, not the inertial frame. This is now corrected.

  • Adding an instrument camera to vizInterface has changed. See vizardSettings on how to use the new method addCamMsgToModule().

Version 2.1.4#

  • In Xcode, when editing vizInterface.c/h files, the protobuffer library is not properly found when opNav is included. The code compiles, but auto-completion etc. doesn’t work in that module.

  • prior version had a bug in computer the latitude in PCPF2LLA() inside geodeticConversion. This is used in the specifyLocationPCPF() method inside groundLocation, and in msisAtmosphere and albedo.

  • coarseSunSensor now receives in sensorList a list of CSS configuration state pointers, not a copy to the configuration structures. This allows these values to be changed on the fly from within python. However, the simulation code must ensure that the CSS configuration structures are retained in memory or a segmentation fault will ensue.

  • How stand alone C-wrapped message objects are created in python has moved from cMsgCInterfacePy to messaging. Old scripts still using cMsgCInterfacePy still work as a link has been created to messaging. But, the use of cMsgCInterfacePy is no depreciated and code should be updated to using messaging instead.

  • The use of custom message in the external modules folders is broke with the new build modification in this release. This is fixed in the latest release.