Add Docking ability to charge robot when power is low

[chrisl8]

Add Docking ability to charge robot when power is low

[TCIII]

@chrisl8,

I will give it a shot this weekend.

I assume that I should have a functioning version of Cooper's 'IR_receiver_rosserial_ircode.ino' code on the IR Receiver Arduino Uno R3 that will output irCode.x = flag2; irCode.y = flag3; in the ROS serial format when the IR Transmitter beam is detected?

How does Cooper's ROS code know which input device to look at for the output of the Arduino Uno R3 ROS serial output?

Can the Arlobot chassis be stationary (on blocks) with the IR Receiver facing the IR Transmitter at some arbitrary distance since this is just a IR Receiver beam detection test?

Regards,
TCIII

[chrisl8]

@TCIII My guess is that you probably need to do everything I mentioned above, and also run:

rosrun rosserial_python serial_node.py /dev/tty<USB# or ACM#>

which will provide the bridge between the Arduino and ROS, and then you would see data on the /irValue topic.

I don't see "irValue" in the cod you pasted, so it may also be necesary to pass the "topic" to serial_node.py somehow?
Unless the .ino file provided by the project already encodes that somehow?

[chrisl8]

@TCIII

No harm in just trying things either. Run the code, see what happens.

It sounds like I will have to put some code on an Arduino to fully know how to make it work. I might get to that this weekend or I might not.

This kind of complex setup process, long string of dependencies, and lots of half-documented solutions is why I made this repository to begin with. ROS is great, but it is not full of people who like to document things or maintain fully functioning systems. 😄

[chrisl8]

@TCIII

When all of this is running, what does the output of rostopic echo /irCode show?

EDIT: I think that you can entirely ignore /irValue, that was a red herring introduced by the other .cpp file, but the mybot_autodocking_irCode instance that you are running is listening to /irCode, which the Arduino is hopefully publishing to?

[chrisl8]

First, it looks like everything is working! 🥳 Maybe not perfectly, but your hardware is working, the code functions, and ROS is receiving input, and the robot is acting on it!

1. My assumption for why X is not set to 0.0 when one side sees the IR signal is that the developer's intention was for it to continue to move toward the dock while correcting the orientation, rather than stopping and rotating to correct every time it got off to one side. Since it sees the IR beam, it knows the goal is in sight, so it might as well move toward it, even while correcting the angle.
   Imagine the difference between a smooth wavy line as it approaches vs. a series of sharp zig-zags as it stops, corrects starts again, stops, corrects, starts again.
   My guess is that the specific values in the code may require tuning on your part to make it work best with your robot, with your dock, on your floor surface.

You can adjust the X value as you see fit at line 23 of mybot_autodocking_irCode.cpp although that is the only place X is set, so if you make it 0.0, it will never move toward the goal. More logic will need to be added to the code if you want it to set X to 0.0 when rotating, but higher when moving straight.

Remember that changes to cpp code will not affect code until you run catkin_make again like you did in the setup to rebuild the code. (That is one drawback of C++ code vs. Python code in ROS. The benefit is that C++ code in theory runs faster with less load on the CPU, although that is debatable with modern Python and CPUs.)

2. If you look at the code in mybot_autodocking_irCode.cpp you can see that it sets an initial value of 0 for foundDockingStation in line 9, and then in line 54 sets it to 1, but it never sets it back to 0 ever.

So the code author assumed that once the IR beam was seen, it would remain seen until docked.
This was either a very poor assumption or just one that worked for the author and not you.

It will take some updates to the mybot_autodocking_irCode.cpp code to change that behavior.

[chrisl8]

@TCIII Yes, we should move this somewhere else. Also, it isn't really a code issue, just having to tweak your variable settings for your particular robot. The wheelSymmetryError is doing this in the code:

ArloBot/PropellerCodeForArloBot/ROSInterfaceForArloBot/ROSInterfaceForArloBot.c

Line 542 in 458754b

expectedRightSpeed =

        expectedRightSpeed =
            expectedRightSpeed / distancePerCount * wheelSymmetryError;

So it literally causes the robot to adjust how many "ticks" in the encoder per rotation are used between the right and left wheels.

I have never had to use it, but it exists for exactly the purpose you are using it for, so if it works, that is all that matters. Just keep in mind that you set this when you are working with the robot later.

[TCIII]

@chrisl8

"dockingStation": {
"_has_dockingStation": "Set this to true if you have a docking station",
"has_dockingStation": true,
"dockingIrReceiverUniqueString": "Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_019990C9",
"dockingIrReceiverStringLocation": "ID_SERIAL",
"angular_z": 0.1,
"linear_x": -0.08
},

I changed "linear_x": -0.08 to "linear_x": 0.08 otherwise ArloBot will backup once it has detected the IR Transmitter beam.

Also, maybe you should add a find_IR_Receiver.sh to the ArloBot scripts?

TCIII

[TCIII]

@chrisl8,

Will do.

TCIII

[chrisl8]

Interesting, I'm not sure how changes to personalDataForBehavior.json would affect the run of the setup script. If you post the errors that it generated before it failed I can look into it, otherwise we will hope it was just unique to your setup and doesn't happen again.

And yes, it should run with or without that bit of configuration. It is entirely optional.

[chrisl8]

@TCIII

Yes, you fixed a bug! I've updated the source and pushed it now also. Apparently, I did not finish updating some of my copy/paste of existing code to implement the new feature.

Thank you for the kind words.

[chrisl8]

source ~/catkin_ws/devel/setup.bash
cd ~/catkin_ws
catkin_make

[chrisl8]

The button in the web interface runs the same script. Since it can be difficult to see the output, I didn't think it was wise to try it until you have the entire procedure working reliably from the command line.

[chrisl8]

As an initial test do this on the robot:

Setup

source ~/catkin_ws/devel/setup.bash
cd ~/catkin_ws/src
git clone https://github.com/wennycooper/mybot_autodocking.git
cd ~/catkin_ws
rosdep update
rosdep install -q -y -r --from-paths src --ignore-src
catkin_make

That should build and install the code.

Testing

Now, in a terminal window, on the robot run start-robot.sh OR start ROS from the web Interface.

Once it is going, in another terminal run:

source ~/catkin_ws/devel/setup.bash
rosrun mybot_autodocking mybot_autodocking

It should start with no output and just stay that way, I think.

In another window, run:

source ~/catkin_ws/devel/setup.bash
rostopic echo /irValue

Is there any output? If so, can you tell me what it is?
If you "bring up" or "turn on" your IR device, does it that change things?

This is where I'm needing help, because I'm not sure what the output should look like.

Finally try this one:

rostopic echo /cmd_vel

and again. does it have any output when then IR system is operating?

[chrisl8]

@TCIII

When you run the rosrun mybot_autodocking mybot_autodocking I suggest having the robot on blocks, because it will probably start trying to move. I could be wrong, but that is the idea.

Also be aware that it will probably lock out all other input to the robot. I will have to add the setup to "mix" the input into the other sources, OR you will need to create some automation to only start the autodocking when you are ready to dock. We can work that out later.

You will want to watch the output of rostopic echo /cmd-vel and rostopic echo /irValue and if there IS output, then move the robot or IR sender to see if it appears to change the output. Honestly, if you get anything on rostopic echo /irValue that will be a successful first test.

I don't actually know how the Arduino talks to the ROS code or how it knows which input device to use.
In fact, when I look into the code here I don't even see anything that is talking to other code:
https://github.com/wennycooper/mybot_autodocking/tree/master/src

Both .cpp files seem to have code to send twist commands to ROS, and they subscribe to an /irValue topic, but what is publishing messages to the /irValue topic?

Maybe the Arduino code itself is doing that? If the Arduino is somehow able to publish right into the ROS topics running on the host, that would make sense. I didn't know that this was possible, but I've never tried either.

Also, I could be wrong about running
rosrun mybot_autodocking mybot_autodocking

You might need to run this instead:
rosrun mybot_autodocking_irCode mybot_autodocking_irCode

I guess try each or both to see what happens?

Make sure your Arduino is plugged in when you try it.

If nothing works, we'll have to do more debugging. I do have an Arduino, so I could probably test that code too, even without the IR hardware.

Let me know what you find.

[TCIII]

@chrisl8,

Thanks for the quick response, much appreciated.

I will integrate your detailed update into the testing.

Take a look at this 'IrRanger.pde' code that transmits an ir range using rosserial and is somewhat similar to Cooper's 'IR_receiver_rosserial_ircode.ino' code.

All of the required rosserial commands in the 'IrRanger.pde' code also appear in ''IR_receiver_rosserial_ircode.ino' code so the structure of the 'IR_receiver_rosserial_ircode.ino' code seems to be sound.

