Michael Schlottmann

Author: Michael Schlottmann

  • RP Rower

    Description

    I had purchased a rowing machine. Unfortunately, the machine did not calculate some values correctly, such as average Strokes Per Minute. Since I had a Raspberry PI and an ultrasonic sensor left, I thought I would try to build this myself. The result is the RP Rower.

    Of course, not all values can be calculated exactly, such as the distance per stroke, but the curiosity was aroused in me to try it out.

    Hardware

    • Rowing machine
    • Raspberry Pi 4
    • Ultrasonic sensor HC-SR04
    • Resistors
    • Breadboard
    • Wires

    Set-up

    • Set-up the Raspberry Pi with the sensor. You find enough tutorials in the internet to connect the sensor with the Raspberry Pi.
    • The sensor measures the distance from the sensor to an object and it must be attached to the rowing machine. In my case I attached the sensor under the hold for the feet. The object was placed under the seat.
    • Clone the git project on your Raspberry Pi. https://github.com/TestAndWin/rp-rower
    • Maybe you have to adapt the constant FACTOR_DISTANCE in the file rower.py. This is used to convert the distance measured by the sensor to the distance of the stroke. As said, the distance value can only give a rough indication.

    Running

    • Start the RP Rower with python3 rower.py

    User Interface

    • Connect with a device like a tablet to the rower, the server is running on port 5000.
    • Click on Start button and start rowing đŸ™‚
    RP Rower
    RP Rower

  • Brick Sorter

    Today I am not writing about software testing, but about a programming project. I was interested in how machine learning works and was looking for an application example. I decided on a sorting machine with which blocks such as Lego can be sorted, called the Brick Sorter.

    The project was very interesting and varied. Not only did I learn about machine learning, but I also had to design something and program it in Python.

    You can watch a video of the Brick Sorter.

    Hardware

    • Raspberry PI 4 with camera
    • 2 DC motor, 2 stepper motor, 1 servo motor
    • Fischer Technik, wood and an aluminium bar for construction

    Software

    • Python with Flask, Keras
    • You can find the project here: Link to Github

    Solutions

    Put the bricks in a sequence

    The first problem I had to solve was to get the bricks in a sequence. This is important so that each brick can be photographed individually. I solved this via a conveyor belt and a vibrating plate. At the beginning of the conveyor belt is a small funnel in which the bricks can be laid. Only one sled is mounted on the conveyor belt, so that the bricks are not transported too quickly to the vibrating plate. I built the conveyor belt out of Fischertechnik parts.

    From the conveyor belt, the bricks fall onto a vibrating plate (aluminium), which has a slight slope. To create the vibration, I attached an unbalance to a DC motor and this DC motor is attached to the plate. The bricks must also pass through a kind of curtain on the vibrating plate in order to separate the bricks even further. But most of it is achieved by the vibration.

    At the end of the plate there is a gate installed, which opens for a short moment and then closes again. Then the bricks fall on a plate where the photos are taken. The gate is operated by a servo motor and the control of the individual motors is taken over by a Raspberry Pi.

    Create photos in sufficient quality

    In my view, the most difficult task in the construction project was to take photos of the bricks in good quality. This is very important for the good detection of the brick type. I had tried various things, but often had the problem that some things were in the background, which then interfered with the detection. In the current solution, I stretched a grey sheet of paper over the plate and adjusted the slope so that the bricks slip into the center so that they can be photographed well. It was also important that the plate is always well and evenly illuminated. The photos are taken with a Raspberry PI camera.

    Determine brick type

    When a brick arrives on the plate, the conveyor belt and the vibrating plate are stopped so that no more bricks fall on the photo plate. The photo is sent to a server which then uses machine learning to calculate the probability of which type of brick it is. The result is then sent back to the Raspberry Pi.

    Sort brick into the right compartment

    When the Raspberry Pi has received the result, which type of brick it is, the hub is aligned accordingly. Afterwards, the photo plate is slightly tilted so that the brick can slide from the photo plate over the hub into the compartment. The photo plate is then driven back to its original position. The hub and the photo plate are driven by a stepper motor.

    Learning a model

    I also used the construction to take photos of the different types of bricks. It was important to have enough photos of each type of brick. To achieve this, I also rotated each photo by 90, 180, 270 degrees. As a model, I used a ready-made Convolutional Neural Network (CNN), the VGG16. The top-layer was replaced by an own layer. The learned model was saved and then used for detection.

    Next steps

    Currently I have trained the model on seven different brick types, from 1×1 to 2×4. To further optimize sorting, more images of other brick types would have to be created, and then the model would have to be retrained.

    Another point would be to further improve the detection of the bricks, so that the error rate is even lower. This would also require the model to be recreated.

    My Brick Sorter summary

    This project was a lot of fun for me. In addition to getting to know machine learning, I also had to deal more with the programming language Python. Another nice aspect was that I could construct physical things, such as conveyor belts or other things that were controlled with the Raspberry PI.

  • Test documentation

    In my past, I have seen different sorts of test documentation.

    From no test documentation at all, to very detailed test documentation with test cases with single steps and the expected behavior. On this page I will explain the extent of test documentation I consider useful. Of course, this always depends on the context in which I move. And you always have to consider, if for example legal requirements for test documentation have to be met. Or in a customer project, the customer may require a specific test documentation.

    What have I seen?

    Detailed test documentation

    A test plan contains the high level overview about the tests and the strategy/approach to run the tests for the component.

    One or more test cases exists for every feature of the component. For the good cases, as well as for error cases. A test case usually looks like this: Test case title, needed preconditions such accounts or test data and the post condition. And for each test step: the action and the expected behavior. The same steps often appear in multiple test cases when testing different cases for one functionality. In a good set-up the test cases are management with a test case management system.

    In my opinion this requires a lot of effort to describe the individual test cases including the steps. And to maintain the maintenance effort must be considered as well.

    I discovered that the documented tests become obsolete after a certain time, or sometimes even after a short time. One reason is that they are not executed regularly and one other reason is to keep them up to date.

    From my point of view this kind of documentation has only one advantage, if persons who are not familiar with the domain have to execute the tests frequently and manually.

    No test documentation

    Of course, the initial effort to have no documentation is zero. But in my opinion, the effort arises later. If you need to test the component after a while, you first need to re-learn and understand what is important for the component and what is not. This could decrease the quality of the test and thus result in errors.

    My preferred scope of test documentation

    I think it is important to have a test documentation. A good documentation makes it easier for new colleagues to familiarize themselves with the components. And it helps when working on the component after a while and to share knowledge in the company. From my point of view, the following structure has proven itself.

    Test scenarios

    Overview of the different test scenarios. I suggest to omit a detailed description of the individual test cases. What I prefer is to invest the effort in the automation of the individual steps so that they can be carried out continuously in a pipeline.

    Risks

    What risks are to be minimized or completely excluded by the test? And you should also look at the point in this way: what would be the worst thing that could happen? For example login, a login without a correct password is possible. This must, of course, not happen under any circumstances.

    Blast Radius

    If the component is unavailable or causing errors, which other components are affected by it? This blast radius should of course be as low as possible.

    Required components

    Overview about all components needed to execute end-to-end tests of the component.

    Specialties

    If any, what are the components specialties. Are there any special features that need to be taken into account.

    Quality characteristics

    Overview about quality characteristics and how important each is for the component. For example the ISO 25010 lists various quality features.

    The overview should also contain the test types and the tools (if used) used to verify the different quality characteristics.

    Test Accounts / Test Data

    This section should give an overview about:

    • The needed test accounts.
    • Needed test data or how to prepare the test data.

    Test documentation final thoughts

    Component documentation could embed the test documentation. The component documentation should contain a brief description of the component, use cases, architecture description and so on. This way you can find all the important information about a component on a single page or on a page with sub-pages.

    The effort for this kind of test documentation is manageable and the maintenance of the documentation is low. This gives the team a good overview of the component, including the test approach, and of the important test scenarios.

    I would put the effort of creating and maintaining detailed test cases into test automation. That way, tests can be triggered automatically when a new version of the software has been deployed. And they usually provide faster feedback to the developer.

  • Why I like Cypress for test automation

    I am using https://www.cypress.io/ for about a year now and I think it is great.

    test automation with Cypress

    In my opinion it offers the following good features:

    The Cypress Test Runner supports you very well for developing or maintaining tests.

    • You receive fast feedback. When you save the test, the Test Runner immediately runs the test.
    • You can select HTML elements with the Test Runner and insert them quickly into the test source code via the clipboard.
    • You can view the settings with the Test Runner which can be very helpful for error analysis.
    • Test Runner allows you to debug the tests very easily.
    • Information can be queried via the browser console.

    You don’t need any waits, which you know from Selenium. Cypress waits “automatically” until the element is “ready”.

    Cypress records videos of the tests. This is helpful if a test fails when it is not obvious at first glance why there was a failure. Cypress also automatically creates a screenshot (as known from other tools), but the video can make the analysis easier.

    It is easy to install and set-up. You just need Node and npm or yarn.

    The documentation is very good.

    Cypress allows to retry failing tests. This could by handy for end-to-end tests.

    Cypress allows to make http requests within the browser context. With this it is possible to test API’s. Furthermore with this is for example a login in the context of a web application possible. This can be helpful if you do not want to test the login functionality but the functionality is protected by a login. This results in faster running tests and in reduced complexity.

    Cypress does not support as much browser as for example Selenium. However with my previous experience, I very rarely needed to run the automatic tests on different devices to significantly reduce the risk of regression errors.