You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👋 I'd like to add a FABRIC implementation to scikit-bot (repo-link) and - since the implementation here is already in python and looks pretty awesome 💯 - I was wondering if there is any interest in merging this repo into scikit-bot.
Here are some advantages I can see that would come with a merge:
easy extension to complex chains (both 2D and 3D) via skbot.transform (similar to ROS tf2 but numpy-based)
URDF and SDF support
a fully-fledged CI/CD pipeline that releases updates immediately (may become nightly in the future)
having python implementations of established robotics algorithms in one central place
The main disadvantage would be that the API/signature would change. It is, however, possible to - if desired - wrap scikit-bot and get the same API downstream. Another potential disadvantage would be a license change from MIT to Apache-2.0. Both are quite comparable though, so I doubt this will be a big problem.
If there is no interest I can, ofc, write my own implementation; I am mainly thinking that it would be more efficient to combine the two implementations and only maintain one.
Let me know what you think 🚀
The text was updated successfully, but these errors were encountered:
👋 I'd like to add a FABRIC implementation to scikit-bot (repo-link) and - since the implementation here is already in python and looks pretty awesome 💯 - I was wondering if there is any interest in merging this repo into scikit-bot.
Here are some advantages I can see that would come with a merge:
The main disadvantage would be that the API/signature would change. It is, however, possible to - if desired - wrap scikit-bot and get the same API downstream. Another potential disadvantage would be a license change from MIT to Apache-2.0. Both are quite comparable though, so I doubt this will be a big problem.
If there is no interest I can, ofc, write my own implementation; I am mainly thinking that it would be more efficient to combine the two implementations and only maintain one.
Let me know what you think 🚀
The text was updated successfully, but these errors were encountered: