kevinochs / hexapod_ros Goto Github PK

In control.cpp, the method publishJointStates() takes leg, head and joint_state parameters which are data members of the Control class so they are accessible by the method with no need of the parameters.

In the case you want to be able to use other messages than the data members of the Control class, then you should replace the use of head_ (line 145) by the parameter head.

The physical measurements are flipped but corrected later down the line. This first came to light when rviz was implemented and it was easy to see visual axis on the TF display. Not blocking but confusing for someone just starting out.

Hello,
Can the code be used with a raspberry pi and standard hobby servos I'm looking to do a college project and I'm on a budget.

it appears to be a common problem. See the below link for a possible solution.

http://answers.ros.org/question/73048/first-compile-with-messages-messages-not-found/

Hi i would like to use your hexapod_ros package for odometry, but my hexapod uses a pca9685(pwm) controllerboard! is there any chance for use with an pca9685 driver?
thx in advance!

Just thought you would like to know, your code was featured on the "Hacksmith Industries" YouTube channel where they designed a scaled-up version of a hexapod:

Our BIGGEST project yet! (SPIDER MECH!)

Hi,

I'm just testing the stack on a RPI4 and a PhantomX MarkIII. It seems that the phamtonX.yaml file has a small problem regarding servo ID's.

In detail

16': {name: coxa_joint_LF, type: AX, id: 19, ticks: 1024, center: 512, max_radians: !degrees 300, sign: 1, offset: !degrees 0},

should be

'16': {name: coxa_joint_LF, type: AX, id: 1, ticks: 1024, center: 512, max_radians: !degrees 300, sign: 1, offset: !degrees 0},

and lines
'19': {name: pan_joint, type: AX, id: 20, ticks: 1024, center: 512, max_radians: !degrees 300, sign: 1, offset: !degrees 0},
'20': {name: tilt_joint, type: AX, id: 21, ticks: 1024, center: 512, max_radians: !degrees 300, sign: 1, offset: !degrees 0}

should become

'19': {name: pan_joint, type: AX, id: 19, ticks: 1024, center: 512, max_radians: !degrees 300, sign: 1, offset: !degrees 0},
'20': {name: tilt_joint, type: AX, id: 20, ticks: 1024, center: 512, max_radians: !degrees 300, sign: 1, offset: !degrees 0}

Cheers,

Christ

You should initialize pose_th_,pose_x_ and pose_y_ equal to zero at the construct function of control.cpp When i using the fake odom tf, it works perfectly on one machine, but becomes weird on the other machine. I finally found that some machine give a random initial value instead zero...
Bests.

Using a custom message for base complicates using standard navigation packages provided by ROS. A switch should be somewhat trivial.

Hello, I'm trying to get this robot working in simulation in gazebo. It looks like the gazebo implementation exists, but I can't find any way to have the hexapod gait & control node talk to the gazebo controllers instead of real Dynamixels. Is it possible to launch the robot and control it within gazebo? Could you provide an example of how to bring that up?

Hi, thank you for your great work.
The IK class works well with the 4 DOF legs, however, it can't get the correct joint angles for the phantomX robot. Could you give me some suggestions?

As I was building the package in ROS Melodic I found that there are problems with building the package due to the sound files. So I decided to remove all files that were related to sound_play or audio.

Currently users have been modifying the function depending orientation changing the sign on roll and pitch. We should be using the urdf as the entry point for that modification.

imu_pitch_lowpass_
imu_roll_lowpass_
imu_yaw_lowpass_

All need to be initialized to 0 on instantiation of the Control class. This became apparent when compiling and running on the RaspberryPi ARM architecture.