As you have indicated, how 'mybot_autodocking_irCode.cpp' or mybot_autodocking.cpp code accesses the output of the 'IR_receiver_rosserial_ircode.ino' code on the Arduino Uno R3 is not well understood at the moment.

This rosserial Package Summary may shed some light on how the ROS-side interfaces with the Arduino.

Also, after analyzing 'mybot_autodocking_irCode.cpp', it appears that Cooper's robot backed into the docking station as 'cmd->linear.x = -0.08;' is a negative value once the docking station has been found and the robot is aligned to the charging contacts.

I am attaching Cooper's Autodocking Guide that explains how he envisioned the autodocking process.

Regards,
TCIII
Autodocking Guide.zip

[TCIII]

@chrisl8,

I have posted a question on ROS Answers as to how Cooper's 'mybot_autodocking_irCode.cpp' code identifies the USB port and baud rate of the rosserial-enabled Arduino that is transmitting the IR Receiver beam detection data.
I really have the feeling that Copper's 'mybot_autodocking_irCode.cpp' was a one-off experiment designed to run on a laptop where the Arduino Uno R3 was the only USB input and therefore the node did not have to search for the Arduino's port.

I don't think that our experiment will succeed until we understand how Cooper's 'mybot_autodocking_irCode.cpp' code detects the rosserial-enable Arduino.

Regards,
TCIII

[chrisl8]

@TCIII

Have you tried it yet?
Did you upload code to the Arduino? If so, what code did you use? I haven't looked at the Arduino code myself, so I don't know how it works. If you send me a link to the .ino file you used, I could give some insight on how it appears to work.

It seems premature to me to call it a failure if you haven't tried it yet.

EDIT: Looking over both of your posts, I think I've probably failed to absorb everything you were trying to say. I apologize for that. I'm still not clear on whether you connected the Arudino to the robot's computer yet and tried it though. My guess is that the Arduino is able to connect to ROS somehow, but I could be making stuff up.

EDIT 2: Looking at https://wiki.ros.org/rosserial, it sounds like maybe there has to also be a "ROS Side" program running to capture the output from a device, like the Arduino, running ROS Serial? If so, that may be a missing piece that we have to start up also. This is why this project is incomplete, as he should have a .launch file that does this for us, as well as included it in the dependencies in the make file.
Anyway, it is doable. I will probably have to get out an Arudino though and put the code on it to try it, as I have never used ROS Serial before.

[TCIII]

@chrisl8,

No, I have not tried the code per your instructions because I see no way that Cooper's 'mybot_autodocking_irCode.cpp' is going to be able to distinguish and identify the IR Receiver Arduino from the other USB components attached to the Rpi 4B.

I have not been able to find one example that uses a ROS-side node code that communicates with an Arduino. All of the examples use 'rosrun rosserial_python serial_node.py /dev/tty<USB# or ACM#>' from the CLI.

Here is what I used to view the Arduino IR Receiver output with the Arduino IDE Terminal:

`#include <IRremote.h>

// #define PIN_IR 3
#define PIN_DETECT2 (2)
#define PIN_DETECT3 (3)
// #define PIN_STATUS 13

unsigned int flag2, flag3;
// IRsend irsend;
void setup()
{

Serial.begin(57600);
pinMode(PIN_DETECT2, INPUT);
pinMode(PIN_DETECT3, INPUT);
// pinMode(PIN_STATUS, OUTPUT);
// irsend.enableIROut(38);
// irsend.mark(0);
}

void loop() {
flag2 = 0; flag3 = 0;
if (digitalRead PIN_DETECT2 == LOW) flag2=1;{
}

if (digitalRead PIN_DETECT3 == LOW) flag3=1;{
}

if (flag2 && flag3) {
Serial.println("Pin2: True, Pin3: True");
}
if (flag2 && !flag3) {
Serial.println("Pin2: True, Pin3: False");
}
if (!flag2 && flag3) {
Serial.println("Pin2: False, Pin3: True");
}

}
`
Here is the same Arduino code with Cooper's ros commands added. It compiled correctly once I modified the rosserial_arduino_library as I mentioned in a post above:

`#include <ros.h>
#include <geometry_msgs/Vector3.h>

//#include <IRremote.h>

// #define PIN_IR 3
#define PIN_DETECT2 (2)
#define PIN_DETECT3 (3)
// #define PIN_STATUS 13

unsigned int flag2, flag3;

ros::NodeHandle nh;
geometry_msgs::Vector3 irCode;
ros::Publisher pub("irCode", &irCode);

// IRsend irsend;
void setup()
{
nh.initNode();
nh.advertise(pub);

Serial.begin(57600);

pinMode(PIN_DETECT2, INPUT);
pinMode(PIN_DETECT3, INPUT);
// pinMode(PIN_STATUS, OUTPUT);
// irsend.enableIROut(38);
// irsend.mark(0);
}

void loop() {
flag2 = 0; flag3 = 0;
if (digitalRead PIN_DETECT2 == LOW) flag2 = 1; {
}

if (digitalRead PIN_DETECT3 == LOW) flag3 = 1; {
}

/*
if (flag2 && flag3) {
Serial.println("Pin2: True, Pin3: True");
}
if (flag2 && !flag3) {
Serial.println("Pin2: True, Pin3: False");
}
if (!flag2 && flag3) {
Serial.println("Pin2: False, Pin3: True");
}
*/

irCode.x = flag2;
irCode.y = flag3;
pub.publish(&irCode);

nh.spinOnce();

// digitalWrite(PIN_STATUS, !digitalRead(PIN_DETECT));

}
`
The above code needs to be cleaned up to remove the unnecessary commented lines.

Comments?

TCIII

[TCIII]

@chrisl8,

"irValue" is called "irCode" in the Arduino .ino code above:

``geometry_msgs::Vector3 irCode;
ros::Publisher pub("irCode", &irCode);
`irCode.x = flag2;
irCode.y = flag3;
pub.publish(&irCode);`

From Cooper's 'mybot_autodocking_irCode.cpp':

irValue_sub = nh.subscribe("/irCode", 10, irValueCallback);

`void irValueCallback(const geometry_msgs::Vector3 &vector3)`
`vec3.x = vector3.x;
 vec3.y = vector3.y;`

Apparently the Vector3.h messages are the link between the Arduino irCode and the irValue values?

I believe that Cooper's 'mybot_autodocking_irCode.cpp' is the ROS-side node that you are referring to, but I don't see where he establishes communication (USB port/baud rate) with the Arduino. Unless it is done with #include < 'ros/ros.h'>?

Cooper's 'mybot_autodocking_irCode.cpp' is definitely acting as a 'subscriber' . The giveaway is the:

irValue_sub = nh.subscribe("/irCode", 10, irValueCallback);

void irValueCallback(const geometry_msgs::Vector3 &vector3)

typedef void(ObjT::*CallbackT)(const MReq&, MRes&);

Regards,
TCIII

[TCIII]

@chrisl8,

I plugged in the Adafruit Metro 328 to the ArloBot USB Hub and ran:

cd /dev
/dev ls

To determine the IR Receiver Metro 328 USB port number which is USB0
The RPLIDAR is USB1
The PAB is USB2
The NeoPixel Arduino Uno is ACM0

I have the IR Transmitter pointed at the IR Receiver Assembly mounted on the ArloBot and the IR Receiver LEDs are indicating reception of the IR Transmitter beam.

I then completed the steps in "Setup" and received the following:

[100%] Built target mybot_autodocking_irCode
[100%] Built target mybot_autodocking

I then ran the following in separate terminals:

start-robot.sh

source ~/catkin_ws/devel/setup.bash
rosrun mybot_autodocking mybot_autodocking

source ~/catkin_ws/devel/setup.bash
rostopic echo /irValue

No output with or w/o IR beam

However the Right Wheel turned forward and the Left wheel turned backward with or w/o the IR beam.

rostopic echo /cmd_vel output with and w/o the IR beam:

linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.15

When I ran rosrun rosserial_python serial_node.py /dev/ttyUSB0 to see if I could see the irValue, the CLI came back with 'rosserial_python' not installed.

How should I install rosserial_python? It appears it can be installed from source or from apt-get install:
sudo apt-get install ros-noetic-rosserial-python

Comments?

TCIII

[TCIII]

@chrisl8,

I have run rosrun mybot_autodocking mybot_autodocking_irCode and received the following on the CLI until I hit ^C:

thomas@thomas-desktop:~$ rosrun mybot_autodocking mybot_autodocking_irCode
x=0.000000, y=0.000000
x=0.000000, y=0.000000

