Comments (14)
With the docker deployment I think the smartest solution for custom comms packages to do the following:
- create a ros workspace with just the custom package and create a launch file that launches whatever you need
- create a Dockerfile with the official open_mower_ros dockerfile as base (i.e. use FROM with the image)
- add your custom package to /opt/whatever
- overwrite the entrypoint to launch your launch file
- run your image
if you run local without the docker you can clone open_mower_ros and your ros workspace, source both and do the same as above.
I want to avoid having code in the open_mower_ros that has lots of hardware dependencies I cannot test
from open_mower_ros.
for wheel ticks, serial ports and so on you can already overwrite it using config files. set OM_MOWER to "CUSTOM" and put your files into ~/mower_params
from open_mower_ros.
XML explained (please see section #3): http://wiki.ros.org/roslaunch/XML
from open_mower_ros.
Unfortunately i don't think the current solution in development branch is flexible enough to support hardware variations such as Mowgli as it requires rosserial. Would it be a good idea to move over to a one liner include instead of params?
from open_mower_ros.
I also don't want mowgli and open mower to drift apart too far, I have fetched the important changes (again with some adaptations) from mowgli this week, but with time this will be hard due to small changes here and there.
Current Approach
It can be used like that. We could have hardware dependent include directories and move all the serial interface mappings out of the mower_config.sh and have just some high level config there (how wide is my mower, how far should it undock etc).
For example:
open_mower.launch currently includes "_comms.launch" which connects to everything on the hardware (+ntrip, that should be moved out of there).
We could have
- launch/hardware/mainboard_vXYZ/_comms.launch
- launch/hardware/mowgli/_comms.launch
and so on, then we can include the right one using the OM_MOWER switch.
The only downside is that all dependencies of all platforms are part of the dependency tree (i.e. rosserial will be installed even when not using mowgli and xESC stuff will be installed when using mowgli)
Another Approach
So we also could do this as an alternative:
We move everything that is shared between all hardware platforms (i.e. the high level stuff) into one repo called open_mower_core or something (or move the hardware dependent stuff out of this one, probably even better) and then create a repo for each hardware platform that includes the core as a dependency (similar to what mowgli is doing right now).
So in the end the user running mowgli will get the mowgli repo which then gets the current compatible open mower core and I could have like open_mower_yardforce, open_mower_husqvarna etc.
Also pinging @cloudn1ne - what do you think?
from open_mower_ros.
assuming you want to switch to BT also for OpenMower:
Im not fully there yet, but im positive that in a few more days i have the BT++ working in the same state as it is now with the slightly enhanced mower_logic (stop, resume) behaviors. From then on it should be really easy to add additional behaviors by creating new BT nodes.
The BT code is already written in a way that it is independent from the hardware as much as possible and where possible (so excluding map service calls) even independent from a "mower usercase", as there might be other uses for the robot platform ;-)
Very similar to mower_logic the following topics/services are subbed/published by mowgli_bt atm:
// Subscribers
subMowgliStatus = n.subscribe("mowgli/status", 50, MowgliStatusCB);
subOdom = n.subscribe("odom", 50, OdomCB);
// Publishers
pubCurrentState = n.advertise<std_msgs::String>("mower_logic/current_state", 10, true);
pubCommandVelocity = n.advertise<geometry_msgs::Twist>("/logic_vel", 1, true);
// Service servers
ros::ServiceServer srvHighLevelCommand = n.advertiseService("mower_service/high_level_control", highLevelCommandCB);
// Service clients
svcMowClient = n.serviceClient<mower_msgs::MowerControlSrv>("mower_service/mow_enabled");
svcDockingPointClient = n.serviceClient<mower_map::GetDockingPointSrv>("mower_map_service/get_docking_point");
svcMapClient = n.serviceClient<mower_map::GetMowingAreaSrv>("mower_map_service/get_mowing_area");
svcPlanPathClient = n.serviceClient<slic3r_coverage_planner::PlanPath>("slic3r_coverage_planner/plan_path");
svcPlannerGetProgressClient = n.serviceClient<ftc_local_planner::PlannerGetProgress>("move_base_flex/FTCPlanner/planner_get_progress");
// Action clients
srvMbfExePathClient = new actionlib::SimpleActionClient<mbf_msgs::ExePathAction>("move_base_flex/exe_path", true);
srvMbfMoveBaseClient = new actionlib::SimpleActionClient<mbf_msgs::MoveBaseAction>("move_base_flex/move_base", true);
Hardware -> BT++ Flow
- Standardised status topic (charge state, voltages, currents) and some capabilities bitmask
- HighLevelCommand - fine as it is i think
BT++ -> Hardware Flow
- Standardised services for Blade Motor Control, LED Control, Buzzer Control, ... ?
- CurrentState topic - maybe not just std::string but something like a numeric state with a string to be a bit more verbose and easier to use in an app or homeassistant display
Repo layout
- Hardware dependant: MowgliRover or openmower_ros (expose standardised interface to BT++) allows other platforms to be added as long as they adhere to the interface.
- The BT++ logic (replace ex mower_logic, or the mowgli version of it) - work in progress but looks good atm - i will put that in a separate repo shortly - happy to rename it to openmower_bt and add contributors then.
- mower_map_service (extract from openmower_ros, and put in its own repo -maybe rename it to openmower_map_service)
- ftc_local_planner (some more debug info would be good, to make it easier for starters to understand states)
- slic3r_coverage_planner
Not sure:
- xesc_ros -> subrepo of openmower_ros ?
- dedicated repo for the standardised messages (openmower_msgs)
Config
i think the config.sh approach is fine, i already prefixed my custom config variables with MOWGLI_ - however some stuff moved to the XML file for the BT (docking/undocking distances for example). Maybe a custom node that fetches ENV variables would need to be written to keep the current config schema.
from open_mower_ros.
Thank you for the detailed answer!
I almost agree with your layout, I think we should split that at a different point, though. For example having dead reckoning implemented in the "common" part of the software might be a good idea, because if we improve on that, we improve it for all platforms.
I think we should separate as low as possible and only implement the hardware drivers differently (+ obviously stuff like PID params / min max battery voltages, ...)
Having a single packet with the messages for implementing the low level interface is a good idea. Then anyone can implement that and can theoretically run the open mower stack.
from open_mower_ros.
Im making a drawing atm - i'll post when finished - as a basis for further discussion.
For DR i agree, but as u noted yourself the stopping /odom approach is a bit hacking, but i dont understand enough atm about the nav stack and all the transform to come up with a better way - at least we should make a dedicated node that outputs /odom then (tbd what that actually will do)
from open_mower_ros.
.drawio file is here
from open_mower_ros.
That looks like I imagined it, thank you for drawing that out.
The only thing I'd change is the odometry / dead reckoning solution. I don't like the two parallel sensor fusions (why are these different anyways, don't they have the same output with the same input?) and having DR implemented in robot_localization and in openmower_odometry.
- It should be possible to fuse GPS directly in robot_localization, so openmower_odometry is obsolete then
- Or we use some Kalman c++ lib (e.g. https://github.com/mherb/kalman) to do the EKF in openmower_odometry which would allow us to be more flexible with it and ditch the robot_localization.
from open_mower_ros.
(btw rviz currently already fetches the map from the remote map server, it's not the local copy)
from open_mower_ros.
added OM to the drawing, at least as i understand it.
from open_mower_ros.
i had the sensor fusion working with robot_localization before i started with integrating any OM parts - config is still somewhere in the mowglirover repo afaik - but the problem was, that you have two run two instances - one for the "jumping" gps coordinates, and one that then loops back the first ekf into the second one which fuses the wheel odometry and imu - it was "somehow" working but not stable for me, but i really dont get the whole TF stuff yet. So maybe you can get that to work ?
What my approach is atm - and what i mean with DR in openmower_odometry is basically a switch between /odom_gps (rel GPS coords + IMU heading) and /odom_dr (EKF output, which is wheel sensors and IMU heading). priority is on /odom_gps, but if that goes away for up to n seconds /odom_dr is emitted before it (for now) stops.
Another option would be to put the decision of what odom topic to use into openmower_bt - you are undocking/docking, then odom_dr is good enough. You need a recovery behavior because you are stuck for 10mins already waiting for GPS, same use a custom odom topic as configured ... just emit proper status information from XXXX_odometry that allows BT to make the proper choice
from open_mower_ros.
I would like to see this implemented somehow, worx branch needs a way to select between communication module (mower_comms and worx_comms). I see a hardware specific launch folder structure could work.
from open_mower_ros.
Related Issues (20)
- docker build fails HOT 1
- Include information about submodules in ReadMe build steps. HOT 1
- don't enter area recorder if battery is empty
- triggering dynamic obstacles in simulator HOT 1
- topic for publishing action HOT 4
- This is a random constant and unused. remove
- Mower pause/resume bug
- Mower fails to navigate an area if the loop has an intersection
- 2.5s for tilt_emergency_millis might be too low HOT 5
- Leaving Emergency while mowing set the state to Docking HOT 4
- Reverse mower-motor direction doesn't work HOT 11
- Grass too high should slow down the mower HOT 2
- Dock to station backwards
- Obstacle too close to the area bound can lead to wrong path HOT 14
- Home Assistant MQTT
- Problem with compilation HOT 1
- ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies HOT 1
- Path crosses not allowed areas HOT 9
- UART2 configuration HOT 1
- Do ellipsoid fit for mag_calibration. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from open_mower_ros.