Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[fetch_binary_drivers] new [fetch_drivers] package #27

Merged
merged 11 commits into from
Feb 13, 2019
Merged

[fetch_binary_drivers] new [fetch_drivers] package #27

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
f2fab5b
[fetch_binary_drivers] new [fetch_drivers] package
moriarty Feb 2, 2019
8e144f9
System config debian components for ROS Melodic
erelson Feb 1, 2019
32f18f8
[fetch_system_config] fix README
moriarty Feb 2, 2019
5f022ca
Fixup system config debian
erelson Feb 4, 2019
529db79
Fixup .gitignore
erelson Feb 4, 2019
ead867e
[fetch_drivers] add more dependencies
moriarty Feb 5, 2019
b144529
Ensure robots power off safely when instructed to
erelson Feb 7, 2019
c5ee991
Update .gitignore
erelson Feb 7, 2019
d305db0
Fix typo in .gitignore
erelson Feb 9, 2019
4432ece
Update wifi power management disabling
erelson Feb 10, 2019
68d33fa
Copy updates to freight post-install script
erelson Feb 12, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 23 additions & 7 deletions fetch_binary_drivers/CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,12 +20,16 @@ find_package(catkin REQUIRED
## System dependencies are found with CMake's conventions
find_package(Boost REQUIRED
COMPONENTS
chrono
filesystem
program_options
python
thread
regex
system
thread
)
find_package(CURL REQUIRED)
find_package(PythonLibs REQUIRED)
find_package(yaml-cpp REQUIRED)

add_custom_target(
binary_driver ALL
Expand All @@ -43,15 +47,27 @@ add_custom_target(
###################################
## The catkin_package macro generates cmake config files for your package
## Declare things to be passed to dependent projects
## INCLUDE_DIRS: uncomment this if your package contains header files
## LIBRARIES: libraries you create in this project that dependent projects also need
## CATKIN_DEPENDS: catkin_packages dependent projects also need
## DEPENDS: system dependencies of this project that dependent projects also need
catkin_package(
# INCLUDE_DIRS include
# LIBRARIES fetch_binary_drivers
# CATKIN_DEPENDS other_catkin_pkg
# DEPENDS system_lib
LIBRARIES fetch_drivers
CATKIN_DEPENDS
actionlib
actionlib_msgs
diagnostic_msgs
fetch_driver_msgs
fetch_auto_dock_msgs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find a reference in the drivers to auto_dock

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cjds it might be stripped out of the research platform drivers.

amoriarty at SW44 in ~/ros/melodic/fetch-private/src/fetch_drivers on master
$ grep -rl auto_dock_msgs .
./CMakeLists.txt
./include/fetch_drivers/logpro/client.h
./package.xml
./src/logpro_client.cpp

nav_msgs
power_msgs
robot_calibration_msgs
roscpp
sensor_msgs
DEPENDS
Boost
CURL
PYTHON
YAML_CPP
)

###########
Expand Down
21 changes: 20 additions & 1 deletion fetch_binary_drivers/package.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,28 @@


<buildtool_depend>catkin</buildtool_depend>

<!-- mk is actually the only build time depend; it just pulls down a the compiled objects. -->
<build_depend>mk</build_depend>
<exec_depend>actionlib</exec_depend>

<!-- system dependencies which the drivers dyanmically link against -->
<exec_depend>boost</exec_depend>
<exec_depend>curl</exec_depend>
<exec_depend>python</exec_depend>
<exec_depend>yaml-cpp</exec_depend>

<!-- ros msgs which the drivers depend on -->
<exec_depend>actionlib_msgs</exec_depend>
<exec_depend>diagnostic_msgs</exec_depend>
<exec_depend>fetch_driver_msgs</exec_depend>
<exec_depend>fetch_auto_dock_msgs</exec_depend>
<exec_depend>nav_msgs</exec_depend>
<exec_depend>power_msgs</exec_depend>
<exec_depend>robot_calibration_msgs</exec_depend>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: ensure that these are the same as the ones we used when building the binary drivers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you won't be able to do that -- the ROS buildfarm / repos only contain the latest debs - once a new version is synced, the old ones go away. Hardcoding the value would make your package uninstallable at best.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikeferguson: would a nightly build job of our binaries, ensuring we’ve always got the latest dependencies work here?

@cjds and I were hoping to open source the Dockerfile & Python script which builds the output.tar.gz- it won’t be helpful without pull access on our drivers but it would at least make the process transparent

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@moriarty even having the released deb download a nightly binary build is a challenge -- when a sync to public happens, you'd have a ~24 hour window where the version built against public is no longer right. (and that sync happens every ~ 2 weeks, so that's about 7% downtime). Also how do you make it work on both shadow-fixed (where developers tend to test) and the main ros repo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😞
@dbking77 & @chadrockey maybe long term we reopen the discussion about refactoring some things to better support public/private drivers to make releasing to research customers easier ❓

We might need a second version setup up and built against shadow-fixed, this still doesn't fix the original problem, and it also wouldn't be clear how to set that up so that the shadow-fixed pulled a fetch-drivers-shadow.tar.gz and the release pulled fetch-drivers.tar.gz especially since currently they're pulling: http://packages.fetchrobotics.com/binaries/fetch-drivers-0.8.0.tar.gz
... Fetch3 & my machine are currently setup against shadow-fixed, but these drivers were built against whatever is inside of

FROM ros:melodic-robot-bionic

(As mentioned @cjds will cleanup the creation process and we plan to put them:
https://github.com/fetchrobotics/fetch_firmware_repackager or rename that repository fetch_drivers_repackager)

And it works now, but that's likely because there hasn't been any API/ABI breaking changes, which is not always guaranteed.
We'll need to check which of the dependencies we have are core dependencies, and which are non-core dependencies.

For the most part, the 7% downtime is a worst case calculation coming from 24hr every 2 weeks. If the dependencies are part of the core ros repositories, I think the API/ABI is stable enough or at least suppose to be... For non-core, and not released by us then it's just a risk that we'll probably need to take.
I don't even know if the melodic sync is triggered every 2 weeks because most of the folks at open robots are developing towards ros2. @jacobperron & @wjwwood?

Our plan, was to setup a mirror of ROS, which we manually trigger a sync on.
So customers with Fetch Research Robots could point to our http://packages.fetchrobotics.com/ and get guaranteed stability. But have the option to get the packages from packages.ros.org either ros or ros-shadow-fixed if they really want to live on the edge and accept some instability.

By pushing this into the public build farm, our internal packages.fetchrobotics.com will become almost a pure mirror, which should have much maintainable for our DevOps team and @bluryi.

If we sync our mirror manually, after testing to know we're not in the 7% downtime, then we'll get stability and more frequent updates.

For the 7% of possible down time for the packages.ros.org I think @erelson will need to update the (not yet existing) documentation to include strong warnings about pointing to packages.fetchrobotics.com or packages.ros.org
The packages.fetchrobotics.com mirror for melodic does not yet exist, we were going to quietly get our packages into melodic, and then setup a mirror once they were in and synced.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clalancette is the ROS Boss for Melodic, so it's up to him to decide when the syncs happen, though I think they've been trying to keep a regular cadence. Looking at the discourse posts, it's more like once a month, though maybe that will change.

Perhaps you can anticipate the syncs and be prepared with updated packages of your own to sync in order to minimize the period where your debs are out of date. We do usually announce an intention to sync a week or two before doing it, with the intention that people could test it for unintended regressions.

I don't know if this would be relevant as well, but there's this recent announcement by @nuclearsandwich:

https://discourse.ros.org/t/announcing-ros-snapshot-repositories/7705

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intention is to sync Melodic every two weeks, though I've basically never been able to achieve that due to regressions that I have to fix for every sync. So the cadence has indeed been more like once a month.

I intend to continue to attempt to sync every two weeks unless there is a compelling reason to change that. So if you have reasons you'd like it to change, please let me know and we can consider it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nickswalker and @mikeferguson I wanted to give you a warning: just in case you've been running melodic and testing with Fetch's using ros-shadow-fixed this is now there:

http://repositories.ros.org/status_page/ros_melodic_default.html?q=fetch_

@erelson will do a test on hardware using the ros-shadow-fixed before we make an official announcement with links to upgrade documentation. So: best case, everything works, but it's more likely that the official announcement to the fetch user mailing lists is going to be not the upcoming ros melodic sync, but the one after. If we're really unlucky we could be in one of those 7% downtime scenarios which was mentioned above.

<exec_depend>sensor_msgs</exec_depend>

<!-- ros dependencies wich the drivers dynamically link against -->
erelson marked this conversation as resolved.
Show resolved Hide resolved
<exec_depend>actionlib</exec_depend>
<exec_depend>robot_controllers</exec_depend>
<exec_depend>robot_controllers_interface</exec_depend>
<exec_depend>rosconsole</exec_depend>
Expand Down