I had to change rosrun mybot_autodocking_irCode mybot_autodocking_irCode to rosrun mybot_autodocking mybot_autodocking_irCode because mybot_autodocking_irCode is in the 'mybot_autodocking' directory. The 'mybot_autodocking_irCode' directory does not exist.

Running the following:

source ~/catkin_ws/devel/setup.bash
rostopic echo /irValue

Yielded the following with and w/o the IR beam:
WARNING: topic [/irValue] does not appear to be published yet

Running the following:

source ~/catkin_ws/devel/setup.bash
rostopic echo /cmd_vel

Yielded this output with and w/o the IR beam:

linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.1

Looks like we are making some progress using rosrun mybot_autodocking mybot_autodocking_irCode, but the mybot_autodocking_irCode node is not getting input from the Metro 328 IR Receiver. Therefore I need advice on installing rosserial_python.

Comments?

TCIII

[TCIII]

@chrisl8,

You are right about Cooper's ROS code being incomplete. Here is the ROS Answers response:

"On the host running rosserial, ROS is not responsible for "finding" the linux /dev/[somehing] device. The author of the ROS launch file must create entries on the ros-parameter-server specifying a linux device name and a baudrate.

For USB, creating the linux device in /dev is typically done with a udev rule. You must install this rule before you insert the usb device and before the ROS launch file is executed. This new udev rule will be triggered when your specific USB-device is inserted, and then udev will create a fixed linux /dev name that you specify in the rule e.g. /dev/arduino

For this to work, the name in the udev rule has to exactly match the device name you specify in your ROS launch file."

I know that the IR Receiver Metro 328 is on USB0 and its baud rate is set at the default 57600.

Should I use udevadm to determine the IR Receiver Metro 328 info?

Regards,
TCIII

[TCIII]

@chrisl8,

Will you be able to do the following this week so that I can continue to validate the robot docking software:

1. Create a find_IR_Receiver.sh script to identify the USB port that the Arduino IR Receiver is connected to.
2. Create a ROS launch file for the ROS node mybot_autodocking mybot_autodocking_irCode that specifies the Arduino IR Receiver USB port and any other support modules that are required.

As far as item one goes, I assume that you will add a .arduinoUniqueString and a .arduinoStringLocation to a "useArduinoForIRReceiver": true, in the "personalDataForBehavior.json" file to be determined by running udevadm info --query=property --name /dev/ttyUSB0 where the Arduino IR Receiver is on USB0?

Regards,
TCIII

[TCIII]

@chrisl8,

I would appreciate some input here as I would like to move this project along to completion.

Regards,
TCIII

[chrisl8]

@TCIII

Did you install ros-noetic-rosserial-python yet?

[TCIII]

@chrisl8,

Thanks for the response, much appreciated.

Not yet as I was waiting for your feedback which you have given.

Once I install ros-noetic-rosserial-python do you want me to run rosrun mybot_autodocking mybot_autodocking_irCode and try running source ~/catkin_ws/devel/setup.bash followed by rostopic echo /irValue and then try running source ~/catkin_ws/devel/setup.bash followed by rostopic echo /cmd_vel?

Regards,
TCIII

[chrisl8]

@TCIII

Yes, and then in addition run
rosrun rosserial_python serial_node.py /dev/ttyUSB0
(or whatever the device name is for the IR controller that is connected)

[TCIII]

@chrisl8,

Unfortunately sudo apt-get install ros-noetic-rosserial-python failed to install:

Get:1 http://packages.ros.org/ros/ubuntu focal/main arm64 ros-noetic-rosserial-msgs arm64 0.9.2-1focal.20210424.032443 [23.8 kB]
Err:2 http://packages.ros.org/ros/ubuntu focal/main arm64 ros-noetic-rosserial-python arm64 0.9.2-1focal.20210922.181500
  404  Not Found [IP: 140.211.166.134 80]
Fetched 23.8 kB in 1s (33.2 kB/s)
E: Failed to fetch http://packages.ros.org/ros/ubuntu/pool/main/r/ros-noetic-rosserial-python/ros-noetic-rosserial-python_0.9.2-1focal.20210922.181500_arm64.deb  404  Not Found [IP: 140.211.166.134 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

TCIII

[chrisl8]

@TCIII

You are either having network/Internet issues or there is some outage for the particular ROS mirror you hit.

You can try running these to confirm/update your package settings:

sudo apt update
sudo apt upgrade

and then try again. It could just be transient. packages.ros.org does sometimes go down or get overloaded.

[TCIII]

@chrisl8,

It will take a while as there are 291 packages to upgrade.

TCIII

[TCIII]

@chrisl8,

I found this sudo apt install -y ros-noetic-rosserial-python here. What do you think?

TCIII

[TCIII]

@chrisl8,

Running sudo apt install -y ros-noetic-rosserial-python worked after the update/upgrade finished.

TCIII

[TCIII]

@chrisl8,

Since the update/upgrade, find_camera.sh UVC cannot find the camera so start-robot.sh will not run.

Running fswebcam --verbose --device=/dev/video0 2>&1|grep cap.card gives:

src_v4l2_get_capability,89: cap.card: "Video Capture 5" whereas the camera used to be "UVC"

I will change "camera0name": from "UVC" to "Video Capture 5", in personalDataForBehavior.json.

Running find_camera.sh Video Capture 5 gives:
/dev/video0

It is interesting what a update/upgrade will do to Ubuntu.

TCIII

[TCIII]

@chrisl8,

Made some progress:

Ran the following sequence in separate terminals:

start-robot.sh

source ~/catkin_ws/devel/setup.bash
rosrun mybot_autodocking mybot_autodocking_irCode

source ~/catkin_ws/devel/setup.bash
rosrun rosserial_python serial_node.py /dev/ttyUSB0

source ~/catkin_ws/devel/setup.bash
rostopic echo /irValue

rosrun mybot_autodocking mybot_autodocking_irCode output when both IR Receivers were illuminated:

x=0.000000, y=0.000000
x=1.000000, y=1.000000 #the wheels were turning in reverse as expected from Cooper's 'mybot_autodocking_irCode.cpp'
code.
x=0.000000, y=0.000000

rosrun rosserial_python serial_node.py /dev/ttyUSB0 output:

[INFO] [1645563476.048943]: ROS Serial Python Node
[INFO] [1645563476.066510]: Connecting to /dev/ttyUSB0 at 57600 baud
[INFO] [1645563478.185020]: Requesting topics...
[INFO] [1645563478.280282]: Note: publish buffer size is 280 bytes
[INFO] [1645563478.284677]: Setup publisher on irCode [geometry_msgs/Vector3]

rostopic echo /irValue output:

WARNING: topic [/irValue] does not appear to be published yet

So it looks like there is a disconnect between /irValue in the .cpp code and /irCode in the Arduino ino.

"irValue" is called "irCode" in the Arduino .ino code:

