Topics

RIAPS Platform v1.1.17 Release Notes

Gabor Karsai
 

THIS RELEASE IS A BREAKING CHANGE!  Meaning that you must update both the VM and BBBs to the same version.  New VMs and BBB images are available on the download page.  No update scripts are available for this platform release since the location of the third-party installed libraries has changed to a new location (no longer RIAPS specific).  You MUST replace your VM with this new platform release.  Save your current work to software repositories to allow easy access and re-establishment from the new VM (information is available below to help guide with this transition).

 

The RIAPS platform consists of 3 packages now:  riaps-core, riaps-pycom and riaps-timesync

 

IMPORTANT CHANGE TO BBB IMAGE:  The BBB image is now a basic platform prepared image.  It includes the needed third-party packages already installed and the environment configurations available for the RIAPS platform.  It DOES NOT INCLUDE the RIAPS platform pre-installed.  Once you copy this image to an SD card, the RIAPS Platform must be installed using the following script on each BBB:  riaps_install_bbb.sh.  The BBBs need to have access to the network during this installation step.  If you have multiple BBBs, you can update one BBB with the RIAPS packages and then copy that SD card to the other BBBs.  Instructions for transferring the SD card image to a location on a VM or a local Linux machine can be found here, then use balenaEtcher to write that image to the other SD cards.

 

Project Impact Notes: 

1)      Any projects using C++ components must be update their CMakeLists.txt file to reflect the third-party library changes.  The riaps-apps/apps-vu examples have been updated with new CMakeLists.txt files which will work on the v1.1.17 RIAPS platform and later.  There is also a CMakeLists_v1_1_16.txt file in these projects to allow the project to still work in v1.1.16 or older RIAPS platforms.  To use this file in the older platforms, replace the CMakeLists.txt with the CMakeLists_v1_1_16.txt file.  To see how these files changed, go to this pull request.

2)      Exception handling has been strengthened in the component to provide better feedback when a system fails.  It is advised to make sure your Python projects include try/except handling around any REQUEST ports to provide logging messages when a port error occurs (this generally happens at the start of an application and will recover through retries).  An example of how to improve your code can be found in the updates to the DistributedEstimator code that was committed with this release.

 

 

================================================================================================

V1.1.17 Release Notes

================================================================================================

Features:

  • Removing riaps-externals and expectation of RIAPS libraries/includes in /opt/riaps/. Installs are now in /usr/local/ or for cross compilation on the VM in /usr/arm-linux-gnueabihf.
  • Moved riaps-externals to the base VM and BBB creation scripts.
  • Removing riaps-systemd package, consolidated into riaps-pycom.
  • Utilize installed pybind11, instead of local version in riaps-core.
  • Any user changed RIAPS files now stored in /etc/riaps and then softlinked to /usr/local/riaps.
  • Update fabfile to incorporate key file references from /etc/riaps and other functions effected.

Bug Fixes:

  • More comments, minor refactorings in riaps-core.
  • This is an initial commit for making RIAPS work in a mininet environment, both for the platform developers and application developers. See mn/README.md for instructions on how to use it.
  • Pass component exceptions up to deplo to be printed - Component exceptions are currently buffered in stderr, and don't get printed alongside their proximal logging statements. This change formats them and passes them up to be printed immediately.
  • Update yaml.load due to PyYAML package update (3.12 --> 5.1.1).
  • Includes fix for paramiko security concern.
  • Updated creation and installation documentation to current platform.

 

Suggestions for Transferring Eclipse Workspaces to a new VM

 

There are several ways to transfer your project work between VM.  Perhaps the easiest is to keep your code in a code repository (such as SVN or GIT) and then create a new workspace from the retrieval of the code from the repository. 

 

Another way would be to use Eclipse to export an archive file that can be moved to a transfer site (such as Dropbox or any other file sharing tool).  And then import that file into a new VM eclipse workspace.  Here are some tips for doing this:

1)      In the old VM, choose “File” à “Export” from the drop-down menus and select the “General – Archive Files” option.

 

 

2)      Select all the files you want to include in the archive.  You can unselect compiled files or even use the “Filter Types” tool to help with this.  Indicate the file name and location to place this archive (“To archive file:” box).

 

3)      Copy the file to a transfer site (such as Dropbox) and then retrieve it on the new VM.

4)      On the new VM, choose “File” à “Import” from the drop-down menus and select the “General – Existing Projects into Workspace” option.

 

5)      “Select the archive file” option and find the transferred file.

 

6)      This should have the workspace back in place in the new VM.

 

Kindest regards,

Mary Metelko  |  System Architect

Institute for Software Integrated Systems

Vanderbilt University

1025 16th Avenue South, Nashville, TN 37212

Ph:  615-875-8008

Web:    http://www.isis.vanderbilt.edu/