Menü
Aktuelles
Von:
Filter

Robot operating system (ROS) for Ardumower - Thoughts, Exploring, Brainstorming, Loud-thinking

AlexanderG

AlexanderG

Lawn robot freak and project co-founder
Teammitglied
Hello,
Maybe you have heard of it, or maybe not : ROS (robot operating system: https://www.ros.org/) - I wonder if this could be an interesting (experimental and also end-user) software platform for the Ardumower. I'm not talking about hardware here (that can be solved quickly, so please do not talk about hardware here) - I'm talking about software here and specifically which ROS software components could be useful for an Ardumower.

So what are the ROS concepts?
  • localization : 'localization' is the process of estimating the position (X, Y) and orientation (delta) of the robot on the ground based on one or more sensors and sensor fusion (if more sensors are used)

    1592820695319.png

  • robot kinematic model : a 'kinematic model' describes the robot's dimensions and its control point (the point that describes the position of the robot and how that point can actually move based on the robot's kinematic model and dimensions)

    1592820745227.png

  • coverage planning : the 'coverage planner' plans all the waypoints based on the given perimeter and exclusions

    1592820807059.png

  • path planning : the 'path planner' plans the trajectory to get to the next waypoint and considers the robot's kinematic (dimensions and control point), dynamic obstacles, fixed obstacles and other contraints like speed

    1592820834251.png

So, which ROS modules (ROS melodic) could be useful for an Ardumower?

localization (sensors and sensor fusion):

coverage planning:

path planning:
simulator prototype:

You probably have found more interesting ROS modules! Feel free to post further ideas for ROS components that could be useful for an Ardumower and that should be tried out when starting real-world ROS experiments (additional ROS modules for interesting sensors, sensor fusion, localization, coverage planning, path planning, etc.).

Happy Ardumowing!

Regards,
Alexander
 
Zuletzt bearbeitet:
Update: Compiled ROS on a Raspberry PI3 today and quickly tried out path planning on it (teb_local_planner) with simulation - It seems the local planner could need a little bit more CPU power (as it complains in the ROS console)...
 
Zuletzt bearbeitet:
Hi Alexander,

I have no experience with Ardumower jet, because my lawn will start growing in september ;-) until now I only read the forum.
But I think ROS is a very interesting thing for Ardumower.
Unfortunately I'm not a good programmer so I only can support the Ideas and test the software :)

Best regards
 
Hello Alexander,


I´m completely new here and don´t have a mower (yet), therefore this is just a comment from someone with little knowledge but current interest.

The ROS usage sounds like a very good idea from the standpoint of future-proof and reliable software. This will also allow faster development as more people will develop their own ROS modules which ardumower can use. The typical problem could be abandoned libraries etc., but on the other hand new developer could be attracted for the project.
On the other hand: Does the ardumower project really need all of this possible features? What is the vision of the project after the current RTK solution? I understand that this is the project goal from the beginning. Mowing without perimeter in a structured way. From what I´ve read you are near a ready-to-use implementation.

As you don´t want the hardware discussion here, I´ll just add my current thoughts in a short way:
I haven´t bought the ardumower kit yet as I´m very price sensible. I see that the offered / used components are well selected and worth their price. But my current idea is to use 2-3 ESP32 as they are cheaper (and more powerful) than the due and also have wlan and BT onboard while being (more or less) compatible with your current code. Maybe the RTL WLAN shield (~60€) could be supplemented with them, too. If someone is interested in this idea I could open up a new thread.
To keep it short: From my perspective ROS will higher the price of the ardumower even further as you need more capable-hardware and storage.

Best regards
Chris
 
Hi,

after months of not visiting Ardumower Forum, I'm back and want really to bring my Ardumower to ROS. Currently I run Azurit which works good so far but I want to try something new.

