AMiRo-Apps issueshttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues2022-11-14T14:39:31+01:00https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/38Default Apps2022-11-14T14:39:31+01:00Svenja KennewegDefault AppsWhen the user uses the AMiRo Default Configuration some Demo Apps should be flashed:
- LineFollowing
- Obstacle Avoidance (https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/15)
- LightFloorData
The app functionality should ...When the user uses the AMiRo Default Configuration some Demo Apps should be flashed:
- LineFollowing
- Obstacle Avoidance (https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/15)
- LightFloorData
The app functionality should be started when
- turning the AMiRo upside down
- shell command
- touching specific proximity sensor
If https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/28 is done the RemoteExample App should be flashed when the ESP is flashed.Svenja KennewegSvenja Kenneweghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/14line following application2022-11-11T13:56:51+01:00Thomas Schöppingline following applicationImplement an application to follow lines using the ground facing sensors.
Preferably, the implementation employs an advanced control scheme (e.g. PID controller) to facilitate smooth motion.
Furthermore, the applications should provide ...Implement an application to follow lines using the ground facing sensors.
Preferably, the implementation employs an advanced control scheme (e.g. PID controller) to facilitate smooth motion.
Furthermore, the applications should provide modes to track the center of the line or either edge.
Finally, inadequate sensor input (e.g. too low contrast between all sensors) should be detected and the line following should stop the robot as result.Svenja KennewegSvenja Kenneweg2022-05-15https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/35Specific Names for Apps2022-10-20T17:40:55+02:00Svenja KennewegSpecific Names for AppsFollowing apps should have specific names, variables and header files:
- BNO055 (IMU of AMiRo v1.2 only)
- DifferentialMotionEstimator
- DifferentialMotorControl
- Floor
- Light
- ProximitySensor
- TouchSensors
- Accelerometer (AMiRo v1...Following apps should have specific names, variables and header files:
- BNO055 (IMU of AMiRo v1.2 only)
- DifferentialMotionEstimator
- DifferentialMotorControl
- Floor
- Light
- ProximitySensor
- TouchSensors
- Accelerometer (AMiRo v1.1 only)
- Compass (AMiRo v1.1 only)
- Gyroscope (AMiRo v1.1 only)
These apps are all directly related to the AMiRo's hardware. <br>
To prevent errors when including external libraries they should be named AMiRo_<otherText>. Just like their variables, header files, ... .Svenja KennewegSvenja Kenneweg2022-09-30https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/36TensorflorLite Integration2022-09-15T13:40:06+02:00Svenja KennewegTensorflorLite IntegrationWhen integrating TensorflowLite on the AMiRo the AMiRo crashed. Probably from memory issuesWhen integrating TensorflowLite on the AMiRo the AMiRo crashed. Probably from memory issuesSvenja KennewegSvenja Kenneweghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/34Odometry Reset2022-08-25T13:14:51+02:00Lauritz KeysbergOdometry ResetCreate a service/function to reset the odometry valuesCreate a service/function to reset the odometry valuesSvenja KennewegSvenja Kenneweghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/28CAN-Bridge: Protocol enhancements2022-08-11T11:25:10+02:00Thomas SchöppingCAN-Bridge: Protocol enhancementsThe protocol which defines CAN frame identifiers and payloads for inter-module µRT communication offers potential for optimization.
# current definition
- frame ID
- bits 0-5: 6-bit frame counter for subsequent frames in case a messa...The protocol which defines CAN frame identifiers and payloads for inter-module µRT communication offers potential for optimization.
# current definition
- frame ID
- bits 0-5: 6-bit frame counter for subsequent frames in case a message needs to be split in several 8 byte chunks.
- bits 6-21: 16-bit topic or service ID.
- bits 22-25: 4-bit transmission type (topic, xRT request or response).
- topic: 0b0000
- NRT request: 0b0001
- SRT request: 0b0011
- FRT request: 0b0111
- HRT request: 0b0101
- response flag: 0b1000
- bits 27-29: 3-bit board ID of the emitting module.
- payload
1. arbitrary number of payload bytes
2. eight additional payload bytes to hold the 64-bit timestamp
# drawbacks
- CAN bitwise arbitration checks bits from MSB to LSB, so the first bits should hold the primary priority information, which is not the case right now.
- Only 8 board IDs (3 bits) supported.
- Transmission type definitions do not represent a sensibile hierarchy wrt. bitwise arbitration.
# proposal
- frame ID
- Change order to (from MSB to LSB):<br>
_(order of 2. and 3. should be discussed or even made configurable)_
1. transmission type
2. board ID or topic/service ID
3. topic/service ID or board ID
4. frame counter
- Redefine transmission types:<br>
_(this would decrease this field to 3 bit)_
- 0b000: reserved for non-protocol, high-priority transmissions
- 0b001: publish-subscribe transmission (topic)<br>
Time-based communication is typically most critical.
- 0b010: HRT request<br>
HRT denoted event-based communication has very high priority as well.
- 0b011: response<br>
This ensures that responses to HRT requests will not be suppressed by low-priority requests.
- 0b100: FRT request
- 0b101: SRT request
- 0b110: NRT request
- 0b111: reserved for non-protocol, low-priority transmissions
- Increase board ID to 8 bit to allow for a reasonable number of modules in a system.
- Decrease topc/service ID to 11 bit (= standard CAN ID).
- Increase frame counter to 7 bit to allow for a maximum of 1024 byte payload per transmission (2⁷ frames á 8 bytes).
- payload
- Always transmit an additional frame containing the timestamp and meta information.
- Whether a request is flagged _fire-and-forget_ is currently encoded in the frame ID via the response flag.
Because those frame ID bits are very precious, this information should rather be encoded in the payload.
- Transmit the number of overall expected frames for the message.
- Transmit "incomplete" timestamp.<br>
Since 58 bits (7 bytes) or even 52 bits (6 bytes) are still enough to represent reasonable time frames at microsecond precision (~9000 years and ~140 years respectively), one or two of the total 8 bytes could be saved for transmission and assumed to be 0.
Since the frame counter is limited to 7 bits and only a single bit is required for the _fire-and-forget_ flag, a single byte should suffice for meta information and 58 bits could be used for the timestamp.
- The timestamp & meta information frame should be prepended (not appended).<br>
In case time or meta information is relevant during message parsing, this information should be available first.
- frame order
1. time & meta information frame<br>
Should use frame counter value of 0 for maximum priority.
2. payload frames<br>
Frame counter should count downwards from _n_ (total number of frames) to 1 (0 is reserved for the time & meta information frame).https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/33CANBridge enhancements2022-08-02T14:26:14+02:00Svenja KennewegCANBridge enhancementsWhen the CANBridge received an incomplete MetaFrame it should print a debug assertion.
Also provide a little Readme how to use the CANBridge (Send, receive data)When the CANBridge received an incomplete MetaFrame it should print a debug assertion.
Also provide a little Readme how to use the CANBridge (Send, receive data)Svenja KennewegSvenja Kenneweghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/16applications for docking and charging at a charging dock2022-06-30T12:48:20+02:00Thomas Schöppingapplications for docking and charging at a charging dockImplement applications to dock at a charging station and to handle charging logic.
The docking application should make an AMiRo, which is already close to a charging dock, to approach the dock align its charging pins to the connectors o...Implement applications to dock at a charging station and to handle charging logic.
The docking application should make an AMiRo, which is already close to a charging dock, to approach the dock align its charging pins to the connectors of the station and dock.
In order to check whether docking was successful, the motors should be turned off completely, so that the charging pins would push the robot away from the charging dock.
If docked correctly, however, the rear screw of AMiRo is held by the magnet of the charging dock and the robot will not move.
Only then the voltage on the pins must be verified before it is applies to the internal system power.
As soon as that has happened, the _PowerManagement_ module would detect the high system voltage via its ADC and enable the chargers.
However, as soon as movement is detected and to robot might loose contact to the charging dock, the pins must be switched off immediately.Lauritz KeysbergLauritz Keysberg2022-06-30https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/21Showcase Demo2022-06-30T12:38:54+02:00Svenja KennewegShowcase DemoCurrent status: Human loading instance, AMiRo drives around and shows its battery state over the LEDs
In nearly future following point should be fulfilled:
* [x] Independently charging
The current showcase demo performs on OS 1.0 . T...Current status: Human loading instance, AMiRo drives around and shows its battery state over the LEDs
In nearly future following point should be fulfilled:
* [x] Independently charging
The current showcase demo performs on OS 1.0 . Therefore all functions must be transferred to OS 2.0:
* [x] Stable Line Following (see: https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/14)
* [x] Driving to the docking station
* [x] Checking of the battery state
* [x] Docking on (docking station) (see: https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/16)
* [x] Charging (see: https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/16)
Because the AMiRo destroys his path while driving a printed base plate could be useful.
Satin foil to glue on exists.
Nice to haves are:
* Integration of the "Spiegel"
* revised graphical representation of the demo
* integration of the TWB-Tracking
* integration of the Bi-Vital
* Portable showcase [hier](https://eventmoebel.koeln/shop/deckplatte-maxi-fuer-dinnertische/)Lauritz KeysbergLauritz Keysberg2022-06-30https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/30Careless mistake in the DifferentialMotorControl App?2022-06-07T13:49:37+02:00Svenja KennewegCareless mistake in the DifferentialMotorControl App?https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/blob/main/apps/DifferentialMotorControl/differentialmotorcontrol.c
Line 282: <br>
`right_derror = (left_error - ((dmc_t*)dmc)->control.right.error.last) / time_diff;` <br>
Probably i...https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/blob/main/apps/DifferentialMotorControl/differentialmotorcontrol.c
Line 282: <br>
`right_derror = (left_error - ((dmc_t*)dmc)->control.right.error.last) / time_diff;` <br>
Probably it should be: <br>
`right_derror = (right_error - ((dmc_t*)dmc)->control.right.error.last) / time_diff;`<br>Thomas SchöppingThomas Schöppinghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/27Shutdowns of AMiRo2022-05-19T17:30:32+02:00Svenja KennewegShutdowns of AMiRoDuring a student project the AMiRo accidentally crashes.
An already found reason could be:
The urtCoreGetTopic() function of the CANBridge returns NULL for an existing topic.
How to reproduce the issue:
- Check out the HighscoreProj...During a student project the AMiRo accidentally crashes.
An already found reason could be:
The urtCoreGetTopic() function of the CANBridge returns NULL for an existing topic.
How to reproduce the issue:
- Check out the HighscoreProject_oldCANBridge branch.
- Touch the left floor wheel sensor to activate some lights and send motor commands.
- During the test you can touch the two front floor sensor to change the light and motor commands.
- Wait - sometimes it takes up to 10 minutesSvenja KennewegSvenja Kenneweghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/29Missing services for deactivation and reactivation of DMC2022-05-19T17:15:08+02:00Lauritz KeysbergMissing services for deactivation and reactivation of DMCThe DifferentialMotorController can currently not be deactivated or reactivated. For some AMiRo application functions, like secure docking and charging, it is desirable to be able to turn the DMC on and off.The DifferentialMotorController can currently not be deactivated or reactivated. For some AMiRo application functions, like secure docking and charging, it is desirable to be able to turn the DMC on and off.Thomas SchöppingThomas Schöppinghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/13user guide2022-04-08T15:45:19+02:00Thomas Schöppinguser guideProvide a user guide for new developers to lower the initial hurdle to get started with the AMiRo-Apps environment.
Alongside a textual guide and/or a video guide, several further thingies should be provided:
- [x] tutorial
- [x] text...Provide a user guide for new developers to lower the initial hurdle to get started with the AMiRo-Apps environment.
Alongside a textual guide and/or a video guide, several further thingies should be provided:
- [x] tutorial
- [x] textual
- [ ] video
- [x] code (sample solution)
- [x] example (e.g. HelloWorld)
- [x] application
- [x] configuration
- [x] code documentation (e.g. Doxygen)
- [x] AMiRo-Apps
- [x] AMiRo-OS
- [x] AMiRo-LLD
- [x] µRT
- [x] generate and view documentation via `setup.sh` script
- [x] AMiRo-Apps
- [x] AMiRo-OS
- [x] AMiRo-LLD
- [x] µRT
- [x] ChibiOS
- [x] rationale of the underlying concepts
- [x] AMiRo-Apps
- [x] AMiRo-OS
- [x] AMiRo-LLD
- [x] µRT2022-04-01https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/26CAN Frames get lost2022-03-23T14:56:12+01:00Svenja KennewegCAN Frames get lostWhen sending frames over the CAN Bridge some get lostWhen sending frames over the CAN Bridge some get lostSvenja KennewegSvenja Kenneweg2022-03-31https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/5DifferentialMotorControl Overflow2022-03-01T15:30:05+01:00Thomas SchöppingDifferentialMotorControl OverflowThe PID controllers of the DMC application tend to overflow when setting high target values, resulting in unstable behavior and even crashing of the application.
The exact variables, that cause these numerical issues, need to bee identif...The PID controllers of the DMC application tend to overflow when setting high target values, resulting in unstable behavior and even crashing of the application.
The exact variables, that cause these numerical issues, need to bee identified and an according limiter has to be applied.Thomas SchöppingThomas Schöpping2022-02-28https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/10CANBridge App2022-02-03T10:04:42+01:00Svenja KennewegCANBridge AppThis app should send request and publisher data over the CANBridgeThis app should send request and publisher data over the CANBridgeSvenja KennewegSvenja Kenneweg2022-01-31https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/11BNO055 App2022-01-11T15:57:17+01:00Svenja KennewegBNO055 AppReading the BNO055 data and publishing them on a topicReading the BNO055 data and publishing them on a topicSvenja KennewegSvenja Kenneweg2022-01-31https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/20Light app2022-01-03T17:52:49+01:00Svenja KennewegLight appThe light app should also work for the BlackMiRo having 24 LEDsThe light app should also work for the BlackMiRo having 24 LEDsSvenja KennewegSvenja Kenneweg2022-01-31https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/12ProximitySensor calibration2021-12-20T16:44:32+01:00Thomas SchöppingProximitySensor calibrationImplement calibration capabilities for the proximity sensors of the _ProximityRing_.
It should be very similar to the calibration logic for the floor sensing application.Implement calibration capabilities for the proximity sensors of the _ProximityRing_.
It should be very similar to the calibration logic for the floor sensing application.Thomas SchöppingThomas Schöpping2022-02-28https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-Apps/-/issues/9DMC broken2021-12-15T15:15:14+01:00Thomas SchöppingDMC brokenCommit c17c39c7 seems to have broken the DMC application. Setting new target velocities results in undefined behavior due to some misaligned data conversion.
The issue is most probably caused by the introduced dependency to the CAN brid...Commit c17c39c7 seems to have broken the DMC application. Setting new target velocities results in undefined behavior due to some misaligned data conversion.
The issue is most probably caused by the introduced dependency to the CAN bridge application. Such dependencies however violate space decoupling and are not allowed with µRT.Svenja KennewegSvenja Kenneweg