yohtm's profile - activity

I've been working with a ProPak V3 recently also. The node expects to receive data in string formats. The first thing you could do is check with a serial tool like minicom or cutecom that data is actually received by the computer and that it's not binary (it might be, depending on how your GPS is configured). Don't forget to test the GPS outside and wait a few minutes for the signal to be aquired.

To configure the GPS I used the Novatel Connect app (Windows) to send the serial commands. The program can also confirm that your GPS is working as it should. We used the GPGGA mode, I think the command to enable it is as follow:

LOG COM1 GPGGA ONTIME 1

What is the orientation of your robot when it starts? And where does it get its orientation from?

Maybe you need to add a forward slash at the beginning of the topic names?

Can you post the configuration of your navsat_transform_node and ekf_localization nodes?

A lot of bugs happen only occasionally because of certain events that might or might not occur at the same time. You could try logging the cmd_vel and the commands sent to the motor controller and compare them to see if all messages are applied.

The fact that the /cmd_vel topic is empty makes me believe that the problem is more on the side of your motor controller than on the path planning or localization side. It might be skipping messages (not applying the /cmd_vel message to the motors) or there might be a hardware problem with the motor communication.

[Update]

To follow up on your update, the bug is definitely on the motor side (move_base behaves as planned, sending 0 velocity messages when the last goal is reached). The problem probably lies in the node subscribed to /cmd_vel that sends (serial?) commands to the motor controller. You could check that node and try to understand exactly what it does when it receives a message on /cmd_vel. It might be ignoring messages with certain conditions or it might simply be a bug.

If everything seems ok, then the bug might be in the communication with the controller or in the actual hardware controller.

First, your subscriber must use a callback, I suggest trying the ROS publisher subscriber tutorial.

I suppose you want to get the orientation in the Euler angle format (rotations around the x-y-z axis). Once you're able to receive the message through the callback, you can use the following code to access the angles.

import tf
orientation_euler = tf.transformations.euler_from_quaternion( odom_msg.pose.pose.orientation)
# use the angles with orientation_euler.x, orientation_euler.y, orientation_euler.z

You can simply add the topic to Rviz and set the value of the keep parameter to 0. This will display all received odometry messages as arrows. You can tweak the position and angle tolerance to display more/less arrows.

More details on the Rviz Odometry page.

I guess its a mix of both of your suggestions. The motor node needs to start sending odometry as soon as amcl and move_base start (even if it hasn't moved). The odometry and imu (through the localization node) and amcl will allow the robot to be positionned adequatly on the map with its tf. Then, using the position of the robot, the map and the currently seen obstacles, move_base will compute a local plan to follow the global plan according to various parameters (see base_local_planner parameters). As the robot moves, the position and obstacles are updated and move_base updates its local plan continuously until it reaches the goal.

The graph on the move_base page illustrates quite well how nodes and topics interact.

Assuming that your robot is non-holonomic (that it can only move forward and not side-to-side), then vy will always be 0 since your robot never moves on its Y axis. As for vx, it will simply be the velocity of your robot in m/s.