Rsewiki - Recent changes [en]

CycloneDDS Configuration file

S253734 — Thu, 28 May 2026 18:43:37 GMT

← Older revision		Revision as of 20:43, 28 May 2026
Line 1:		Line 1:
			Back to [[Electronics]]

	The IP address in NetworkInterfaceAddress must match the Ethernet IP address of the local computer.		The IP address in NetworkInterfaceAddress must match the Ethernet IP address of the local computer.
	<CycloneDDS>		<CycloneDDS>

Electronics

S253734 — Thu, 28 May 2026 18:43:00 GMT

← Older revision	Revision as of 20:43, 28 May 2026
(One intermediate revision by the same user not shown)
(No difference)

Fejemis Vision ROS2

S253734 — Thu, 28 May 2026 18:41:12 GMT

← Older revision		Revision as of 20:41, 28 May 2026
(6 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	Back to [[Fejemis ~~2026~~]]		Back to [[Fejemis ROS2 Software]]

	== fejemis_vision package ==		== fejemis_vision package ==
Line 22:		Line 22:

	Main launch files:		Main launch files:
	* ''~~main-launch~~.py'' - Launches the complete perception system		* ''main_launch.py'' - Launches the complete perception system.

	Testing launch files:		Testing launch files:
	* cable_test.launch.py - Launches the cable detection pipeline		* ''cable_test.launch.py'' - Launches the cable detection pipeline.
	* net_test.launch.py - Launches the net detection pipeline		* ''net_test.launch.py'' - Launches the net detection pipeline.
	* people_test.launch.py - Launches the people detection pipeline		* ''people_test.launch.py'' - Launches the people detection pipeline.

	These launch files initialize the required ROS 2 nodes, camera subscriptions, and RViz visualization.		These launch files initialize the required ROS 2 nodes, camera subscriptions, and RViz visualization.
Line 35:		Line 35:

	Main scripts:		Main scripts:
	* main.py - Main ROS 2 vision node coordinating the perception system		* ''main.py'' - Main ROS 2 vision node coordinating the perception system

	Detection scripts:		Detection scripts:
	* cable_detection.py - Detects cables and linear structures in the environment		* ''cable_detection.py'' - Detects cables and linear structures in the environment.
	* net_detection.py - Detects net or mesh-like structures using computer vision methods		* ''net_detection.py'' - Detects net or mesh-like structures using computer vision methods.
	* people_detection_pose_segmentation.py - Human detection using pose estimation and segmentation		* ''people_detection_pose_segmentation.py'' - Human detection using pose estimation and segmentation.
	* people_detection_depth_segmentation.py - Human detection using depth-based segmentation		* ''people_detection_depth_segmentation.py'' - Human detection using depth-based segmentation.
	* people_detection_simple_segmentation.py - Simpler segmentation-based human detection approach		* ''people_detection_simple_segmentation.py'' - Simpler segmentation-based human detection approach.

	Tracking:		Tracking:
	* people_detection_deep_sort.py - Multi-person tracking using the DeepSORT tracking algorithm		* ''people_detection_deep_sort.py'' - Multi-person tracking using the DeepSORT tracking algorithm.

	Testing scripts:		Testing scripts:
	* cable_test.py		* ''cable_test.py''
	* net_test.py		* ''net_test.py''
	* people_test_basic.py		* ''people_test_basic.py''

	These scripts are used for testing and validating the detection pipelines independently.		These scripts are used for testing and validating the detection pipelines independently.
Line 57:		Line 57:
	The package contains several directories with offline test images used during development and debugging:		The package contains several directories with offline test images used during development and debugging:

	* cable_test_images/		* ''cable_test_images/''
	* net_test_images/		* ''net_test_images/''
	* people_test_images/		* ''people_test_images/''
	* other_imgs/		* ''other_imgs/''

	These images are used to evaluate the detection models without requiring a live camera stream.		These images are used to evaluate the detection models without requiring a live camera stream.
Line 68:		Line 68:

	Files include:		Files include:
	* yolov4-tiny.cfg - YOLOv4-tiny network configuration		* ''yolov4-tiny.cfg'' - YOLOv4-tiny network configuration.
	* yolov4-tiny.weights - Pretrained YOLOv4-tiny weights		* ''yolov4-tiny.weights'' - Pretrained YOLOv4-tiny weights.
	* classes.txt - Object class labels used by the detector		* ''classes.txt'' - Object class labels used by the detector.
	* mars-small128.pb - Feature extraction model used by DeepSORT tracking		* ''mars-small128.pb'' - Feature extraction model used by DeepSORT tracking.

	The package uses YOLOv4-tiny to achieve lightweight real-time object detection suitable for embedded systems such as Raspberry Pi devices.		The package uses YOLOv4-tiny to achieve lightweight real-time object detection suitable for embedded systems such as Raspberry Pi devices.
Line 121:		Line 121:
	=== Current Results ===		=== Current Results ===

	* All detection pipelines were successfully tested offline using stored test images		* All detection pipelines were successfully tested offline using stored test images.
	* Live camera stream testing produced mixed results		* Live camera stream testing produced mixed results.
	* People detection and net detection showed the most stable and reliable performance		* People detection and net detection showed the most stable and reliable performance.
	* RViz marker visualization worked correctly for several detection pipelines		* RViz marker visualization worked correctly for several detection pipelines.
	* Cable detection was significantly more unstable and noisy. The cables were sometimes correctly detected ~~and~~ false detections and random line generation frequently occurred		* Cable detection was significantly more unstable and noisy. The cables were sometimes correctly detected, however false detections and random line generation frequently occurred.

	=== Areas for Future Improvement ===		=== Areas for Future Improvement ===

	* Detection parameters and thresholds were not fully tuned. Additional tuning may significantly reduce detection noise, especially for cable detection		* Detection parameters and thresholds were not fully tuned. Additional tuning may significantly reduce detection noise, especially for cable detection.
	* Only people_detection_pose_segmentation.py was verified to work reliably during live testing. The remaining human detection methods were not fully investigated due to time limitations		* Only ''people_detection_pose_segmentation.py'' was verified to work reliably during live testing. The remaining human detection methods were not fully investigated due to time limitations.
	* Additional filtering and depth processing could improve robustness		* Additional filtering and depth processing could improve robustness.
	* Performance optimization may still be required for Raspberry Pi deployment		* Performance optimization may still be required for Raspberry Pi deployment.

	=== RViz Visualization ===		=== RViz Visualization ===

	The original ROS 1 implementation used the jsk-visualization package for RViz markers.		The original ROS 1 implementation used the '''jsk-visualization''' package for RViz markers.

	At the time of this project, jsk-visualization was not fully compatible with ROS 2. Therefore, the system was modified to use built-in ROS 2 MarkerArray visualization messages instead.		At the time of this project, '''jsk-visualization''' was not fully compatible with ROS 2. Therefore, the system was modified to use built-in ROS 2 '''MarkerArray''' visualization messages instead.

	This allowed detected objects and positions to still be visualized in RViz.		This allowed detected objects and positions to still be visualized in RViz.

Electronics

S253734 — Thu, 28 May 2026 18:26:18 GMT

LD19 LiDAR Sensor

← Older revision		Revision as of 20:26, 28 May 2026
Line 139:		Line 139:
	* Typical logic level: 3.3V		* Typical logic level: 3.3V

	More information and full documentation: https://www.elecrow.com/download/product/SLD06360F/LD19_Development%20Manual_V2.3.pdf		More information and full documentation: [https://www.elecrow.com/download/product/SLD06360F/LD19_Development%20Manual_V2.3.pdf LD19_Development Manual]

	=== Realsense D455 ===		=== Realsense D455 ===

Fejemis Vision ROS2

S253734 — Thu, 28 May 2026 18:24:57 GMT

Show changes

Fejemis Vision ROS2

S253734 — Thu, 28 May 2026 18:06:03 GMT

Created page with " == fejemis_vision package == The fejemis_vision package is the computer vision subsystem used in the Fejemis robot platform. It is responsible for: * Human detection * Cable detection * Depth-based segmentation * Pose estimation * Object tracking The package is located in: ''src/fejemis/fejemis_vision'' launch/: Contains ROS 2 launch files used to start the vision system. * ''main-launch.py'' - launch full detection * ''cable_test.launch.py'', ''net_test.launch.p..."

New page

== fejemis_vision package ==

The fejemis_vision package is the computer vision subsystem used in the Fejemis robot platform. It is responsible for:

* Human detection
* Cable detection
* Depth-based segmentation
* Pose estimation
* Object tracking

The package is located in: ''src/fejemis/fejemis_vision''

launch/:
Contains ROS 2 launch files used to start the vision system.

* ''main-launch.py'' - launch full detection
* ''cable_test.launch.py'', ''net_test.launch.py'', ''people_test.launch.py'' - launches individual detection

pyth/:
* main.py - Main ROS 2 vision node
* cable_detection.py - Cable and linear object detection
* net_test.py - Used for testing and validating the net detection pipeline
* people_detection_pose_segmentation.py - Human detection using pose estimation and segmentation
* people_detection_depth_segmentation.py - Human detection using depth-based segmentation
* people_detection_deep_sort.py - Multi-person tracking using DeepSORT

Each detector has a test script to run for testing.These test uses test images to do offline testing of the detection models fromdifferent test images folder.

config/:
* Configuration files allow tuning the perception system without modifying source code.

deep_learning/:
* The deep_learning/ directory contains the neural network models and configuration files used by the vision system for object and human detection.

Setup:

* OpenCV should be installed using "pip install opencv-python"
* The various python packages used can be installed using the requiremtents.txt file by running "pip install requiremtents.txt"
* To run the scripts using roslaunch make sure to set scripts to be executable permissionns:

chmod +x main.py
chmod +x net_test.py
chmod +x people_test_basic.py
chmod +x cable_test.py

* To run the main script:

ros2 launch fejemis_vision main.launch.py

* To run any of the test scripts:

ros2 launch fejemis_vision cable_test.launch.py
ros2 launch fejemis_vision people_test.launch.py
ros2 launch fejemis_vision net.launch.py

== Progress ==

The main work done was to convert this package from ROS1 to compatible with ROS 2. Limited testing was done due to limited time, and more modifying needs to be done.

* Each detections worked on offline testing meaning testing with existing images.

* The result testing each detector from camera stream was mixed. People detection and net detection had the most working detection and displaying the markers in rviz. Cable detectors seems random where it some time detected cables and ofte drawed cables on random places and some time

This can look into:

* The detection parameters was not fully tested and twearked, which can be done to improve the noise expecially for cable detectors.

* From people detection only the people_detection_pose_segmentation.py observed to work. There other was not invastigated due to limited time and can be further invastigate.

* In the original ROS jsk-visualization was used for markering in Rviz. However at the time of this project this package was not compatible in ROS2. Instead inbuilt marker array was used to draw the object in Rviz.

To access the old ROS 1 repository: https://github.com/MP-EL/fejemis_vision

Fejemis Maploc Ros2

S252724 — Thu, 28 May 2026 11:41:40 GMT

Cleaning

← Older revision		Revision as of 13:41, 28 May 2026
(One intermediate revision by the same user not shown)
Line 571:		Line 571:

	These subtrees show the intended full cleaning sequence, although the active ''t_cleaning'' branch currently only navigates to a waypoint and changes mission state.		These subtrees show the intended full cleaning sequence, although the active ''t_cleaning'' branch currently only navigates to a waypoint and changes mission state.
	[[File:cleaning.~~png~~\| 800px]]		[[File:BT-cleaning.jpeg\| 800px]]

	~~Cleanign~~ Node Behaviour Sequence: mission trigger -> waypoint navigation -> coverage path computation -> brush on -> follow coverage path -> brush off -> idle.		Cleaning Node Behaviour Sequence: mission trigger -> waypoint navigation -> coverage path computation -> brush on -> follow coverage path -> brush off -> idle.

	== Configuration Files ==		== Configuration Files ==

File:BT-cleaning.jpeg

S252724 — Thu, 28 May 2026 11:40:02 GMT

S252724 uploaded File:BT-cleaning.jpeg

New page

Mechanics

S252724 — Thu, 28 May 2026 11:12:59 GMT

Main Mechanical Parts

← Older revision		Revision as of 13:12, 28 May 2026
(8 intermediate revisions by the same user not shown)
Line 12:		Line 12:
	== Main Mechanical Parts ==		== Main Mechanical Parts ==

	=== Front Wheel ~~Design~~ ===		=== Front Wheel ===
			The front wheel plays an important role in the robot’s movement and overall cleaning performance. It helps guide and steer the robot as it moves through the environment, allowing it to turn, follow paths, and navigate around obstacles while cleaning. As a result, the stability and rigidity of the front wheel directly affect both motion accuracy and mapping quality.

	The ~~rigidity of the~~ front wheel was ~~a significant flaw~~ of the robot, ~~affecting the~~ odometry and ~~the~~ movement. ~~We improve it by adding ball bearings, increasing~~ the ~~infill~~ of ~~the 3D printed parts~~ and ~~fixing correctly the magnetic encoder~~.		==== Previous Design ====
			The original front wheel assembly was one of the main mechanical weaknesses of the robot. Its low rigidity caused wobbling during motion, which negatively affected odometry and reduced movement stability. This introduced drift in the generated map and lowered the overall quality of localization and navigation.

	~~This changes had a great effect in~~ the ~~performance~~ of the ~~robot~~. ~~But there are things that can be enhance~~.		==== Current Design ====
			The wheel assembly was redesigned by adding ball bearings, increasing the infill of the 3D-printed parts, and mounting the magnetic encoder more securely. These changes improved rigidity, produced steadier motion, and reduced map drift.

	The support that ~~fix~~ the linear actuator to the robot ~~must~~ be reprinted~~. Increasing the~~ infill and ~~the width of the two thin~~ walls ~~in the sides~~.		The updated design is available at this link: https://cad.onshape.com/documents/d35a3b26eb917ad7000d2d0c/w/821c3ada1e18c2055d92ea08/e/35b8a6b1c67d3640704aa6e7 as a downloadable ZIP file for future modification and improvement.

			==== Future Work ====
			Although the redesigned front wheel performs better, the current structure still relies on plastic components that may loosen, deform, or wear over time during repeated use. Future work should evaluate whether a tighter mechanical design, a stronger filament material, or a different material altogether would provide better long-term rigidity and durability.

			Another component that should be improved is the support that attaches the linear actuator to the robot. This part should be reprinted with higher infill and thicker side walls to increase its strength and reduce flex during operation. Future team members can assess whether these further changes are necessary based on long-term use and observed wear.

Fejemis Maploc Ros2

S252724 — Thu, 28 May 2026 10:29:39 GMT

Notes and Future Work

← Older revision		Revision as of 12:29, 28 May 2026
(One intermediate revision by the same user not shown)
Line 571:		Line 571:

	These subtrees show the intended full cleaning sequence, although the active ''t_cleaning'' branch currently only navigates to a waypoint and changes mission state.		These subtrees show the intended full cleaning sequence, although the active ''t_cleaning'' branch currently only navigates to a waypoint and changes mission state.
			[[File:cleaning.png\| 800px]]

	~~'''Diagram placeholder:''' cleaning behaviour sequence~~: mission trigger -> waypoint navigation -> coverage path computation -> brush on -> follow coverage path -> brush off -> idle.		Cleanign Node Behaviour Sequence: mission trigger -> waypoint navigation -> coverage path computation -> brush on -> follow coverage path -> brush off -> idle.

	== Configuration Files ==		== Configuration Files ==
Line 638:		Line 639:
	* Clarify which Raspberry Pi should run each launch file in the final deployment.		* Clarify which Raspberry Pi should run each launch file in the final deployment.
	* Expand the cleaning behaviour section once ''t_cleaning'' is connected to ''f_get_area_to_clean'' and ''f_clean_area'' in the active tree.		* Expand the cleaning behaviour section once ''t_cleaning'' is connected to ''f_get_area_to_clean'' and ''f_clean_area'' in the active tree.
			* Test and validate the complete cleaning behaviour structure in the final hardware setup, as it has not yet been fully evaluated due to current Raspberry Pi limitations.

File:Cleaning.png

S252724 — Thu, 28 May 2026 10:25:23 GMT

S252724 uploaded File:Cleaning.png

New page

Fejemis Maploc Ros2

S252724 — Thu, 28 May 2026 10:13:43 GMT

Mapping

← Older revision		Revision as of 12:13, 28 May 2026
(2 intermediate revisions by the same user not shown)
Line 515:		Line 515:
	* mission_sub: ''idle''		* mission_sub: ''idle''

	This keeps the robot in a waiting state.		This keeps the robot in a waiting state. Sensors, telemetry, and subscriptions remain active, but no movement commands are issued. The robot leaves this state when a new mission is received through ''/behavior/set_mission''.

	=== Calibration ===		=== Calibration ===
Line 524:		Line 524:

	* Requires mission ''calib/line''.		* Requires mission ''calib/line''.
	* Drives forward using ''DriveOnHeading'' ~~for~~ ''calib_sq_dist'' at 0.05 m/s.		* Drives forward using ''DriveOnHeading''
			* ''calib_sq_dist'' is set to 0.05 m/s during initialization.
	* Returns to idle.		* Returns to idle.

Line 533:		Line 534:
	* Each side drives forward and spins 1.57 rad.		* Each side drives forward and spins 1.57 rad.
	* Returns to idle.		* Returns to idle.
			Each ''f_calib_side'' contains:

			*DriveOnHeading
			*Spin
			*A quarter-turn style calibration step
			Calibration succeeds when each action in the sequence completes successfully.

	=== Mapping ===		=== Mapping ===

	''t_mapping'' currently checks for ~~mission~~ ''mapping/*'' and then returns to idle. This branch ~~is a placeholder for future~~ autonomous mapping ~~behaviour~~.		''t_mapping'' currently checks for ''mission mapping/*'' and then returns to idle.

			Requires mission mapping/

			*Currently acts as a placeholder

			*Does not yet launch the SLAM or exploration pipeline

			*Returns to idle immediately

			This branch should later be expanded to perform autonomous mapping, localization checks, and map saving.

	=== Cleaning ===		=== Cleaning ===

Fejemis 2026

S253809 — Thu, 28 May 2026 09:17:40 GMT

Mission Statement

← Older revision		Revision as of 11:17, 28 May 2026
Line 133:		Line 133:

	== Mission Statement ==		== Mission Statement ==
			Fejemis is developed to autonomously sweep the ASTA building in a safe and practical way for daily operations.

			The robot should:
			* Navigate autonomously through the building and reach assigned cleaning areas.
			* Plan and execute a full cleaning strategy instead of only following a single manual path.
			* Interrupt its cleaning mission when needed to return to a docking station for charging, then resume operation.
			* Avoid interfering with ongoing work in the ASTA building by operating safely around people and active tasks.

Fejemis ROS2 Software

S253809 — Thu, 28 May 2026 09:07:45 GMT

Convenience commands

← Older revision		Revision as of 11:07, 28 May 2026
(One intermediate revision by the same user not shown)
Line 160:		Line 160:
	On each Pi that needs software from the repository, clone the workspace and run the provided install scripts:		On each Pi that needs software from the repository, clone the workspace and run the provided install scripts:

	~~```bash~~		git clone https://github.com/Melvin-Angel/Fejemis_Workspace_2026.git
	git clone https://github.com/Melvin-Angel/Fejemis_Workspace_2026.git		cd Fejemis_Workspace_2026
	cd Fejemis_Workspace_2026		./install.sh
	./install.sh		source ./activate.sh
	source ./activate.sh
	~~```~~

	4. Camera / sensor hosts		4. Camera / sensor hosts
Line 183:		Line 181:
	* ''fejemis launch_aux'' — start a launch file on an auxiliary Pi from the primary Pi. This is commonly used to start camera or sensor nodes remotely. Example:		* ''fejemis launch_aux'' — start a launch file on an auxiliary Pi from the primary Pi. This is commonly used to start camera or sensor nodes remotely. Example:

	~~```bash~~		fejemis launch_aux fejemis robot.launch.py
	fejemis launch_aux fejemis robot.launch.py
	~~```~~

	* ''fejemis sync_clocks'' — synchronise system clocks across Pis (uses SSH and sudo on targets). Run this before recording or starting perception stacks so timestamps align. Example:		* ''fejemis sync_clocks'' — synchronise system clocks across Pis (uses SSH and sudo on targets). Run this before recording or starting perception stacks so timestamps align. Example:

	~~```bash~~		fejemis sync_clocks
	fejemis sync_clocks
	~~```~~

	== Network Configuration ==		== Network Configuration ==

Fejemis Description ROS2

S253809 — Thu, 28 May 2026 09:04:54 GMT

Typical Usage

← Older revision		Revision as of 11:04, 28 May 2026
Line 110:		Line 110:

	Start robot description publisher:		Start robot description publisher:
			ros2 launch fejemis_description model.launch.py
	~~```bash~~
	ros2 launch fejemis_description model.launch.py
	~~```~~

	Start with simulation time:		Start with simulation time:
			ros2 launch fejemis_description model.launch.py use_sim_time:=true
	~~```bash~~
	ros2 launch fejemis_description model.launch.py use_sim_time:=true
	~~```~~

	In most full-system runs, this launch file is included by top-level bringup (for example in simulation launch stacks).		In most full-system runs, this launch file is included by top-level bringup (for example in simulation launch stacks).

Fejemis Bridge ROS2

S253745 — Thu, 28 May 2026 09:03:59 GMT

Show changes

Fejemis Description ROS2

S253809 — Thu, 28 May 2026 09:03:59 GMT

Created page with "Back to Fejemis ROS2 Software == Purpose == ''fejemis_description'' is the robot description package for Fejemis. It defines the robot model using URDF/Xacro and publishes the TF model state so the rest of the ROS 2 stack can use a consistent robot geometry. The package is responsible for: * Building the Fejemis robot model from modular xacro files. * Publishing ''robot_description'' and TF through ''robot_state_publisher''. * Providing a simulation-friendly whee..."

New page

Back to [[Fejemis ROS2 Software]]

== Purpose ==

''fejemis_description'' is the robot description package for Fejemis. It defines the robot model using URDF/Xacro and publishes the TF model state so the rest of the ROS 2 stack can use a consistent robot geometry.

The package is responsible for:

* Building the Fejemis robot model from modular xacro files.
* Publishing ''robot_description'' and TF through ''robot_state_publisher''.
* Providing a simulation-friendly wheel configuration through launch arguments.
* Keeping a shared frame and link structure used by simulation, mapping, and navigation.

== Package Layout ==

Important folders:

* ''launch'' - launch files for model generation and state publishing.
* ''xacro'' - modular robot model definition files.
* ''config'' - controller/simulation-related configuration.

Main xacro files:

* ''xacro/robot.urdf.xacro'' - top-level robot assembly file.
* ''xacro/robot_core.xacro'' - chassis and base links.
* ''xacro/robot_wheels.xacro'' - drive wheels and Gazebo diff-drive plugin.
* ''xacro/robot_castor.xacro'' - castor wheel definition.
* ''xacro/sensor_imu.xacro'' - IMU and magnetometer links/sensors.
* ''xacro/sensor_lidar.xacro'' - LiDAR link and simulated scan sensor.
* ''xacro/sensor_depth_camera.xacro'' - depth camera and optical frame.
* ''xacro/utils_inertial.xacro'' and ''xacro/utils_colors.xacro'' - reusable inertial and visual macros.

== Launch File ==

=== launch/model.launch.py ===

This launch file generates the URDF from xacro and starts ''robot_state_publisher''.

Launch arguments:

* ''use_sim_time'' - enables simulation clock when ''true''. Default: ''false''.

Behavior:

* Processes ''fejemis_description::xacro/robot.urdf.xacro'' with xacro.
* Passes ''fixed_wheels:=<use_sim_time>'' into xacro.
* Publishes ''robot_description'' parameter to ''robot_state_publisher''.
* Publishes the model TF tree for downstream packages.

== Model Composition ==

The top-level model in ''robot.urdf.xacro'' assembles the robot in this order:

* Core chassis: ''xacro:core''
* Drive wheels: ''xacro:wheels''
* Castor wheel: ''xacro:castor''
* IMU and magnetometer: ''xacro:imu_sensor''
* LiDAR: ''xacro:lidar''
* Depth camera: ''xacro:depth''

There is also an optional camera macro (currently commented in the top-level xacro).

== Main Links and Frames ==

Common links/frames provided by the description:

* ''base_link'' - primary base frame for navigation and odometry integration.
* ''chassis'' - main physical body link.
* ''left_wheel'' and ''right_wheel'' - drive wheel links.
* ''laser_frame'' - LiDAR mounting and scan frame in simulation.
* ''imu_link'' - IMU and magnetometer frame.
* ''depth_link'' and ''depth_link_optical'' - depth camera body and optical frame.

These frames are consumed by mapping/localisation and simulation bridge layers.

== Simulation-Specific Behavior ==

The wheel macro supports both fixed and rotating wheel joints:

* Real robot path: wheel joints are fixed in the model launch context.
* Simulation path: wheels are set to continuous joints when simulation mode is enabled.

Gazebo systems configured in ''robot_wheels.xacro'':

* ''gz::sim::systems::DiffDrive''
* ''gz::sim::systems::JointStatePublisher''

Diff-drive plugin settings include:

* Wheel separation: ''0.3847''
* Wheel diameter: ''0.2''
* Command topic: ''/model/fejemis/cmd_vel''
* Odometry topic: ''/model/fejemis/odom''
* Frame IDs: ''odom'' and ''base_link''

Drive wheel friction is increased in simulation to reduce slip, while castor behavior is defined separately in the castor xacro.

== Sensor Simulation Topics ==

The description also defines simulated sensor outputs used by the bridge layer:

* LiDAR: ''/model/fejemis/scan''
* IMU: ''/model/fejemis/imu''
* Magnetometer: ''/model/fejemis/mag''
* Depth camera: ''/model/fejemis/depth_camera''

These topics are later bridged into ROS topics by ''fejemis_sim''.

== Typical Usage ==

Start robot description publisher:

```bash
ros2 launch fejemis_description model.launch.py
```

Start with simulation time:

```bash
ros2 launch fejemis_description model.launch.py use_sim_time:=true
```

In most full-system runs, this launch file is included by top-level bringup (for example in simulation launch stacks).

== Relationship To Other Packages ==

* ''fejemis_sim'' uses this package to spawn the robot from ''/robot_description''.
* ''fejemis_maploc'' and Nav2 depend on the frame structure defined here.
* Sensor and odometry pipelines assume the link names and frame conventions from this model.

Fejemis 2026

S253809 — Thu, 28 May 2026 08:56:51 GMT

Troubleshooting / usual problems

← Older revision		Revision as of 10:56, 28 May 2026
(One intermediate revision by the same user not shown)
Line 69:		Line 69:

	If Fejemis crash (one of the battery display will turn off), you need to plug it in before turning it on again.		If Fejemis crash (one of the battery display will turn off), you need to plug it in before turning it on again.

			=== Troubleshooting / usual problems ===

			Common issues seen during daily operation:

			*'''Main Raspberry Pi crashes while building the full workspace'''
			The main Raspberry Pi may crash or run out of resources when building everything at once.
			Use symlink install and only build the packages you changed:

			colcon build --symlink-install --packages-select <changed_package_1> <changed_package_2>

			*'''Robot shuts down while driving (high speed / acceleration)'''
			If commanded speed or acceleration is too aggressive, the battery management system can cut power and both Raspberry Pis may shut down.
			Reduce drive aggressiveness and avoid sudden acceleration spikes.

			*'''System behaves inconsistently between main and aux Pi'''
			This is often caused by the two Raspberry Pis having unsynchronised clocks.
			Run this from the main Raspberry Pi:

			fejemis sync_clocks

			*'''Only one Raspberry Pi appears to boot'''
			You must hold the power button for a few seconds so both Raspberry Pis start correctly.

			*'''Left battery does not engage after BMS cutoff'''
			If the left battery turns off due to battery management protection, plug in the robot before booting again, otherwise that battery may not re-engage.

			*'''Unstable wireless connection in ASTA'''
			Wi-Fi in ASTA is often unreliable. Prefer connecting your PC over Ethernet for stable control and monitoring.

	=== Other utilities ===		=== Other utilities ===

Fejemis Bridge ROS2

S253745 — Thu, 28 May 2026 08:51:38 GMT

Fejemis Bridge — Design, flow and file map

← Older revision		Revision as of 10:51, 28 May 2026
Line 1:		Line 1:
	Back to [[Fejemis ROS2 Software]]		Back to [[Fejemis ROS2 Software]]

	== Fejemis Bridge ~~— Design, flow and file map~~ ==		== Fejemis Bridge ==

	=== Purpose ===		=== Purpose ===

Fejemis Bridge ROS2

S253745 — Thu, 28 May 2026 08:51:22 GMT

Created page with "Back to Fejemis ROS2 Software == Fejemis Bridge — Design, flow and file map == === Purpose === `fejemis_bridge` translates the Teensy serial protocol into typed ROS2 messages and back. This page explains the runtime flow, the core files to edit, and the small number of extension points developers need. === Overview === The bridge runs as a ROS2 node that creates two serial sources (`front` and `drive`). Each source registers lightweight "proxies" that convert be..."

New page

Back to [[Fejemis ROS2 Software]]

== Fejemis Bridge — Design, flow and file map ==

=== Purpose ===
`fejemis_bridge` translates the Teensy serial protocol into typed ROS2 messages and back. This page explains the runtime flow, the core files to edit, and the small number of extension points developers need.

=== Overview ===
The bridge runs as a ROS2 node that creates two serial sources (`front` and `drive`). Each source registers lightweight "proxies" that convert between device text prefixes and ROS messages. Low-level framing, CRC, confirmation and retry are handled by the shared `raubase` serial layer.

=== Primary components ===
* `bridge` node — wrapper around `raubase::SerialBridge` that registers sources and parameters. (`src/bridge/main.cpp`, `include/fejemis_bridge/bridge.hpp`)
* `SerialSource` subclasses — device-specific handlers that run the TRX loop and own proxies (`include/fejemis_bridge/sources/*`, `src/bridge/sources/*`).
* Proxies — single-purpose adapters mapping device prefixes ↔ ROS messages (`include/fejemis_bridge/proxies.hpp`, `src/bridge/proxies/*`).
* `raubase` serial core — framing, CRC, confirm/resend, queues (`deps/raubase_core/.../message.hpp`, `.../source_txrx.cpp`).

=== Key files (quick map) ===
* `include/fejemis_bridge/bridge.hpp` — registers `FrontTeensy` and `DriveTeensy`.
* `src/bridge/sources/*.cpp` — source constructors (where proxies are registered).
* `include/fejemis_bridge/proxies.hpp` and `src/bridge/proxies/*.cpp` — proxy declarations and conversions.
* `config/bridge.yaml` — runtime parameters (proxies, rates, device defaults).

=== Runtime flow (short) ===
1. Bridge constructs sources and registers proxies.
2. Each source runs a TRX loop: read bytes → assemble framed line → validate CRC → dispatch to proxy; and handle TX queue → send messages → wait for confirm if requested.
3. Inbound: device line → proxy `from_device()` → publish ROS message.
4. Outbound: ROS message → proxy `to_device()` → enqueue `Message` → TRX loop sends (CRC added).

=== Message framing (exact) ===
* Frame start: `;` (CRC prefix starts immediately after).
* CRC: 3-char prefix `;NN` (computed by `Message::generateCRC`).
* Terminator: `\n` (newline).
* Confirmation: messages may request confirmation (`!` flag); confirmations are matched to queue head and cause the entry to be popped.

=== Proxies and topics (simple) ===
Proxies are tiny adapters. For each proxy you should know three things:
1. Device prefix it handles (e.g. `hbt`, `fwl`, `manage`).
2. Which ROS message type it publishes/subscribes.
3. Which source (front/drive) it is registered with.

Inbound example:
* `;NNhbt 123 1\n` → `SerialSource` strips CRC → finds `hbt` proxy → `hbt` proxy parses payload → publishes `Heartbeat` message.

Outbound example:
* Publish `DriveManage` with `cmd_type=START_MOTORS` → Drive proxy formats `manage start` → bridge sends `;NNmanage start\n` to Teensy.

Where to find exact topic names: open the proxy implementation in `src/bridge/proxies/*.cpp` — it shows the publisher/subscriber topic strings and message types used.

=== Extension (what to edit) ===
To add a new device message:
* Add or reuse a ROS `msg` (if needed).
* Implement conversions in a new proxy (`src/bridge/proxies/YourProxy.cpp`).
* Declare the proxy in `include/fejemis_bridge/proxies.hpp` and register it in the appropriate source constructor (`src/bridge/sources/*`).
* Optionally add parameters to `config/bridge.yaml`.

=== Troubleshooting (short) ===
* CRC failures: check RX logs (CRC check messages) — invalid CRC means device or framing differs.
* Missing confirmations: inspect `source_txrx.cpp` logs for timeouts and resend messages; check `timeout_confirm` / `max_resend` in `SourceConfig`.
* Swapped serial ports: verify `front_device` and `drive_device` parameters and use `/dev/serial/by-id/*` symlinks if needed.

=== Quick checklist to include in the wiki ===
* Parameters & defaults: `front_device`, `drive_device`, `timeout_confirm`, `max_resend` (see `bridge.hpp` and `source` config).
* Proxy → prefix → topic → msg table (optional, can be generated from `src/bridge/proxies`).
* One inbound and one outbound framed example (in Message framing section).

Dependencies Index

S253809 — Thu, 28 May 2026 08:43:06 GMT

Building and Recommendations

← Older revision		Revision as of 10:43, 28 May 2026
(5 intermediate revisions by the same user not shown)
Line 5:		Line 5:
	This page summarises the main vendored dependencies under ``src/deps`` and their role in the Fejemis stack. The repository keeps these in-tree to avoid mismatched versions and to make development reproducible.		This page summarises the main vendored dependencies under ``src/deps`` and their role in the Fejemis stack. The repository keeps these in-tree to avoid mismatched versions and to make development reproducible.

	-- Fields2Cover		=== Fields2Cover ===

	Purpose: Complete coverage path planning library providing swath generation, headland generation, route ordering, and path smoothing.		'''Purpose:''' Complete coverage path planning library providing swath generation, headland generation, route ordering, and path smoothing.

	Where used: ``opennav_coverage`` and Fejemis coverage planners.		Where used: ``opennav_coverage`` and Fejemis coverage planners.

	Notes: Prefer the workspace copy (``src/deps/Fields2Cover``) when building — installing a distro package can produce header/ABI conflicts.		'''Notes:''' Prefer the workspace copy (``src/deps/Fields2Cover``) when building — installing a distro package can produce header/ABI conflicts.

	-- ldlidar_stl_ros2		=== ldlidar_stl_ros2 ===

	Purpose: Driver and adapter for the LD-series LiDAR hardware used on Fejemis. Publishes 2D scans used by SLAM and Nav2.		'''Purpose:''' Driver and adapter for the LD-series LiDAR hardware used on Fejemis. Publishes 2D scans used by SLAM and Nav2.

	Where used: ``fejemis_maploc`` LiDAR bringup and Nav2 costmaps.		Where used: ``fejemis_maploc`` LiDAR bringup and Nav2 costmaps.

	Notes: Launch configuration often exposes serial port and container placement arguments (see ``launch/lidar.launch.py``).		'''Notes:''' Launch configuration often exposes serial port and container placement arguments (see ``launch/lidar.launch.py``).

	-- opennav_coverage		=== opennav_coverage ===

	Purpose: Wraps Fields2Cover into ROS 2 lifecycle components and provides a Nav2-compatible Complete Coverage Task Server.		'''Purpose:''' Wraps Fields2Cover into ROS 2 lifecycle components and provides a Nav2-compatible Complete Coverage Task Server.

	Where used: Optional coverage navigation component integrated by ``fejemis_maploc`` when coverage support is enabled.		Where used: Optional coverage navigation component integrated by ``fejemis_maploc`` when coverage support is enabled.

	Notes: Depends on Fields2Cover; keep both workspace copies consistent.		'''Notes:''' Depends on Fields2Cover; keep both workspace copies consistent.

	-- raubase_core		=== raubase_core ===

	Purpose: Core robot control messages, adapters, and helpers (includes ``RoverCommand``, ``rover_2_twist`` adapter, and mixers).		'''Purpose:''' Core robot control messages, adapters, and helpers (includes ``RoverCommand``, ``rover_2_twist`` adapter, and mixers).

	Where used: Bridge and simulator control paths; adapters that keep simulation and real hardware command interfaces aligned.		Where used: Bridge and simulator control paths; adapters that keep simulation and real hardware command interfaces aligned.

	Notes: Building ``raubase_core`` alongside simulation ensures consistent message formats for Gazebo and the real robot.		'''Notes:''' Building ``raubase_core`` alongside simulation ensures consistent message formats for Gazebo and the real robot.

	-- ros_arcana (arcana_python, arcana_tools)		=== ros_arcana (arcana_python, arcana_tools) ===

	Purpose: Small utility libraries and launch helpers used across the workspace (xacro helpers, launch conveniences, python utilities).		Purpose: Small utility libraries and launch helpers used across the workspace (xacro helpers, launch conveniences, python utilities).
Line 47:		Line 47:
	== Building and Recommendations ==		== Building and Recommendations ==

	- Build the workspace copy of deps first so downstream packages use the in-tree install. Example:		* Build the workspace copy of deps first so downstream packages use the in-tree install. Example:
			colcon build --symlink-install --packages-up-to fields2cover
			colcon build --symlink-install

	``~~`bash~~		* If you previously installed a system package (for example ``ros-jazzy-fields2cover``), uninstall it if you want the workspace copy to be authoritative. Use your system package manager (``apt remove ros-jazzy-fields2cover``) with care; sudo is required.
	~~colcon build~~ --~~symlink~~-~~install~~ -~~-packages-up-to~~ fields2cover
	~~colcon build --symlink-install~~
	```

	- If you previously installed a system package (for example ``ros-jazzy-fields2cover``), uninstall it if you want the workspace copy to be authoritative. Use your system package manager (``apt remove ros-jazzy-fields2cover``) with care; sudo is required.		* If a build fails with missing headers, check that the workspace-installed ``fields2cover`` CMake config is being found (see CMakeCache or the ``build/*/CMakeFiles/CMakeConfigureLog.yaml`` entries).

	- If a build fails with missing headers, check that the workspace-installed ``fields2cover`` CMake config is being found (see CMakeCache or the ``build/*/CMakeFiles/CMakeConfigureLog.yaml`` entries).

	~~If you want, I can expand individual sections with example launch commands, config locations, and common troubleshooting notes~~.

Dependencies Index

S253809 — Thu, 28 May 2026 08:38:40 GMT

Created page with "Back to Fejemis ROS2 Software == Dependencies Index == This page summarises the main vendored dependencies under ``src/deps`` and their role in the Fejemis stack. The repository keeps these in-tree to avoid mismatched versions and to make development reproducible. -- Fields2Cover Purpose: Complete coverage path planning library providing swath generation, headland generation, route ordering, and path smoothing. Where used: ``opennav_coverage`` and Fejemis covera..."

New page

Back to [[Fejemis ROS2 Software]]

== Dependencies Index ==

This page summarises the main vendored dependencies under ``src/deps`` and their role in the Fejemis stack. The repository keeps these in-tree to avoid mismatched versions and to make development reproducible.

-- Fields2Cover

Purpose: Complete coverage path planning library providing swath generation, headland generation, route ordering, and path smoothing.

Where used: ``opennav_coverage`` and Fejemis coverage planners.

Notes: Prefer the workspace copy (``src/deps/Fields2Cover``) when building — installing a distro package can produce header/ABI conflicts.

-- ldlidar_stl_ros2

Purpose: Driver and adapter for the LD-series LiDAR hardware used on Fejemis. Publishes 2D scans used by SLAM and Nav2.

Where used: ``fejemis_maploc`` LiDAR bringup and Nav2 costmaps.

Notes: Launch configuration often exposes serial port and container placement arguments (see ``launch/lidar.launch.py``).

-- opennav_coverage

Purpose: Wraps Fields2Cover into ROS 2 lifecycle components and provides a Nav2-compatible Complete Coverage Task Server.

Where used: Optional coverage navigation component integrated by ``fejemis_maploc`` when coverage support is enabled.

Notes: Depends on Fields2Cover; keep both workspace copies consistent.

-- raubase_core

Purpose: Core robot control messages, adapters, and helpers (includes ``RoverCommand``, ``rover_2_twist`` adapter, and mixers).

Where used: Bridge and simulator control paths; adapters that keep simulation and real hardware command interfaces aligned.

Notes: Building ``raubase_core`` alongside simulation ensures consistent message formats for Gazebo and the real robot.

-- ros_arcana (arcana_python, arcana_tools)

Purpose: Small utility libraries and launch helpers used across the workspace (xacro helpers, launch conveniences, python utilities).

Where used: Launch utilities, xacro handling, and small tooling used by multiple packages (e.g., ``fejemis_sim`` uses arcana launch helpers).

Notes: These packages are lightweight but important for consistent launch behaviour across machines and ROS distros.

== Building and Recommendations ==

- Build the workspace copy of deps first so downstream packages use the in-tree install. Example:

```bash
colcon build --symlink-install --packages-up-to fields2cover
colcon build --symlink-install
```

- If you previously installed a system package (for example ``ros-jazzy-fields2cover``), uninstall it if you want the workspace copy to be authoritative. Use your system package manager (``apt remove ros-jazzy-fields2cover``) with care; sudo is required.

- If a build fails with missing headers, check that the workspace-installed ``fields2cover`` CMake config is being found (see CMakeCache or the ``build/*/CMakeFiles/CMakeConfigureLog.yaml`` entries).

