I’m currently working on a Qt-based application to control the EduArt robot from my PC using ROS2. However, I’m struggling to find comprehensive documentation on the ROS interface for EduArt, especially details on all parameters, topics, and service calls. If anyone knows of well-documented resources for this, I’d be very grateful!
Additionally, I’m encountering an issue when trying to set the robot’s mode. The robot briefly accepts the mode change to “remote controlled,” but it immediately switches back to “inactive.” Has anyone else run into this problem or have any insights into why this might be happening?
Since I’m new to EduArt robots, any guidance on where to start—particularly with software resources or documentation that would help me get up to speed—would be greatly appreciated.
Hey @meltabakh97,
Cool idea with the QT-app!
I’ve seen many people do this sort of stuff - it’s a great way to visualize basic data while driving.
But if you want to visualize sensor data (such as LiDAR), rviz2 is an already fantastic solution - you don’t have to re-invent the wheel
First of all, can you tell us your software/hardware setup?
EduArt either use the raspi shield (left) or the ethernet shield (right)
These use edu_drive_ros2 (raspi) or edu_robot (ethernet)
(The IOT shield also is edu_robot)
edu_robot uses custom ROS2 messages, which means you need to install (and source) it on every computer that should communicate with edu_robot.
After that you can use the messages like any other ros2 message type.
Changing back to inactive is a intended safety feature.
You need to repeatedly send Data (usually cmd_vel or joy), or else the control node will automatically disable the motors.
This is a countermeasure against connection loss and lag (so you don’t crash into a wall when it happens).
As for ROS docs - here are some tutorials for making ROS clients (aka your app),
that wiki has almost everything you’ll need.
I’ve also found AI chatbots to be rather helpful with ROS code.
Your plan sounds interesting. I can’t wait to see what you come up with.
Regarding your questions: have a look at the interfaces to our Eduard robots documented here. We generally write the documentation for Eduard in the software package “edu_robot”. Just go to Github and follow the links in the readme. If something is missing, just let us know via the forum.
Unfortunately, I don’t know which hardware variant you have at the moment, but in general the following must be considered in order to get the robot “ready to drive”.
A speed command must be sent continuously. If none is sent for 500ms, the robot deactivates.
therefore send twist messages continuously, then change the mode.
If the emergency stop is pressed, the robot will deactivate again immediately.
And the robot must not be connected to the charger.
If you tell me what hardware you have, I can show you and explain the parameters.
