victoriarobotics / victoria_platform Goto Github PK

In doReadEncoders() is probably the ideal place to handle it.

When the Teensy is listening for cmd_vel, it needs to have a timeout where if it doesn't receive a new command within 200 ms, it commands the motors to stop.

Create a custom message, publish the encoder counts at 10Hz.

Like:

bool RosParamHelper::getParam(const char* name, float* param);

and other methods that have repeated pattern and code.

Need a message with the bumper information raw and/or calculated.

@markwomack
Instead of doing
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L187

Use the ros param defaults.
http://wiki.ros.org/rosserial/Overview/Parameters#CA-80097c1f2a5ef7735d28c0b3f247ceedac26fda6_1

@markwomack
I appreciate lines like this are unavoidable:
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L17

But unless we have a space constraint (which I don't think we do and it's not even clear that this would be a problem) I'm an advocate of converting ALL #define macros to const variables or ros params.

For the block of #define macros here:
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L111
Themselves should be ros params that are checked for. Otherwise, anytime we want to look at any debug outputs, we'll have to recompile and reload.
Further more, these macros encourage dead code. The preprocessor will remove them before the compiler gets to them, so when we do want to use them in the future when we've changed the code, it won't compile.

Macros like these:
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L36
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L53

Should be const variables or ros params so they can be tuned and seen/shared in a param file easily.

So, apparently, frames shouldn't have a / prepended onto them.
For example, it shouldn't be /odom it should be odom because of tf2 I think.
Topics should stay for now the way they are.

Code needs to handle incoming (subscribed) messages related to motor control and outgoing (published) motor encoder information.

The readme is in need of an overhaul, documenting dependencies and how to build/install.

Fob mode defaults 0, which means to ignore all fob settings. Values 1-4 indicated with fob to check. If the set fob is low, then the robot is stopped. But need subscriber to listen for setting the fob mode.

Stopping the robot due to the bumper being pressed should be controlled from the higher level ros modules, not the teensy code.

Increase the baud rate so that more information can be sent faster. It is going to take some exploration, some relevant discussions:

http://answers.ros.org/question/206972/baud-rate-parameter-in-rosserial_python-arduino/
http://wiki.ros.org/rosserial_python
http://answers.ros.org/question/243271/rosserial-baud-rate-not-being-set/

Right now the code uses pulseIn, which will block while it reads a pwm. cycle. See battlebot firmware for example.

http://docs.ros.org/api/sensor_msgs/html/msg/MagneticField.html

The lis3mdl we are using returns values that can be converted to gauss, which we will need to convert to tesla.

We call setMotors() for every loop. We should only call it when we have received a cmd_vel or we have not received a cmd_vel for the threshold. That would allow the motor controller hardware to stop itself since it does not get a continuous stream of commands.

@markwomack
I can't easily find out what these parameters are
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L146

Can we make the magic numbers const int with names like I2C_MASTER_ADDRESS or whatever they are.

Comment:
https://github.com/victoriarobotics/victoria_platform/blob/master/Arduino/victoria_teensy_ros_node/victoria_teensy_ros_node.ino#L341

For the gyro conversion is wrong.

To be used by strategy module to pause if the emergency stop is active.

After they get installed.
Just the motor parameters.

I think we want to create a publisher of "imu/data_raw" and publish the message sensor_msgs::Imu.

Been having some issues with the Teensy lately (power related I'm sure) and I've thought that it would be nice if the Teensy blinked with one pattern when it was on, before contacting the ROS core and a different one after.

Add ros topic that publishes a custom message that contains the current state of the Teensy. Is the TRex happy? Is the IMU and Magenetometer happy? Etc. Can be published once every 5 seconds.

The imu_raw message doesn't have a frame. The frame should be imu_link.

Right now a number of values are hard coded in the teensy code. Allow for those values to be set via rosparam.

TRex support a set acceleration instead of just set speed. The speed will be brought up to the set acceleration with changes every 10th or 100th of a second. This may make the robot less jumpy when starting up and changing direction, etc.

Parameters are documented here:

https://www.pololu.com/file/0J2/TReX_Parameters_v1.2.pdf

Probably want to set a timeout to kill the motors. Maybe change the acceleration settings, etc.

TRex allows for reading the current current draw for each motor. Add code to read it and publish it in ROS.

Right now, rosparam values are only loaded in the setup() method. Need to find a mechanism to update those values without requiring a restart of the Teensy. Maybe some kind of "update" or "reset" message from ros?

@markwomack We might have to have a custom odom message

ros-drivers/rosserial#277

At the very least the baud rate will need to go up.
The covariance data is too big in most cases.