Define release acceptance tests

[Bckempa]

While full automated acceptance testing is under development, we need a minimum equipment list of tests (automated or manual) that must pass for a release to be tagged. Presumably these will be defined per component.

[EzraBrooks]

document what we considered essential in October, then go from there

[quarkytale]

Currently, there is only manual testing, where I ensure the robots (mars_rover and canadaram) are responding to control inputs. A better way, in my mind, is a gtest setup/integration test which will spawn the gzserver, apply a world force and validate the motion using positions of the model, see this for reference. I'm not sure how or if it'll work with the ROS framework here. But I can certainly start looking into it from this direction.

[ivanperez-keera]

@quarkytale Are any of the ros packages installed currently as part of the build process of the spaceros docker image running any of the static analyzers included by default with spaceros as part of their test suite?

Would it make sense to have a minimal demo app, which could be based on a hello world for ros, that only exercises the features we provide?

I'm trying to think of how to accomplish a small, incremental step that provides some value but is also so small that we'll have very little risk of not being able to complete it if the next release development period is busy at our respective jobs.

EDIT: Note.

[quarkytale]

Are any of the ros packages installed currently as part of the build process of the spaceros docker image running any of the static analyzers included by default with spaceros as part of their test suite?

I'm not sure about that will check and get back to you.

As per discussion during the technical meeting, the first action item for the next milestone is to have a test or a CI job checking all the demos are running, robots are spawning etc. No need to test Gazebo integration.

[ivanperez-keera]

The following is what I did to complete this work during the January release:

Identify release name. For all the commands below, it is imperative that the right branch/tag be identified.

• Remove all Space-ros related images (should not be necessary but I wanted to be sure I was building everything correctly).
• Build basic space-ros image following instructions in https://github.com/space-ros/docker/tree/main/spaceros.
• Boot into image, run basic commands such as ros2, ikos, just to check that they are installed.
• Build moveit2 image following instructions in https://github.com/space-ros/docker/tree/main/moveit2.
• Build navigation2 image following instructions in https://github.com/space-ros/docker/tree/main/navigation2.
• Build space_robots image following instructions in https://github.com/space-ros/docker/tree/main/space_robots.
• Boot space_robots image. Start Mars rover demo, check that the demo launches, and it's possible to send commands to the rover. Start canadarm demo, check that the demo launches, and it's possible to send commands to the robotic arm.
• Boot the Nav2 image and run following the instructions in https://github.com/space-ros/docker/tree/main/nav2_demo#run-the-mars-rover-demo-with-nav2-and-slam-toolbox. Check that the robot is localizing.

[EzraBrooks]

If Ivan doesn't get a chance to do so, I will collate his and Brian's notes during the release process.

[ivanperez-keera]

For the just released version of Space ROS, we did this: #33 (comment), which includes some tests.