geometry_msgs::Vector3 irCode;
ros::Publisher pub("irCode", &irCode);
irCode.x = flag2;
irCode.y = flag3;
pub.publish(&irCode);`

From Cooper's 'mybot_autodocking_irCode.cpp':

irValue_sub = nh.subscribe("/irCode", 10, irValueCallback);

void irValueCallback(const geometry_msgs::Vector3 &vector3)
vec3.x = vector3.x;
vec3.y = vector3.y;

Comments?

TCIII

[TCIII]

@chrisl8,

Nice catch as I did not try rostopic echo /irCode. Apparently Cooper converted /irCode to irValue in mybot_autodocking_irCode.cpp:

ros::NodeHandle nh;
cmd_vel_pub = nh.advertise<geometry_msgs::Twist>("/cmd_vel", 50);
irValue_sub = nh.subscribe("/irCode", 10, irValueCallback);

Just about dinner time so I will have to take a break. Recharging the ArloBot batteries too.

TCIII

[TCIII]

@chrisl8,

I ran the setup code again and this time I ran rostopic echo /irCode.

When I had the IR beam illuminating both IR Receivers the output looked like this:

x: 1.0
y: 1.0
z: 0.0

When I had the IR beam illuminating the Right IR Receiver the output looked like this:

x: 0.0
y: 1.0
z: 0.0

When I had the IR beam illuminating the Left IR Receiver the output looked like this:

x: 1.0
y: 0.0
z: 0.0

When I had the IR beam illuminating both IR Receivers both wheels were turning backwards as the robot thinks it is now aligned to the dock and is trying to engage the dock. The wheels are turning backwards because Cooper's mybot_autodocking_irCode had the robot back into the dock:

if (foundDockingStation) {
geometry_msgs::TwistPtr cmd(new geometry_msgs::Twist());
cmd->linear.x = -0.08; # Going in reverse
cmd->angular.z = 0.1 * (vector3.x - vector3.y);
if (vector3.x || vector3.y)
cmd_vel_pub.publish(cmd);

However, pointing the beam at just one sensor does not seem to make the mybot_autodocking_irCode attempt to rotate in the other direction in order to illuminate both detectors with the beam.

Shouldn't this code snippet from mybot_autodocking_irCode cause the robot to search for the beam or does your code not understand angular.z :

if (!foundDockingStation && vec3.x == 0.0 && vec3.y == 0.0) {
geometry_msgs::TwistPtr cmd(new geometry_msgs::Twist());
cmd->angular.z = 0.1; // const rotate until
cmd->linear.x = 0.0;
cmd_vel_pub.publish(cmd);
} else {
foundDockingStation = 1;

The mybot_autodocking_irCode code only prints printf("x=%f, y=%f\n", vec3.x, vec3.y); so we never see an angular "z" value.

I will perform more testing tomorrow morning.

Comments?

TCIII

[TCIII]

@chrisl8,

Observation:
After testing last night I found that the Right wheel was turning much faster than the Left wheel when ArloBot was supposed to go in a straight line. I tried several software fixes to no avail. Finally I used an air can to blow any dust out of the Right wheel optical encoder and that cured the problem. It might be a good idea to blow the dust out of the wheel encoders periodically. This is another reason why hall effect motor encoders are superior to optical wheel encoders. Also motor encoders tend to have much higher resolution than wheel encoders.
When I was having the Right wheel issue I ran bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh) to see if there was a software issue.

Now when I run rosrun rosserial_python serial_node.py /dev/ttyUSB0 I get this error message:

[INFO] [1645631340.221298]: ROS Serial Python Node
[INFO] [1645631340.236635]: Connecting to /dev/ttyUSB0 at 57600 baud
[INFO] [1645631342.352447]: Requesting topics...
[ERROR] [1645631342.475269]: Mismatched protocol version in packet (b'\xbf'): lost sync or rosserial_python is from different ros release than the rosserial client
[INFO] [1645631342.483907]: Protocol version of client is unrecognized, expected Rev 1 (rosserial 0.5+)

Did running <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh) mess up rosserial client?

Found out what the problem is. Running <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh) rearranged the USB port numbers. The Arduino IR Receiver is now USB1 instead of USB0.

Observations:

1. When both IR Receivers are illuminated the irCode.cpp thinks that it is aligned with the docking station and begins backing up into the station:

if (foundDockingStation) {
geometry_msgs::TwistPtr cmd(new geometry_msgs::Twist());
cmd->linear.x = -0.08; # Going in reverse
cmd->angular.z = 0.1 * (vector3.x - vector3.y);
if (vector3.x || vector3.y)
cmd_vel_pub.publish(cmd);

2. When I illuminate either the Right or the Left, but not both, what should the irCode.cpp do to get both IR Receivers illuminated:
   if (!foundDockingStation && vec3.x == 0.0 && vec3.y == 0.0) {
geometry_msgs::TwistPtr cmd(new geometry_msgs::Twist());
cmd->angular.z = 0.1; // const rotate until
cmd->linear.x = 0.0;
cmd_vel_pub.publish(cmd);
} else {
foundDockingStation = 1;

If there is no illumination of either IR Receiver, then it should begin rotation based on if (!foundDockingStation && vec3.x == 0.0 && vec3.y == 0.0) {, but the wheels quit turning. Do you think that cmd->angular.z = 0.1; is too slow for ArloBot?

Comments?

TCIII

[TCIII]

@chrisl8,

Here is a detailed look at docking using Twist as in the irCode.cpp, but it uses odometry instead of movement generated by IR beam detection.

TCIII

[TCIII]

@chrisl8,

Here is a snippet describing Cooper's docking algorithm as far as IR beam response goes:

If only R0 got RC5(0x43) code, the robot should rotate in CCW.
If only R1 got RC5(0x43) code, the robot should rotate in CW.
If both R0 and R1 got RC5(0x43) code, the robot should move forward.
If neither R0 nor R1 got RC5(0x43) code for a period of time, it should be treat as "lost docking station",
and it should go back to the previous stop.
Until the sensor limitSW is contact to the docking station. Then stop the base.

Note: In our project "got RC5(0x43) code" should be treated as R1 or R2 receivers have detected the IR beam.

Comments?

TCIII

[chrisl8]

Unfortunately Linux will move your USB devices around a lot. They are liable to change any time you reboot, or if you run any command that resets the devices, and of course if you unplug anything and plug it back in. That is why I made scripts to use stable values to find the ports when running things.
I can try to guide you through making such a script for your new device.

My testing causes my robot to just rotate constantly, which makes sense, as it is continuously in the state of "no IR signal received, rotate until it is found" since I have no input device.
Does your robot not do that?

What is the output of rostopic echo /cmd_vel?

[TCIII]

@chrisl8,

I have not looked at rostopic echo /cmd_vel recently, but will give it a shot.

As I described above, with no IR beam detected (irCode x:0, y:0, and z:0) the wheels quit turning, while with both IR receivers illuminated (irCode x:1, y:1, and z:0) the wheels turn backward as the irCode.cpp tries to back into the docking station:
cmd->linear.x = -0.08; # Going in reverse
cmd->angular.z = 0.1 * (vector3.x - vector3.y);

With x and y equal 1, angular.z = 0 so only linear.x = -0..08 which is reverse.

Yes, I would be interested in writing such a script.

TCIII

[TCIII]

@chrisl8,

Here is what I see with rostopic echo /cmd_vel:

1. No beam at the start:
   Linear
   x:0
   y:0
   z:0
   Angular
   x:0
   y:0
   z:0.1
   The wheels try to rotate left

2. Both IR Receivers illuminated:
   Linear
   x:-0.08 # backing up to the docking station
   y:0
   z:0
   Angular
   x:0
   y:0
   z:0.0 # an occasional -0.1 will appear momentarily

3. Only the Left IR Receiver illuminated:
   Linear
   x:-0.08 # why isn't x = 0.0
   y:0
   z:0
   Angular
   x:0
   y:0
   z:0.1

4. Only the Right IR Receiver illuminated:
   Linear
   x:-0.08 # why isn't x = 0.0
   y:0
   z:0
   Angular
   x:0
   y:0
   z:-0.1

5. If both IR Receivers are being illuminated and then not illuminated:
   Linear
   x:0
   y:0
   z:0
   Angular
   x:0
   y:0
   z:0
   The irCode.cpp will not try and hunt for the IR beam like it did when there was no IR beam at startup.

Observations:

1. I don't understand when only one IR Receiver is illuminated in 2 and 3 why Linear x = -0.08 while Angular z = either 0.1 or -0.1 when Linear x should be 0.0 so that Angular z will drive the robot either right or left to illuminate both IR Receivers.

2. I don't understand why the irCode.cpp will hunt for the beam at startup ( the first (1) above), but will not hunt for the beam if the beam has been illuminating both IR Receivers and then is taken away (beam lost).

Comments?

TCIII

[TCIII]

@chrisl8,

Thanks for the analysis, much appreciated.

So I could change Linear x = -0.08 to Linear x = 0.08 to have the robot chassis move forward instead of backwards to dock and then use catkin_make to recompile the code?

To use Cooper's code there has to be an input to ROS that tells the docking code when the robot is docked so that Linear x = 0.0. He apparently used a limit switch to tell the ROS code when the robot had docked, but never integrated it into the irCode.cpp.
What do you envision as the path forward now with the docking project? This could be useful for the "off the shelf" robot chassis that you have planned?

TCIII

[TCIII]

@chrisl8,

Can we work up a plan to integrate the docking code into the ArloBot/ROS software package and make it an option in the personalDataForBehavior.json file?

1. The forward looking PING will probably have to be ignored so that the robot does not attempt an Escape as it gets very close to the dock.
2. Integrate a limit switch into the PAB code so the docking codes knows when the robot is seated in the dock.
3. Come up with a charging sequence that charges both the battery and keeps the SBC and accessories running at the same time.

Comments?

[TCIII]

@chrisl8,

I changed the cmd->linear.x = -0.08; to cmd->linear.x = 0.08; and reran catkin_make. Now ArloBot moves forward when both IR Receivers are illuminated.
I left the IR transmitter off at startup and ArloBot began a very slow CCW turn when looking from the front as it searched for the IR transmitter beam. I believe that you saw the same response when there was no IR transmitter beam at start up?

Thoughts about the docking station supplied voltage and current required to charge the battery and run the SBC at the same time:

1. Most three stage SLA battery chargers require around 16 vdc. My SBC and accessories stepdown voltage regulators can handle between 12-24 vdc so that won't be a problem.
2. The three SLA battery chargers I have charge at a 1 amp rate which means that the 1 amp current is split between the two SLA batteries.
3. I would estimate that the SBC and accessories (PAB/DHB-10/Arduinos/etc) are probably drawing around minimum current while docked so maybe figure around 3 amps.
4. Therefore the docking station should be capable of supplying 16 vdc and at least 5 amps through the docking contacts.

Comments?

TCIII

[TCIII]

@chrisl8,

Bump?

I have created a find_IR_Receiver.sh script by doing the following:

1. Identified the IR Receiver Arduino to be USB0 using /dev/tty
2. Used udevadm info /dev/ttyUSB0 to determine the Arduino ID_SERIAL: "Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_019990C9". The ID_MODEL cannot be used because it is the same for all Silicon_Labs_CP2104_USB_to_UART_Bridge_Controllers.
3. Modified find_RPLIDAR.sh by changing "CP2102_USB_to_UART_Bridge_Controller" ID_MODEL to "Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_019990C9" ID_SERIAL
4. Added find_IR_Receiver.sh to ~/catkin_ws/src/ArloBot/scripts
5. However, I have to use bash find_IR_Receiver.sh to get it to execute. How do I convert find_IR_Receiver.sh to execute from the CLI without using bash ?

The personalDataForBehavior.json file can be modified to include a "useIRReceiverforDocking" where the IR Receiver ID_SERIAL can be added and the find_IR_Receiver.sh modified such that it searches for STRING=$ and LOCATION=$ that are located in the personalDataForBehavior.json file?

TCIII

[TCIII]

@chrisl8,

Instead of using the limit switch, that Cooper proposed, to indicate when the robot chassis had successfully docked with the docking station, might it be possible to use the front PING sensor to determine when the robot chassis is correctly docked with the docking chassis? The front PING sensor could be set to detect the distance between the front of the robot chassis and the docking station and the docking station code could issue a Linear x: = 0.0 Twist command to stop the robot chassis?

Comments?

TCIII

[TCIII]

@chrisl8,

Bump?

I would really appreciate a response so I can move this project to completion.

Here is a link to the ArloBot performing basic autodocking without a dock.

TCIII

[TCIII]

@chrisl8,

I experimented again today with the autodocking system and found that the autodocking software is quite capable of driving headlong into the IR Transmitter and being perfectly centered on the beam.

Observation:

The robot starts with a CCW search to detect the IR beam and as a result the Left detector is the first detector to see the beam. Since both the Right and the Left sides of the detector mount are open, the Left detector will be illuminated before the robot has almost centered itself towards the beam.
Therefore I think that is might be a good idea to shield both sides of the IR Receiver so that the FOV of each detector can be made narrower than it presently is in order to better center the robot on the IR beam.

Comments?

TCIII

[TCIII]

@chrisl8,

Bump?

TCIII

[TCIII]

@chrisl8,

I have found these high current pogo pins that can be used on the robot side to make contact with brass strips on the docking station.

I have built a fixture that attaches under the front PING mount and will support a plate to which the pogo pins can be mounted. I am also in the process of building the docking station that will house the IR Transmitter and the brass strip charging plates.

TCIII

[TCIII]

@chrisl8

Here are two photos of the IR Receiver and the Docking Probe from head-on and from above.

You can see the high current pogo pins in the center of the docking probe. There will be three pins each for the positive and negative power connections with the docking station to be able to handle both the battery charging and SBC/Accessories current requirements.

During recent testing the ir_Code.cpp code was able to bring the pogo pins to within 1/2 inch or less of the simulated docking station four inch wide brass contact strips. The docking station brass contact strips will be mounted on a moveable carriage backed by a set of springs. The ability of the brass contact strips carriage to move backward when being contacted by the ArloBot docking probe will insure positive contact between the docking station brass contacts and the ArloBot probe pogo contact.

The Escape distance of the forward PING sensor will have to be modified during the docking station maneuver in order for the docking probe to contact the docking station brass charging strips.

TCIII

[TCIII]

@chrisl8

Here is a prototype docking station that I have completed.

The pogo pins on the ArloBot docking probe contact the middle of the brass strips on the docking plate.

The docking plate is spring loaded and can move horizontally to allow for horizontal play between the ArloBot docking probe and the docking station.

The pogo pins on the docking probe can move 1/4 inch horizontally which will allow for slight off angle contact between the ArloBot docking probe and the contact plate on the docking station.

The black looking tube above the docking plate is the IR Transmitter IR LED that is encased in shrink sleeving to help narrow the IR beam.

TCIII

[TCIII]

@chrisl8,

Where have you gotten off to?

Regards,
TCIII

[chrisl8]

@TCIII

That is amazing! Lots of engineering there.

Life has gotten very busy for me. I'm still tinkering a bit, but not making enough progress on anything to report at the moment.

[TCIII]

@chrisl8,

Hi Chris,

Thanks for the response, much appreciated. I was getting a little worried there.

I believe that you have indicated that you would like to charge the battery and keep the SBC on line.

I picture two scenarios:

1. To do so will require a docking station power supply of around 5-6 amps at 16 vdc: ~1-2 amps for charging the battery and around 3-4 amps for the SBC and accessories.
   Having the SBC/Accessories on line while charging the battery will require a high current Schottky diode between the battery and the SBC/Accessories.
   The battery will charge at 14.4 vdc and the SBC/Accessories will run at 16 vdc. The Schottky diode will prevent current back flow from the 16 vdc being supplied to the SBC/Accessories.
   A the end of the battery charging cycle, the battery will be at a float voltage of ~13.6 vdc while the SBC/Accessories continue running at 16vdc.
   From my POV 5-6 amps is a lot of current and I have made allowances for that amount of current by having three pogo pins mounted horizontally in two rows for the positive and negative power connections on the docking probe. I have shown just one pogo pin in the center of the each row of the docking probe above so picture two more, one on each side of the center pogo pin.
   Likewise, the 1/2 inch wide brass strips are 1/16 inch thick to carry the current with minimal voltage drop.

2. Shutdown (remove power from) the SBC/Accessories once the ArloBot is docked and charge only the battery.
   This will require a relay between the battery and the SBC/Accessories that can remove power from the SBC/Accessories once the SBC has been commanded to shutdown.
   Once the battery reaches the 13.6 vdc float voltage, a timer circuit can determine when to energize the relay, startup the SBC/Accessories, and undock.

Comments?

TCIII
This avoids the need for a 5-6 amp power supply.

[chrisl8]

Why so many volts? My 12 volt chargers only go to like 14 volts I think, usually more like upper 13's. I think 14 is the max charging voltage for a 12 volt SLA battery isn't it, or something around 14, not 16?

Why so many amps? I'm only using a 1.1 amp charger and it is able to keep the Pi running while also toping off two SLA batteries. Without the Propeller boards, just using a Roboclaw, a Pi and a couple of other gadgets, my 750 milliamp chargers even do the job.

I feel like your setup is very different from mine if you need 16 volts at over 3 amps.

[TCIII]

@chrisl8,

All of the documentation I have read requires an initial charging voltage of 14.4 vdc and a constant current (CC) of 1-2 amps and then at the end of charge, a constant voltage (CV) of 13.6 vdc.
I have three SLA battery chargers and they all start out at 14.4 vdc and end at 13.6 vdc once the batteries are at full charge.

I am assuming an onboard battery charger which will require a 16 vdc input to achieve a 14.4 vdc initial charging voltage.

Here are the real life current draw specs on the Rpi 4B:

Raspberry Pi 4 measurements
I had OSMC with KODI running, but nothing else, i.e. the KODI UI being idle, but all the background services running. The latest firmware as of 4. June 2021 was used, storage was SDHC card only. CPU load was generated using the stress command.

The Raspberry Pi 4 consumed idle 3.8 W to 4.0 W.

With 1 core being busy, it consumes 4.5 W.

With 2 cores being busy, it consumes 5.0 W.

With 3 cores being busy, it consumes between 5.4 W and 5.5 W.

With 4 cores being busy, it consumes 6.0 W.

Taken from here.

Four watts at 5 vdc is just under one amp and if you are charging the batteries at 1 amp, then you need at least 2-2.5 amps without any accessories running. Since the Rpi will not be idling, should we assume at least one core being busy which will up the current draw a little?

Do you plan to turnoff the A1/A3 and the RoboClaw to reduce idling current? The A3 consumes around 500 ma and the A1 around 300 ma in normal operation after startup. I would say that the RoboClaw consumes at least 100-200 ma when idling.

I think that it will be a mistake to try and run low level motor control and rviz at the same time from the Rpi only. Having a processor between the Rpi and the Roboclaw/Motor Controller will help to prevent Rpi overload.

Comments?

TCIII

[TCIII]

@chrisl8,

Will it be possible for you to integrate the ir_Code.cpp node into the ArloBot ROS package in the near future so that a user can use the webui to command the ArloBot to dock.

Presently the default 12 cm (~4.75 in) halt distance for the lower center PING sensor is keeping ArloBot from docking with the docking station as front of the docking probe is ~5.7 cm from the face of the PING sensor.

Would it be possible for the docking node code to temporarily modify the default halt distance to a user specified distance during the docking process?

Comments?

TCIII

[chrisl8]

I think our goals and hopes for the electrical components are not the same. I don't intend to run an on-board voltage converter, but rather an external charger. I can see how getting one that provides more than 1 or 2 amps might be better, but I've had good luck just using the 1 amp chargers.
I also don't hope to make the Pi run Rviz on a normal basis. It is nice for initial "does it work" testing, but as a robot, it should be primarily controlled remotely.
The Roboclaw is a computer, so I intend to leverage it to replace both the DB-10 and the Propeller board and process the data to/from it on the Pi. I'm not sure what I will do about PING or other proximity sensors at this point. That is an open question.

Anyway, that shouldn't stop us from working together. The code isn't going to differ greatly, and the reality is that it may be many months before I actually have a second robot in operation anyway.

If you want me to help you customize the setup to allow you to shut down the SBC, etc. while docked, I am happy to. The biggest issue I see is how you will turn it on again when charged without having the SBC active, but if you can find a way that you are happy with, making the code work with it should be fun and doable.

---

Yes, I will try to get back to the ir code. That shouldn't be very difficult. The main difficulty is that I don't have the hardware, so I just have to let you test.

Yes, it is already possible to shut off the robot's response to PING/IR sensors, so it should be easy enough to automate that when in "docking mode". I will try to remember to do that.

[TCIII]

@chrisl8,

Thanks for the quick response, much appreciated.

I will be glad to do any testing required as I am presently a Donkey Car Maintainer who does a lot of hardware/software validation.

Right now I would appreciate being able to have the ArloBot be commanded to dock from either the CLI or the webui so that I can experiment with a number of charging schemes.

Additionally I plan to build a smaller ArloBot on a 14 in diameter chassis using an Rpi 4B, a RoboClaw motor controller, the Pololu D37 motors with encoders, and 5.7 in diameter scooter wheels.

The problem here is that a smaller robot chassis is not going to support two 12 vdc/7 amp-hr SLA batteries and I plan to move to Li-Ion batteries with charge protection circuits. I have used the Li-Ion batteries in ROVs with great success and a spotless safety record. But that is neither here nor there concerning which battery chemistry we employ.

Comments?

TCIII

[TCIII]

@chrisl8,

I also don't hope to make the Pi run Rviz on a normal basis. It is nice for initial "does it work" testing, but as a robot, it should be primarily controlled remotely.

So you plan to use either a fast (I7) PC or Laptop to run rviz remotely on Windows and offload that processing from the Rpi?

I assume that docker-view-navigation.sh still runs rviz on the Rpi or does it?

I presently have a Nano 4GB running your "Workstation via x11docker".

Regards,
TCIII

[TCIII]

@chrisl8,

Do you have any ETA in mind as to the integration of the ir docking code into the ArloBot ROS package?

Regards,
TCIII

[TCIII]

@chrisl8,

Bump?

I would really like to know about running the docker rviz as I posted above.

Regards,
TCIII

[TCIII]

@chrisl8,

Bump?

TCIII

[chrisl8]

I don't know what your question is about running rviz. You can run it anywhere. There are Windows instructions to run it on Windows. You can use the Docker container if you need to use a different version/distribution of Linux than ROS supports, and you can just run it normally on supported Ubuntu versions.

It runs fine on any modern computer and even pretty well on a Pi or other small ARM based computer.

You might double check your CPU usage if you are attempting to build a map and run RViz on the same Pi. It works, but map making can "degrade" if it is starved for CPU cycles. If it works though, then it works.

[TCIII]

@chrisl8,

When I run docker rviz on the Nano 4GB is it running on the Nano or the Rpi that the Nano is communicating with which is running the ArloBot software?

By the way, how is the ir_Code.cpp code integration into the ArloBot software package coming along? I have completed all of the necessary ArloBot and Docking Station hardware and am just awaiting the software update to be able to perform docking maneuvers.

TCIII

[TCIII]

@chrisl8,

Bump?

TCIII

[TCIII]

@chrisl8,

I have essentially completed the docking station and the ArloBot docking probe.

I have performed the following to complete the docking station/docking probe:

1. Installed a 10 amp 24 vdc switching power that can be adjusted to power the battery charging module and the ArloBot SBC/Accessories.
2. Installed a 1.5 amp 5 vdc power converter to power the IR transmitter and the adjustable timing circuit.
3. Installed a relay controlled by an adjustable timing circuit in order to prevent arcing when the docking probe pogo pins make contact with the docking station power plates.
4. Installed all six pogo pins on the ArloBot docking probe.

All that I require now is the integration of the ir_Code.cpp into the ArloBot sofware package so that the ArloBot can perform the auto docking function.

Regards,
TCIII

[chrisl8]

@TCIII

That is an impressive hardware setup.

I am sitting down now to build an initial attempt at the integration code for you to test. I should have it by the end of the day.

[chrisl8]

@TCIII

I have pushed new code that includes the auto docking functions. I haven't really tested it, so I expect it to have problems. Please give it a try and report back.

First, you need to add this to your ~/.arlobot/personalDataForBehavior.json file:

"dockingStation": {
    "_has_dockingStation": "Set this to true if you have a docking station",
    "has_dockingStation": true,
    "dockingIrReceiverUniqueString": "Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_019990C9",
    "dockingIrReceiverStringLocation": "ID_SERIAL",
    "angular_z": 0.1,
    "linear_x": -0.08
  },

Then run the setup again,
bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh)

Then start ROS and when it is going, run this script:
auto-docking.sh

[TCIII]

@chrisl8,

Thanks for the update and the kudos on the docking hardware, much appreciated.

I will test the code first thing tomorrow.

I spent most of the day attempting to make a map using ArloBot.

I found that ArloBot would veer off to the left when it should go straight when using 2D Nav Goal with Rviz.

So I ran ~/catkin_ws/src/ArloBot/scripts/PropellerSerialTest.sh and used cut and try (instead of the "[Borenstein, J., & Feng, L. (1995). UMBmark: A benchmark test for measuring odometry errors in mobile robots"] method) to adjust the wheelSymmetryError and the distancePerCount until ArloBot would go straight for 1 meter. I converged on the correct values farily quickly though I found that adjustments in the distancePerCount affected the wheelSymmetryError and vice versa.
Here is what I found:
wheelSymmetryError IS: 1.0, S/B: 0.79

distancePerCount IS: 0.00338, S/B: 0.00350

In the driveGeometry tuning guide you state that the wheelSymmetryError "accounts for a difference in left/right wheel diameter." I have accurately measured both of the six inch diameter wheels and when inflated to the same pressure, they both are the same diameter.
The only thing that I can think of that is causing ArloBot to veer off to the left of a straight line, when wheelSymmetryError is set to 1.0, is that the right hand motor is turning faster than the left hand motor for the same drive voltage?

Comments?

Regards,
TCIII

[chrisl8]

@TCIII Yes, wheelSymmetryError exists to compensate for the left and right wheels either not being of equal diameter or some other issue with the drive geometry.

The setting is the "distance per count" of the encoder, so voltage isn't a part of the issue. The wheel speed is read by the encoders, so the voltage output to wheel speed shouldn't matter, as the read wheel speed will dictate the final voltage for a given speed. Hence, the left/right side should only differ if the wheels are not the same diameter because of some abnormality like under or over inflation of one tire compared to the other, or one wheel just slipping badly and consistently.

Besides making sure it can go straight for a meter, also ensure that it can rotate 180, and 360 degrees both clockwise and counterclockwise.

Finally, you sad it would veer off to one side when under navigation control. Was the navigation clearly attempting to correct this, because it wasn't expected?
Or was this the navigation having strange ideas about the best way to get somewhere?
In other words, is this odometry failure or path planning failure?

[TCIII]

@chrisl8,

Thanks for the response and detailed guidance.

1. Both tires are inflated to the same pressure: 12 pounds atmospheric.
2. Both tires measure the same diameter.
3. There is no observable slip between the tires and driving surface.
4. There is approximately 1/2 inch of wheel circumference slop in the drive train between the motor and the wheel on both
   sides of the chassis. According to Parallax technical support this is expected and acceptable.
5. During the Rviz 2D Nav Goal the drawn path was initially straight ahead and ArloBot slowly veered to the left (began to turn
   slowly left CCW) instead of moving straight ahead as per the drawn path.
6. The slow drift to the left was observed when running ArloBot in a straight line for one meter using the maneuver function
   in ~/catkin_ws/src/ArloBot/scripts/PropellerSerialTest.sh with the default values for wheelSymmetryError and the
   distancePerCount. Changing to the wheelSymmetryError and the distancePerCount values I published in my post above
   corrected the slow drift to the left and kept ArloBot moving straight ahead for one meter.

When using the default wheelSymmetryError and the distancePerCount values ArloBot overshot the commanded angle of rotation both during CW and CCW operation.
When I use my wheelSymmetryError and the distancePerCount values the ArloBot rotation to the commanded angle is virtually spot on during CW and CCW operation.

I will have to make a disclaimer here: My Arlo robot chassis uses the Eddie chassis and the Eddie motor/ wheels, but is using the Arlo encoder and wheel disks. The distance between the center of the Eddie chassis wheels is within a 0.01 meter of the default trackWidth so I have left it at the default value of 0.403 meter.

How about if we move this issue to a new issue so that it will not preempt the docking station development enhancement issue?

Comments?

Regards,
TCIII

[TCIII]

@chrisl8,

You are right that it is not a code issue, but I was surprised at how far I had to deviate from the default wheelSymmetryError value.
I suspect that there may be a mechanical problem with the right Motor/Wheel assembly that is causing ArloBot to deviate from a straight path when using the default wheelSymmetryError value. Though the gear lash between the right and left Motor/Wheel assemblies seem to be the same.

Regards,
TCIII

[chrisl8]

@TCIII
"angular_z" and "linear_x" are being used in the C++ code in the file
https://github.com/chrisl8/ArloBot/blob/noetic/arlobot_ros/src/autodocking_irCode.cpp

At lines

ArloBot/arlobot_ros/src/autodocking_irCode.cpp

Line 30 in 458754b

cmd->linear.x = linearX;

and

ArloBot/arlobot_ros/src/autodocking_irCode.cpp

Line 31 in 458754b

cmd->angular.z = angularZ * (vector3.x - vector3.y);

and

ArloBot/arlobot_ros/src/autodocking_irCode.cpp

Line 60 in 458754b

cmd->angular.z = angularZ; // const rotate until

I added them as configuration variables to make it easier to tweak them without having to recompile every time.

[TCIII]

@chrisl8,

Nice, as I need ArloBot to move forward to dock, not backwards.

I have done the ArloBot software updates and will run setup again, but it is getting late here on the East Coast so I will run a validation test tomorrow morning.

I see that there might be a potential problem with the present auto-docking.sh script as my docking probe is inside the default forward Escape range of 12cm so the docking probe will not make contact with the docking station.

Comments?

TCIII

[chrisl8]

@TCIII
I just realized that the code I posted doesn't even compile, so I'm not sure how you were able to test it. 😁

I have posted an update, so try running setup again when you have a chance and it should work.

[chrisl8]

@TCIII

Oops, yes, I forgot to set it to disable escaping while it is docking. I had that on my list but overlooked it. I will add that next.

[TCIII]

@chrisl8,

I meant that I will run setup again, but haven't yet.

If you disable Escaping, then ArloBot will not stop when making contact with the docking station and will probably cause a motor overload.

I think that you might want to put a docking distance value in the personalDataForBehavior.json that will modify the default forward Escape distance from 12cm to a distance to be determined by measuring the distance from the front of the docking probe to the front of the forward PING sensor.
Can that be done? If so, the ir_Code.cpp will move ArloBot up to the docking station until the new docking station Escape distance value is reached and then stop. I have seen this effect when testing the ir_Code.cpp: ArloBot drove up to the docking station and stopped 12cm from the docking station and quit moving.

If the default forward Escape distance can't be temporarily modified for docking, we might have to install a limit switch on the docking probe so the docking code knows when it is docked?

However, I noticed that once the ir_Code.cpp found the docking station and moved towards it, I could stop the IR Transmitter beam and the robot would stop. I have a sensor switch on the docking station plate that senses when the docking probe makes contact with the plate and then causes the power supply relay to provide power to the plate after a suitable delay. This same sensing switch could turn off the IR Transmitter which will stop the robot as long as the forward Escape function can be turned off during the docking process.

Comments?

TCIII

TCIII

[chrisl8]

@TCIII

You can shut off the escaping behavior via the web Interface on the "Sensors" tab. Just set the "PING" to "Ignore". That would be the best way to test for now. Set that to ignore, then start the docking procedure.
Once you are sure that is what you want, I can add code that does this automatically when the docking script is run.

As you said, then it won't stop for anything, so be ready to do what you need to do to stop it, like flip the power switch by hand or whatever. I have an emergency cutoff switch on the top of my robot that I can always press to break the power connection from the motors, which comes in handy during testing.

Relying on the PING sensors for confirming "connection" presents a few problems:

1. I do not actually have a method at the moment to arbitrarily set distances in real time. As you may remember, those were set right into the C code that was loaded onto the Propeller board. So adding that ability will require quite a bit of new code updates.
2. I'm not even sure that the PING sensors can be relied on to provide a clear indication of when the sensor is at 0mm vs. 2mm or whatever your tolerance is from the destination.

Since your dock is very smart, and knows when it is connected, shutting off the IR beam seems smart, although won't that just cause the robot to start spinning again, in search of the IR beam?

I had assumed that you were going to contrive some method to stop the robot when power was connected. You were also intending to shut down the SBC during charging, so I assumed whatever method was doing that would halt the robot and shut down everything, whether that be a physical switch, or a sensor on the power line that notices when a charging voltage is present.

The safest thing would probably be to put a small bumper on the front of the robot with a switch that just kills the motors when it is pressed. Basically replacing the PING with a physical switch for full contact. That would ensure that even if the dock wasn't powered up properly, the robot would stop pushing against it as soon as it makes contact.
In theory the PING could already do that, but again, I'm not sure if they are accurate enough down to such a small distance to ensure contact. I could easily see the PING claiming "0 centimeters" when it is 3 or 4 millimeters from actually making contact with the dock.

[TCIII]

@chrisl8,

I tried running bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh) this morning and received an install failure.

TCIII

[chrisl8]

@TCIII

I will need more details than that. What was the error?

[TCIII]

@chrisl8,

INSTALL FAILURE!!!
The Install Script has failed. Please investigate the cause, correct, and run again before proceeding.

If this was a transient error, such as a network failure connecting to something, you may just need to run it again.

If this persists, please file an issue against the repository at https://github.com/chrisl8/ArloBot/issues

TCIII

[chrisl8]

@TCIII

Right, that is the final script bailing because of an error that occurred during the install, but you are going to have to scroll back in your terminal and find the error that caused the script to fail and provide it here. I have no ability to remotely investigate your system or see any terminal output other than what you provide here.

[TCIII]

@chrisl8,

Okay I got it to compile by going back to my original personalDataForBehavior.json code which you instructed me to modify with the additional "dockingStation" code before running bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh).

Should start-robot.sh run without error even without the "dockingStation" code in personalDataForBehavior.json just as a sanity check before modifying personalDataForBehavior.json with the "dockingStation" code?

TCIII

[TCIII]

@chrisl8,

Okay, start-robot.sh ran without error without the "dockingStation" code in personalDataForBehavior.json.

I will now try running start-robot.sh using the personalDataForBehavior.json modified with the addition of the "dockingStation" code.

TCIII

[TCIII]

@chrisl8,

I am getting this error after adding the "dockingStation" code to personalDataForBehavior.json when running start-robot.sh:

thomas@thomas-desktop:~$ start-robot.sh
Clearing ROS Logs . . .
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
Checking all configured devices to make sure they are available, attempt 1
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
Hardware Check SUCCESS! All devices found.
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
parse error: Invalid numeric literal at line 46, column 0
Waiting for roscore to start . . .
Waiting for roscore to start . . .
... logging to /home/thomas/.ros/log/ec2a96de-af85-11ec-a40a-b16713263cd7/roslaunch-thomas-desktop-4445.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

Waiting for roscore to start . . .
Waiting for roscore to start . . .
Waiting for roscore to start . . .
started roslaunch server http://192.168.0.65:33359/

Is this error in the personalDataForBehavior.json file?

TCIII

[chrisl8]

@TCIII
Yes, it sounds like there is some minor error in the personalDataForBehavior.json file.

You can try copying the entire contents of the file to an online JSON validator like https://jsonlint.com/ and it should tell you where the issue is in your JSON.

[TCIII]

@chrisl8

The nano edited version of the personalDataForBehavior.json with the "dockingStation" code must have had an error in it somewhere as my PC copy of personalDataForBehavior.json with the "dockingStation" code passed the JSON validation.

So I transferred the PC copy of the "dockingStation" modified personalDataForBehavior.json file to the .arlobot directory and then ran start-robot.sh and got this:
thomas@thomas-desktop:~$ start-robot.sh
Clearing ROS Logs . . .
Checking all configured devices to make sure they are available, attempt 1
Checking Camera 0 . . .
Checking Xbox Controller . . .
Checking Activity Board . . .
Checking RPLIDAR
Checking Docking IR Receiver . . .
Docking IR Receiver missing!
ERROR: Hardware failed to come on line:

1. Running find_docking_IR_Receiver.sh results in: /dev/ttyUSB0

2. Using udevadm info /dev/ttyUSB0 I get this for the IR Receiver:

ID_SERIAL=Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_019990C9

Which is identical to the ID_SERIAL that is in the personalDataForBehavior.json file.

3. Could the problem be here in check_hardware.sh:

# Docking IR Receiver

if [[ $(jq '.dockingStation.has_dockingStation' "${HOME}/.arlobot/personalDataForBehavior.json") == true ]]; then
  echo "Checking Docking IR Receiver . . ."
  if ! "${SCRIPT_DIR}/find_docking_IR_Receiver.sh" >/dev/null; then
    FAILURE_REASON="Docking IR Receiver missing!"
    CHECK_GOOD=false
    return 1
  fi
  USB_DEVICE=$("${SCRIPT_DIR}/find_camera.sh")   ### S/B find_docking_IR_Receiver.sh"

  if ! ls "${USB_DEVICE}" &>/dev/null; then
    FAILURE_REASON="Docking IR Receiver missing!"
    CHECK_GOOD=false
    return 1
  fi
fi

4. I changed USB_DEVICE=$("${SCRIPT_DIR}/find_camera.sh") to USB_DEVICE=$("${SCRIPT_DIR}/find_docking_IR_Receiver.sh") and that change fixed the "Docking IR Receiver missing" issue.

5. Running start-robot.sh ran without error. The ArloBot batteries are getting low so I shutdown to recharge the batteries and will run the auto-docking.sh script first thing tomorrow morning.

Nice work, Chris, given all of the changes/additions you had to make to get the autodocking feature integrated into the ArloBot software.

TCIII

[TCIII]

@chrisl8,

Thanks for the quick response, much appreciated. No problem giving kudos to your excellent programming efforts.

After running start-robot.sh, I ran auto-docking.sh which worked as expected except for one small issue:

1. After the autodocking code detected the IR Transmitter IR beam, ArloBot moved backwards instead of forwards even though "linear_x": is set to 0.08 in personalDataForBehavior.

2. As an experiment I changed cmd->linear.x = -0.08; to cmd->linear.x = 0.08; in mybot_autodocking_irCode.cpp in ArloBot/arlobot_ros/scripts and ArloBot still backed up after the autodocking code detected the IR Transmitter IR beam.

3. I was still mystified as to why ArloBot was backing up after the autodocking code detected the IR Transmitter IR beam. So I did a search of all of the changes you made to the ArloBot software to integrate the docking function into the existing code. That is when I found that you made a change to the Behavior.js script, in the noetic/website/src/containers directory, which changed the webui. All of this time I have been using start-robot.sh instead of the webui to start ROS. Could this be causing ArloBot to backup instead of go forward after the autodocking code detected the IR Transmitter IR beam?

4. I used the webui to start ROS and then clicked on the Autodocking button in the Behavior dropdown and waited until it turned green (On). I then ran auto-docking.sh from a terminal and ArloBot still went backwards instead of forwards when the autodocking code had detected the IR Transmitter IR beam.

Comments?

TCIII

[TCIII]

@chrisl8,

Hey Chris, we almost have the auto-docking function working which is no small accomplishment.

All we have left is to determine why ArloBot is backing up instead of going forward once the autodocking code has detected the the IR Transmitter IR beam.

Also, can you explain the function of the Auto Docking Button in the webui Behavior tab versus running start-robot.sh and auto-docking.sh?

TCIII

[TCIII]

@chrisl8

I ran an experiment this morning to see what was the value of cmd_vel during the docking process once the IR Transmitter IR beam had been detected.

Here is the result of the experiment:

linear:     
  x: 0.0
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.1     #autodocking_irCode.cpp is looking for the IR beam by rotating the robot chassis
---
linear:
  x: 0.0
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.1
---
linear:
  x: 0.0
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.1
---
linear:
  x: 0.0
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.1
---
linear:
  x: 0.0
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.1
---
linear:
  x: -0.08     #autodocking_irCode.cpp has found the IR beam, but is moving backwards instead of forward towards the docking station. 
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.0
---
linear:
  x: -0.08
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.0
---
linear:
  x: -0.08
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.0
---

I have "linear_x" set to 0.08 in personalDataForBehavior.json, but that value is obviously not be used by the autodocking_irCode.cpp code. I believe that the error might be here in the auto_docking.launch code:

<launch>
  <arg name="usb_port" value="$(optenv USB_PORT)"/>
  <arg name="angular_z" value="$(optenv ANGULAR_Z)"/>
  <arg name="linear_x" value="$(optenv LINEAR_X)"/>

  <!-- Serial Port listener -->
  <node pkg="rosserial_python" type="serial_node.py" name="serial_node" respawn="false">
    <param name="port" value="$(arg usb_port)"/>
    <param name="angular_z" value="$(arg angular_z)"/>
    <param name="linear_x" value="$(arg linear_x)"/>
  </node>

  <!-- ROS Receiver -->
  <node pkg="arlobot_ros" type="autodocking_irCode" name="autodocking_irCode">
    <param name="scale_angular" value="1.5"/>
    <param name="enable_button" value="4"/>
  </node>
</launch>

When we first developed the autodocking function it was my understanding that the audotdocking_irCode.cpp was listening (subscribing) to the IR Receiver output (publisher) irCode (ircode.x and ircode.y) over rossserial and not "angular_z" and "linear_x"?

Should "scale_angular" and "enable_button" actually be "angular_z" and "linear_x" because "angular_z" and "linear_x" need to be the same in the audotdocking_irCode.cpp as they are in the personalDataForBehavior.json? Or should "scale_angular" and "enable_button" be ircode.x and ircode.y which is what audotdocking_irCode.cpp uses to determine it has found the IR Transmitter IR beam?

Comments?

TCIII

[TCIII]

@chrisl8,

Hi Chris,

Do you think that you might have time this weekend to address linear_x value issue above so that we can wrap up this enhancement project?

Regards,
TCIII

[chrisl8]

@TCIII
Yes, I think you are right. I updated and pushed the launch file.

[TCIII]

@chrisl8

Unfortunately the changes that you made to the auto_docking.launch file did not change the behavior of Arlobot as once the autodocking_irCode detected the IR Transmitter IR beam ArloBot started going backwards instead of forwards.

For some reason the linear_x value of 0.08 in the personalDataForBehavior.jason file is not being used by theautodocking_irCode in place of the default value of -0.08 which makes ArloBot move backwards.

I believe the issue now resides in the autodocking_irCode.cpp code. I believe that this snippet of code, which is not in Cooper's original mybot_autodocking_irCode.cpp, should be changed:

  nh.param("angular_z", angularZ, 0.1);
  nh.param("linear_x", linearX, -0.08);

which is causing ArloBot to back up, once the autodocking_irCode.cpp code has detected the IR Transmitter IR beam, because linear_x is now set to -0.08.

Comments?

Regards,
TCIII

[chrisl8]

If you change the line

nh.param("linear_x", linearX, -0.08);

To

nh.param("linear_x", linearX, 0.08);

And rebuild the binary with catkin_make does it fix the issue?

[TCIII]

@chrisl8,

Changed nh.param("linear_x", linearX, -0.08); to nh.param("linear_x", linearX, 0.08);, ran catkin_make, and reran start-robot.sh followed by auto-docking.sh. That cured the issue with ArloBot backing up instead of going forward once the autodocking_irCode had detected the IR Transmitter IR beam.

However, why isn't the autodocking_irCode code using the linear_x from the personalDataForBehavior.jason file? Is it because the autodocking_irCode binary code cannot be changed once compiled? Or is there a way around this issue?

TCIII

[TCIII]

@chrisl8,

Can you explain the function of the Auto-docking button in the webui Behavior tab in relation to running start-robot.sh and auto-docking.sh to initiate autodocking? Is the Auto-docking button even functional?

TCIII

[TCIII]

@chrisl8,

As I asked above, is the Auto-docking button in the webui Behavior tab functional or not. If it is functional, what docking function process does it initiate?

TCIII