Before diving deep into thousands of ROS packages,I want to get low level firmware done first. From my understanding, a lawn mower is nothing more than a turtlebot. I want to recycle as much as possible from my mower projects, so Hardware (I know you didn't want to discuss), will be old PCB 1.2 as starting point. This will be connected to ROS core by rosserial either direct (USB) or remotely by wifi. ROS itself can run on RPI or Jetson inside the mower, on a stationary PC or where ever you want.

My first goal will be to build a firmware for Ardumower which is able to be used with ROS. I know Azurit already has some ROS capabilities but it brings too much code which will be obsolete when using ROS. So I want to have a clean, working code.

Couple of months ago, I started to remove any unnecessary code out of Azurit. It has still some Bluetooth capabilities (settings, manual control, debug) and will be able to track perimeter wire (will stick to this first as it is the cheapest solution). But I'm not sure if this is the right way or if I should start from scratch instead.

My current plan is like this:
- low level settings can be done at mower like we do today (sensor settings, activate bumper sonar perimeter etc.) Depending on this, robot will trigger only activated sensors
- Firmware will always stop mower when any sensor gets triggered. Also it will always stop if any communication error occur (no ROS messages since x ms received)
- save operation has highest priority for me

As rosserial is limited in capabilities (same to Arduino), I think of some kind of custom messages and events to raise sensor trigger events instantly and sensor data frequently (seen something like this at kobuki robot). So firmware will not calculate /geometry/twist by itself but will provide raw odometry ticks and other raw sensor values. A special ROS Ardumower node will handle this messages on a more powerful device (RPI, Jetson or what ever used as SBC) and calculate (publish) geometry/twist or anything else needed. Same is true for /cmd/vel messages to mower.

First step to ROS for me, Ardumower will act as it does today (planned randomness) but with two perimeter coils. If this is solved, we can start to bring additional features (SLAM, path planning etc.)

What do you think about this? Should we:
- investigate in a totally new firmware vs. build a firmware based on Azurit and delete unnecessary code
- use custom messages over rosserial vs. use real ROS messages native (/odom, cmd_vel, geometry_twist)

I hate to do simulation only, so I build a ArdumowerTurleBot which I posted a couple of month ago in forum. This will be my R&D platform

Patrick
 
Hello Patrick.
For me , On the Net it's really difficult to find where to start with ROS :( (Nothing is really clear and you can find many simulation without real working mode)
so, maybe my point of view is totaly bad but for due a totally new firmware is certainly the solution with full and very fast interface with Jetson Nano

But the real question is what do you want to add to your mower ?

If it's path planning certainly Sunray is the solution.

If it's vision, all test i have made using tensorflow lite and PI4 (to detect dog or person) actually failed to work outdoor on correct speed without Google Coral or Jetson Nano
 
Hello Bernard,

well there is no real reason why I want to go for ROS. It is just because it is possible and I want to learn new things. I agree with you, it is pretty difficult to start with ROS. You find thousands of "in theory" tutorials which are not more than "Hello World". Thats why I want to start it from opposite point. Also by learning/using ROS, I'll be able to build other robots as well without building everything from scratch again. For example, I've started to build a quadruped robot. Calculation of trajectory is not an easy task for Arduino. But driving servos is an easy task for it.

I haven't investigate to Sunray so far and especially, GPS RTK is not a solution for me (way too expensive). In my opinion, ROS is a good way to implement new functionality fast. I found it hard to change Azurit and I changed couple of things there. Sunray might not be even better at this point.

But if we got a solid firmware for Arduino together with a ROS driver, we get a lot of capabilities here. In my opinion, PCB 1.3 is a great hardware basis for many robots, not only mowers. But you will not reach people outside "lawn" without ROS stack.
 
GPS RTK is not a solution for me (way too expensive)
Zum Vergrößern anklicken....
Yes actually the gps RTK is not a low cost solution without NTRIP ,But certainly in the future XBEE or F9P cost reduce and Alexander work can be the future of robot mowing.
Also maybe the cost is not only the problem, In my case there are water everywhere near my mowing area and a lot of big tree.
So if Sunray can work at +/-5cm inside a safe area (or create a waterproff mower 😆 ),his solution is the best i can imagine.(Robot can mow exactly like human do).

Do not hesitate to share a starting pont If you find a way to easy setup ROS (Without using a 300 Eur Jetson) with Arduino (only basic movement with bumper or sonar react ) and not on Simulation;).
 
I don't want to blame Alexander or any participant to this project for all this thousands of hours spending in Sunray (and even Azurit) and now to GPS RTK. This all is fantastic and hard work, impressive. But for me, Ardumower is a fun hobby project and a DIY robot, which costs up to 1500€ doesn't make much sense to me. My first Ardumower did only cost approx 200€.

However, I recently started to build a new firmware based on Azurit to communicate with ROS. This will be a long game and it might will result in nothing. But for me, its a good task to learn ROS.
As a first step, I remove anything of Azurit which is not needed anymore. Anything which was used to take decisions based on sensor data is gone (State machine ony contains off, error and ROS). It now just reads all sensor values regulary and send them to a ROS node. Here, it can be translated to any standard ROS message. For debugging purposes, some pfod functionalities are still there.
To be onest, this still covers thousands of code rows. I kept all this reliable working code of read out sensor values.

After this task is complete, I'll start develop ROS nodes who reacts on sensor data, like Bumper or perimeter. It will act as Azurit do today for beginning (planned randomness). If this works reliable, I'll learned enough to do more sophisticated tasks (hopefully)

I'll keep you informed in a separate thread as soon as my ArdumowerTurlebot works on teleop_key (real robot, no simulation)

Patrick
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben