Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Examine Linorobot again. You will see very detailed instructions for building a robot, both the hardware and the software. In our world, bullet, platform, cat are all fully compliant Linorobot robots.
For the SBC we use either a Rasperry Pi 3B+ or a Raspberry Pi 4
Lidar is connected via USB to the Raspberry Pi
The Microcontroller is connected via USB to the Raspberry Pi
For the microcontroller we use either a Teensy 3.2 or a Teensy 4.x (check this)
The motor controller is connected to the Teensy via
The IMU is connected to the Teensy via I2C bus
The SBC is running Ubuntu 20.04 and ROS 1.0. It is a standard install which we get from the Linorobot installation. Of course our own ROS code and scripts are then added to it. Certain standard Linorobot Nodes are launched.
The Teensy code is provided by Linorobot. We have tweaked it in small ways. See How To for information on rebuilding it and installing the software. This software has the following jobs:
Read the encoders to determine the apparent speed and direction of the robot
Subscribe to cmd_vel to determine the desired speed and direction
Use a PID controller to drive the motors to meet the desired speed and direction
Publish the actual speed and direction as computed by the encoders as ODOM_RAW
Read the IMU data (via the I2C bus) and publish it as IMU_RAW
Read other I2C sensors and actuators (coming soon!)
Linorobot is a software package for building our own robots. We have used their software and instructions to construct our own robots and configure the software for them. The above link is a major resource for you. In this section we will explain things that are specific to Brandeis but we won't repeat it.
Consistent across Platform 1, 2 and 3?
Raspberry Pi 4b
Arduino Teensy 3.1
MPU 9250 IMU
YDLidar X4
When a new robot is built, there are a number of steps needed to see that it is properly configured.
Encoders need to be connected correctly. The left and right can be swapped, and also they may be backwards. These issues lead to very crazy and incomprehensible behavir, so it's best to check them first if your new robot is acting weird.
Motors also need to be connected correctly. They can be left-right swapped or forward-reverse swapped. It is worth again to test them separately. The kind of incomprehenible behavor from this kind of problem is totally different from the one when the encoders are backwards or swaps.
It is very important that you know what the front of the robot is. Otherwise nothing makes sense. Our robots have the big wheels in front and the casters in back.
The IMU is connceted via an I2C Quick Connector to the Teensy. We have seen problems when the IMU doesn't work that were caused by the placement or length of the wire, so keep an eye out for that case.
The most common problem with a new build is that the pin numbers are incorrect. You can find the hardware configuration in linorobot/teensy/firmware/lib/config/lino_base.h. In that same directory you will find other versions of that file for our different models. If you are qualifying a new model, then you should add a copy there.
There are numberous variables in this file. The key ones for now are:
and
MOTOR1 is front left, and MOTOR2 is front right. There are several misconfigurations possible, basically all the permutations of left/right and forward/backward, on both the motors and encoders.
If all wheels are spinning but the robot spins in circles, goes backward, is unresponsive to cmd_vel commands or in general acts crazy, your first hypothesis should be that one or more of the pins above are incorrect or swapped.
If one of the wheels doesn't spin at all then it's probably an electrical connection to the motor. If both wheels don't spin then it's probably a power/battery issue.
To check the encoders, disconnect the power from the motors, leaving just the encoders. Then when you roslaunch linorobot minimal.launch it will print four numbers over and over again which are the readings of the potential for encoders (two in front and two in the back.)
As I had only two wheels I just got two non-zero numbers. Put the robot on the floor and push it gently forward. Those two numbers will change. They should both go up approximately as fast, even though they are not the same number. In my case, they went in opposite directions. Note the one that is going down. The left wheel is encoder1 and the right wheel is encoder2. In the setup file I switched the pins for the corresponding motor and that solved it.
(Note: This is very obvious but I got it wrong: The caster is on the BACK of the robot not the front. You need to know what is the front of the robot to know which wheel is left or right.)
For me, this didn't quite solve it. So the next thing to check was the motor itself. I changed the Arduino code (.ino) so that instead of sending the calculated numbers to the motors, I sent 100 to the left motor and 500 to the right motor. This is so that I could tell if the left motor turned slower than the right. If not, I had to switch those pins. Next I had to tell that both motors turned so that the effect was forward motion of the robot. That was incorrect for me too. That too is fixed by switching PIN numbers.
Next came the PID settings. The instructions are good there in terms of getting monitoring the result of the pid calculations but not as far as what numbers are right. There are an infinite number of references on the web on tuning pid and they are all vague and different.
Here again I made a small change to the Arduino code. I had it print out the error between the desired and actual rate of the left and right wheels. If things are working like they should that error starts at zero and when you give the robot a command it temporarily goes away from zero and then returns nicely to zero. I don' know yet what "technique" I used, nor whether I have the right parameters yet. But at least the robot is behaving better.