If you want, I can expand individual sections with example launch commands, config locations, and common troubleshooting notes.

Fejemis ROS2 Software

S253809 — Thu, 28 May 2026 08:38:13 GMT

← Older revision		Revision as of 10:38, 28 May 2026
(One intermediate revision by the same user not shown)
Line 10:		Line 10:
	* Hardware bridge and low-level microcontroller integration (the Fejemis bridge).		* Hardware bridge and low-level microcontroller integration (the Fejemis bridge).
	* The ROS 2 software stack for mapping, perception, and high-level behaviours (the Fejemis ROS2 workspace).		* The ROS 2 software stack for mapping, perception, and high-level behaviours (the Fejemis ROS2 workspace).

			In this page we focus on the ROS 2 software stack to learn more about the low-level microcontroller integration see [[Fejemis bridge]] and [[Fejemis repository]]

	== Fejemis ==		== Fejemis ==
Line 136:		Line 138:
	* ''test_static_tf'' - adds a temporary static transform for camera frame testing.		* ''test_static_tf'' - adds a temporary static transform for camera frame testing.
	* The main vision node also loads ''config/main.yaml'' and uses ''use_sim_time=False'' in this launch file.		* The main vision node also loads ''config/main.yaml'' and uses ''use_sim_time=False'' in this launch file.

			== Dependencies (src/deps) ==

			The repository vendors a set of third-party and support packages under ``src/deps``. These are kept in-tree to ensure reproducible builds and known-good versions for Fejemis.

			For a short index and per-package summaries see [[Dependencies Index]].

	== Multi pi setup ==		== Multi pi setup ==