Close
0%
0%

Quadruped ROS2 Bot

I will try to build a ROS2 enabled quadruped robot

Similar projects worth following
Two semesters ago I had to give a presentation about the current state of ROS2. The successor of the well-known Robot Operating System. Even though this project has come a long way and is already pretty "old", it is not really out there yet in the hacker scene. I think mainly because ROS1 works and still a few packages and documentations are missing for ROS2.
After I finished my presentation my professor asked me if I'd think it would be possible to realize a project in ROS2 yet. I wasn't sure back then. I said yes, but it will be a lot of work.

Now I want to prove this to myself. ROS2 has has matured a lot in the past year. After a few failures with other robots I will try to train myself in slow, but steady progress and try to reduce the 'hackyness'

What's the goal? There are a few

  • Low cost robot to learn more robotics and improve my 3D design stuff
  • Proving myself that ROS2 is mature enough for a neat hacker project
  • Add a simple programming interface to programm just the robots move and don't care about all the mathematics behind it.
  • Have a walking robot before the 36c3 and hacking together an API+Scratch-Extension ( https://scratch.mit.edu/ ) to make it programmable for kids. I think that's a good first milestone.
  • Being one of the first ROS2 projects on hackaday (damnit. Last time I looked there were no projects mentioning it) and maybe motivating atleast some person

What hardware do I want to use?

  • The ROS2 instance should run on a Raspberry Pi later on
  • A bluepill microcontroller ( STM32F103C8 ) for PWM
  • 12 TowerPro mg996r servos

What does the journey look like?

Now I kind of hacked together the first prototype of a leg, have a nice mount for it and a hacked together pwm-controller, I want to start implementing most things now and implement the inverse kinematics for just one leg. If this is all done, and hopefully more or less modular, I will go on and build the whole frame for it and start working on walking gates.

To not fail again as in my previous atempts to build a robot I am trying to implement and visualize everything with RVIZ before I am trying it out on real hardware. This will enable me working without the hardware around and hopefully reduce a lot of headaches.

A demo of the current state with visualization in RVIZ can be seen below:

All source code, the pwm controller firmware and openSCAD design files will be published sometime soon.

  • The motor control node

    Mario06/15/2019 at 19:51 0 comments

    I think I will write step by step down each ROS2 node I implemented, what they are doing, what my thoughts were and why I picked exactly the message I picked.


    The first one is going to be one which is essential for our direct hardware communication. This is the so calld 'motor_control'-Node. This node accepts motor commands with which the servo motors can be controlled.

    Each servo motor has a unique id and name. I am not entirely sure if this is overkill and just and ID would be enough, but I think atleast for RVIZ I need a name. So I just got both for each motor.


    Most logic from this node was inspired from a ros node by hansonrobotics[1], which I found on github. My first intention was to completely port this node to ROS2, but since I want to use the Bluepill-Controller later on (I am using a Pololu Maestro right now), I just  stripped it down to the bare minimum I actually need.

    It just consists of two classes. One for the motors and one for the controller. The first one is just a simple data class.

    The node consists of each a simple publisher and subscriber.

    The subscriber listens on the topic '/motor_command' and accepts a MotorCommand.msg which consists of the joint name, the position, speed and acceleration. Speed and acceleration are not used right now. They get default values. And apart from that this subscriber does exactly what you would think of it.


    The publisher publishes to '/joint_states' all current positions of every joint. This is needed for visualization in RVIZ and later inverse kinematics calculations.


    This node needs some default values for each joint as a parameter. These are noted down in the robot_params.yaml found in the root of the workspace and has the following structure:

    motor_node:
        ros__parameters:
            port_name : "/dev/ttyACM0"
            topic_name : "motor_command"
            hw_connected: false
            motor_names: ["base_to_coxa_joint", "coxa_to_femur_joint", "femur_to_tibia_joint"]
            motors:
                base_to_coxa_joint: 
                    motor_id: 0
                    init: 1500
                    min_pulse: 500 
                    max_pulse: 2500
                    min_angle: -1.5708
                    max_angle: 1.5708
                    offset: 0.7854
                    inverted: True
    

    - port_name

    Obvious, just the port name for the controller

    - topic_name

    The topic on which should be listened

    - hw_connected

    A boolean value if there is actual hardware connected. This is used for if I want to just visualize things in RVIZ and I do not have the hardware present.

    - motor_names

    A list of all following motors

    - motors:

    A list of the above listed motors with the id, an init value, min and max pulse as well as the angles. There can also be an offset, if any is needed. Each motor can also be inverted, which then just flips the current value to the equivalent opposite.

    To start the node you just have to write the following:

    ros2 run qrb_motors motor_control --params:=robot_params.yaml

    Now there should be a topic /motor_commands available, to which you can publish the needed motor states.

    The node will then publish all of them to /joint_states, as previously described.

    ---

    - [1] https://github.com/hansonrobotics/ros_pololu

  • Uh-oh.

    Mario06/10/2019 at 17:54 0 comments

    Looks like I should start printing the missing three legs and thinking about what I want the frame to look like. This has no interpolation or whatever in it. Just directly approaching three points.

  • This project ain't dead

    Mario06/03/2019 at 21:50 0 comments

    Beating the learning curve is hard. Writing about your shit is demotivating, too. I hope I can deliver something sometime soon. My math results look promising. Inverse kinematics should be done shortly.

    What am I working on? This:

    https://www.math.ucsd.edu/~sbuss/ResearchWeb/ikmethods/iksurvey.pdf

    http://gottliebtfreitag.de/msc_freitag.pdf


    Why not Denavit-Hartenberg or even a geometric solution? Because Lutz said those are for the lazy. Now I have to fight myself through his solution. Will damped least squares be overkill for 12DOF? Yes. I don't care.

    AvE talked on quite a few videos about beating the learning curve. I can't find any good right now. Therefore something else for motivation:

View all 3 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates