AMiRo-Apps issueshttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues2023-08-03T09:55:20+02:00https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/40Code duplicate in DiWheelDrive_1-2 apps.c2023-08-03T09:55:20+02:00Jonas GrubeCode duplicate in DiWheelDrive_1-2 apps.c[These lines](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/blob/main/configurations/AMiRoDefault/modules/DiWheelDrive_1-2/apps.c#L255-271) contain the declaration of
```C
urt_service_t can_service[NUM_SERVICES];
size_t payload_...[These lines](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/blob/main/configurations/AMiRoDefault/modules/DiWheelDrive_1-2/apps.c#L255-271) contain the declaration of
```C
urt_service_t can_service[NUM_SERVICES];
size_t payload_sizes[NUM_SERVICES];
```
twice.
This probably is ignored by the compiler, but could cause problems, if one of the declarations is altered, but the second one overrides the change.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/39Demo: AssemblyLine2022-11-09T10:43:04+01:00Svenja KennewegDemo: AssemblyLineDuring the Autonomous Systems engineering project the students developed an exemplary "assembly-line". For this the AMiRo follows - given a JSON file - the attached track.
One student group also developed an graphical user interface whi...During the Autonomous Systems engineering project the students developed an exemplary "assembly-line". For this the AMiRo follows - given a JSON file - the attached track.
One student group also developed an graphical user interface which could be used as a demo. While testing their implementation following things were noticed that must be improved for a stable and valid demo:
- [ ] Unstable Line Following. Resetting the overall velocity from 0.15 to 0.1 seems as a valid solution.
- [ ] Shape detection of the objects only works for the default velocity of 0.15
- [ ] Revision of the GUI (no pixelated graphs, dynamic adjustment of sizes)
- [ ] No connection after a long standing of the AMiRo in the IDLE state
- [ ] GUI sometimes lags behind the real positions
After fixing the above points following todos are still pending:
- [ ] Demo should run on all AMiRos (Default AMiRo is 68)
- [ ] Write a demo readme here: https://gitlab.ub.uni-bielefeld.de/amiro-internal/demos/management
- [ ] Probably a docker image for the Demo is useful
- [ ] Python package of the GUI
[Automatica5_merged.pdf](/uploads/e4e4c4bf15109621c2a3b1656b9d4ba8/Automatica5_merged.pdf)Kaja HubmannKaja Hubmannhttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/37App for the new Sensorring2023-02-01T11:42:39+01:00Svenja KennewegApp for the new SensorringImplement an app for the new ToF and Proximity Sensorring.
Before implementing an app different driver and tests need to be implemented or tested:
- [ ] Driver and test for the [PCA9554](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-L...Implement an app for the new ToF and Proximity Sensorring.
Before implementing an app different driver and tests need to be implemented or tested:
- [ ] Driver and test for the [PCA9554](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/11#note_163716)
- [ ] Driver for the [VL53L5CX](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/12)
Hint: Flash the PowerManagement over <br>
`make flash_PowerManagement_1-2 BOARD_SENSORRING=BOARD_TOFPROX_SENSOR`https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/32Flash the AMiRo over WLAN2022-07-22T09:55:00+02:00Svenja KennewegFlash the AMiRo over WLANBecause of the ESP breakout board which is plugged on top of the AMiRo, data can be written on the internal CAN bus of the AMiRo.
To make the programming cable completely superfluous and support the autonomy of the robot, flashing via WL...Because of the ESP breakout board which is plugged on top of the AMiRo, data can be written on the internal CAN bus of the AMiRo.
To make the programming cable completely superfluous and support the autonomy of the robot, flashing via WLAN should be implemented. <br> <br>
The topic should be assigned as 10 LP Project. At the same time, the serial terminal should also be sent via CAN/WLAN.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/25Decentralized Project Structure2022-03-17T10:28:29+01:00Thomas SchöppingDecentralized Project StructureCurrently, the AMiRo-Apps project implements a very centralized architecture, where all application and configuration code resides in this single project.
A more liberal approach could facilitate a more decentralized architecture, where ...Currently, the AMiRo-Apps project implements a very centralized architecture, where all application and configuration code resides in this single project.
A more liberal approach could facilitate a more decentralized architecture, where applications and configurations have their individual projects but can be plugged together using defined interfaces.
First of all configurations should be moved into an individual project, which holds the operating system, middleware(s) and applications as Git submodules, and provides any required glue code.
The application project(s) on the other hand, expects certain interfaces (i.e. of an operating system and middleware), which it does not hold by itself.
The actual "installation paths" of those should probably specified via GNU Make configuration variables.
Any message types used for communication are probably still best defined within the application project.
As result, a configuration project could still comprise multiple configurations with multiple modules each, but also multiple operating systems, multiple middlewares and multiple application projects, and provide all the glue code required for those to interact with each other.
The benefits of such an architecture would be:
- Application and configuration logic decoupled in separate projects.
- Due to this relaxation of dependencies, code development becomes more "decentralized".
- Configurations can comprise *multiple* application projects and *multiple* environments (operating systems & middlewares).
For the AMiRo plattform, this would allow to unite AMiRo-OS + µRT MCU code and Linux + ROS code in a single configuration project.
Some challenges are expected though:
- Compatibility between OS/middleware expected by applications and actually provided by the configuration.<br/>
-> Checking version definitions would be straight-forward, but maybe there is a more elegant solution (e.g. what if multiple application projects expect different versions of the same middleware?).
- Transformation of message types between middlewares.<br/>
-> two (or more?) alternatives:
1. Additional mediator applications, which act as bridges between middlewares.
- rather complex
- responsibility is entirely at the configuration
2. Applications, message types or middlewares must provide an API to induce and execute transformation code.
- less complex
- requires support by applications and/or middlewares
- still requires configuration to provide and induce such logichttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/24Allow for automated setup2022-03-17T10:29:00+01:00Ruben LippertsAllow for automated setupCurrently, it is not possible to run the initialisation via `setup.sh` without human intervention.
Using the flags `--init` and `--quit` it is possible to avoid most prompts. Still the setup procedure prompts with an `Understood!`, expe...Currently, it is not possible to run the initialisation via `setup.sh` without human intervention.
Using the flags `--init` and `--quit` it is possible to avoid most prompts. Still the setup procedure prompts with an `Understood!`, expecting input. To have any kind of CI take place it is necessary to run the setup procedure without human intervention.
**Simple Solution:**
- [ ] Add a `--no-prompts` flag that disables all prompts
**Nice to have:**
The prompt actually occurs in a part of the setup, which does not need to be performed for CI testing. Unfortunately, the `--init` flag performs initialisation of **all** submodules. This results in a large (avoidable) overhead with every kind of test performed.
- [ ] Allow to control the setup procedure by commandline arguments in the same kind of granularity that the manual setup hasRuben LippertsRuben Lippertshttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/23(De)serialization of data2022-03-17T10:29:20+01:00Svenja Kenneweg(De)serialization of dataAn use case is the CANBridge where the data should be serialized before sending them and deserialized when receiving.
For this, an appropriate library like [nanopb](https://jpa.kapsi.fi/nanopb/) could be used.An use case is the CANBridge where the data should be serialized before sending them and deserialized when receiving.
For this, an appropriate library like [nanopb](https://jpa.kapsi.fi/nanopb/) could be used.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/19EEPROM application2022-03-17T10:25:37+01:00Thomas SchöppingEEPROM applicationIntroduce an application for EEPROM access on the AMiRo modules.
Preferably, the contents should be represented by a custom C struct for simple access.
In order to support versioning/compatibility checks, some identifier should be stor...Introduce an application for EEPROM access on the AMiRo modules.
Preferably, the contents should be represented by a custom C struct for simple access.
In order to support versioning/compatibility checks, some identifier should be stored in the EEPROM.
This could be accomplished by a hash of the struct type (not its contents!).2022-03-31https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/18'AMiRo-Charger' enhancements2022-03-17T10:26:53+01:00Thomas Schöpping'AMiRo-Charger' enhancementsThere are several open issues with the [AMiRo-Charger](apps/AMiRo-Charger) application:
- [ ] Take fule gauges into account.<br>
Charging should only be enabled if batteries are actually within a defined range (e.g. 50% - 80% char...There are several open issues with the [AMiRo-Charger](apps/AMiRo-Charger) application:
- [ ] Take fule gauges into account.<br>
Charging should only be enabled if batteries are actually within a defined range (e.g. 50% - 80% charge).
- [ ] Introduce service to allow manual charging.<br>
A service should be provided to set charging manually.
The service should still check current system parameters and respond accordingly:
- system voltage too low for charging -> error
- battery level out of recommended range -> warning
- [ ] Decouple LED control to individual application.<br>
Currently, the status LED is toggled by the application, which is undesired behaviour.
Preferably, an additional application will listen to the messages published by the charge app and set the LED accordingly.
- [ ] Introduce DiWheelDrive logic.<br>
Introduce logic specifically for the DiWheelDrive modules:
- check pin voltage (periodically and/or on demand)
- enable voltage from pins to system voltage (on demand only)2022-06-30https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/17StreetSign demo FSM2022-03-17T10:26:58+01:00Thomas SchöppingStreetSign demo FSMImplement an application to interface the high-level logic of the street sign detection demo.
This application should also implement an FSM according to the expectations of the high-level logig.Implement an application to interface the high-level logic of the street sign detection demo.
This application should also implement an FSM according to the expectations of the high-level logig.2022-06-30https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/15obstacle avoidance applications2022-10-21T11:15:12+02:00Thomas Schöppingobstacle avoidance applicationsImplement a set of applications to avoid obstacles and facilitate wall following.
In principle the independent applications should be combined in a configuration so that
- The robot moves straight forward at a specified speed.
- As soon...Implement a set of applications to avoid obstacles and facilitate wall following.
In principle the independent applications should be combined in a configuration so that
- The robot moves straight forward at a specified speed.
- As soon as an obstacle is detected in front, the robot stops.
- If an obstacle is detected the robot can follow its shape.2022-05-15https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/4DifferentialMotorControl auto-calibration2022-11-15T12:23:50+01:00Thomas SchöppingDifferentialMotorControl auto-calibrationThe DifferentialMotorControl application (DMC) should provide a feature to automatically calibrate the several PID parameters.
An according interface (service and shell command) is already in place.
The automatic calibration procedure i...The DifferentialMotorControl application (DMC) should provide a feature to automatically calibrate the several PID parameters.
An according interface (service and shell command) is already in place.
The automatic calibration procedure is planned to work like this;
1. Preparations
- Simplify all controllers to P-controllers by setting all other gains to 0.
- Set the P-gains for the two motor controllers to low values.
- Deactivate the steering controller by setting even the P-gain to 0.
- Ignore any incoming target velocity requrests during calibration.
2. Calibration of the motor controllers
1. Iteratively increase the P-gains of the two motor controllers until they oscillate but try to make the robot move straight.
2. Repeat the following sequence
1. move forwards
3. move backwards
4. stop
3. As soon as those critical gains are found, adapt all other gains using [Ziegler-Nichols method](https://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method).
3. Calibration of the steering controller
1. Set the P-gain of the steering controller to a low value.
2. Iteratively increase the P-gain of the steering controller until it oscillates.
3 Repeat the following sequence
1. turn left
3. turn right
4. stop
3. As soon as the critical gain is found, adapt all other gains using [Ziegler-Nichols method](https://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method).Lauritz KeysbergLauritz Keysberghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/3`HelloWorld` enhancements2022-03-17T10:29:46+01:00Thomas Schöpping`HelloWorld` enhancementsThe `HelloWorld` application currently does not set any timing constraints.
The application as well as the configuration code need to be expanded so that the user can optionally set those parameters via the provided CLI.The `HelloWorld` application currently does not set any timing constraints.
The application as well as the configuration code need to be expanded so that the user can optionally set those parameters via the provided CLI.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/2introspection application2022-03-17T10:29:49+01:00Thomas Schöppingintrospection applicationDesign and implement an application that can be used for introspection of [µRT](https://gitlab.ub.uni-bielefeld.de/AMiRo/uRtWare).
The too shall be accessible via the [AMiRo-OS](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS) shell.
T...Design and implement an application that can be used for introspection of [µRT](https://gitlab.ub.uni-bielefeld.de/AMiRo/uRtWare).
The too shall be accessible via the [AMiRo-OS](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS) shell.
Typical capabilities of the too shall be (among others):
- list all topics
- read information about topics
- read information about messages and print payload
- listen to one or multiple topics and inform the user
- list all available services
- etc.
In order to realize an efficient and user friendly introspection, further enhancements of [µRT](https://gitlab.ub.uni-bielefeld.de/AMiRo/uRtWare) and [AMiRo-OS](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS) may be necessary as well.