Theoritical Background
The kinematics model of the bot gives us the equations that define the relation between position and velocity, which can be used for localization. The UV robot is based on a differential drive model where two wheels are independently actuated to control all the motions(forwards, left, right, back) of the UGV. There is also a third unactuated freewheel that is used to support the bot. The point of rotation about which the robot turns is called the instantaneous center of curvature (ICC). In the current application, only point rotation is required i.e. rotation about the center of the bot. The equations for point turn, relating the linear velocity of motors to the angular velocity of the bot are as follow:
Ω = Vr.(2/D)
Ω = Vl.(2/D)
Where Vl and Vr are the linear velocities of the right and left wheel respectively and D is the diameter of the bot or the wheelbase. The angular velocity due to both wheels is the same and given by Ω. The total angular velocity of the bot is 2Ω. For forward and backward motion, the linear velocity of the wheels is the same as that of the bot. Given by,
V=ω.(r)
ω is the angular velocity of the motor and r is the radius of the wheel.
There are two methods of controlling the BLDC motor. They are sensorless control and sensored control. Sensorless motor drivers are used in high-speed applications such as drones and low-speed application sensored control. Sensored BLDC motor uses hall effect sensors to activate the coils at regular intervals as it is a closed-loop type of approach the motor control is precise when compared to the sensorless approach. Our application is low speed and needs precise motion. We selected BLDC Hub motors for the bot, which required a good motor controller for it to be speed regulated via ESP32. Before selecting the appropriate motor drive, all the motor specifications were matched with the driver limits, assuming a FOS, a generic BLDC motor driver was selected. It works on 5v logic level, provides PWM speed control of the motor, and also has other features like over-current and over-voltage protection.
Key factors for selecting a motor driver :
-
Operating current The operating current of the motor driver must be greater than(recommended) the stall current the motor requires. Check for the continuous current motor requires. Generally, if the stall current is satisfied motor driver can provide sufficient continuous current.
-
Operating voltage and power rating Power rating gives an idea of the max amount of current that can be drawn based on the operating voltage of the system. The battery pack selected should be able to satisfy the need of the current surge if it arises.
-
Control Few motor drivers use communication such as I2C for speed and direction control of motors. If the application requires speed and direction control using a limited number of GPIO one can select these motor drivers. Some of the drivers offer speed control with the help of a PWM signal that can be generated by the GPIO of the microcontroller.
| Motor Specifications | Motor Driver Specifications | |
|---|---|---|
| Operating voltage range | 20-36V | 12-36V |
| No-load speed | 210+/- RPm | - |
| No-load Current | <800mA | - |
| Rated load | 5N-m | - |
| Continues current | <5A | <=15A |
| Stall Current | 13A REF | <=15A |
| Stall Torque | 13N-m REF | - |
| Power | (24*13)312 W | 500W |
| Speed Control | - | 0-5v [PWM] |
| Overcurrent protection | - | yes |
| Speed control | - | yes |
| Direction control | - | Yes |
Table 1. Comparison between motor driver and motor specifications
Fig. 1. Motor driver
Generally, BLDC motors have phase windings that are activated according to the commutation logic, using sensored BLDC motor control we can get the position feedback of the rotor as well as it can help in commutation. The motor driver has the closed-loop control mechanism which takes hall sensor feedback and activates the windings accordingly. Speed control using PWM and direction control using a digital signal are provided.
5V -Driver board internal output voltage.
Signal – Motor speed pulse signal output port, 5V pulse signal.
Control port:
- Z/F– Rotating direction control ports. Connect “5V” high level or no connect is Forward direction, connect 0 V low level or connect to GND is a reverse direction.
- VR -Speed control port. Analog voltage linear speed regulation 0.1v -5V
- GND—Used for Drive board internal control.
Motor port :
- MA - motor phase A
- MB - motor phase B
- MC - motor phase C
- Hx - Hall sensors connection
Even though ESP32 has a grid-based3.3V logic level we are assuming that the motor driver that works on 5V logic level will have “a high signal” threshold above 2.5V and ESP32 will be able to activate the motor driver signal pins such as direction pin. Another thing that needs to be checked is the PWM compatibility, as the MD PWM port requires 0 to 5V for 0 to 100% of the speed of the motor. We need to make sure the maximum speed required falls under the corresponding voltage level of ESP32(max is 3.3v).
- Maximum speed of the bot- 0.05m/sec = 50mm/sec = 3000mm/min.
- Rated speed of the motor- 115 RPM.
- Wheel diameter - 170mm.
- Distance covered in one rotation of wheel- 170*pi = 534mm.
- RPM of the motor at the maximum speed of bot- 3000/534 =~ 6 RPM (maximum motor speed)
- Now, 6 RPM is 5.2% of the rated speed which corresponds to a voltage level of 0.261V.
- If we want to change it in the duty cycle percentage for 3.3V logic =~ 8%.
All the Wi-Fi credentials(SSID and password), recorded paths and the path names are stored in ESP32 flash using the SPIFFS file system. Two text files have been created, one for storing Wi-Fi data and the second for recording the path and storing its name. We have limited the maximum number of Wi-Fi credentials that a user can store to 5 and the maximum number of paths that can be stored in the file as 5. Wi-Fi data is updated as and when new networks are added in the STA mode. In the case of path storage, initially, the user must record the path using manual mode and the path is stored as a series of operations taken by the user separated by spaces in the paths.txt file, the pathname that the user enters is stored as the last element of the path. This data is appended to the path.txt file when recording is completed and the number of valid paths is updated. Different paths are separated by “\n” characters. In the code, mention of temp.txt is also there but that acts as a temporary file to copy the previous data and add new data which is then renamed to path.txt, after deleting the previous path.txt file. The representation of data stored in the file is shown below. the
Example wifi.txt :
Initial wifi.txt when booted for the 1st time:
SAP
example example
example example
example example
0
0
eg.1)
STA <-Means the ESP should operate in STA mode
Dummy1 pass1 <-Network 1 SSID is Dummy1 and Password is pass1
Dummy2 pass2 <-Network 2 SSID is Dummy2 and Password is pass2
Dummy3 pass3 <-Network 3 SSID is Dummy3 and Password is pass3
example example <-This is a dummy value which means this is not a valid network
example example <-This is a dummy value which means this is not a valid network
2 <-This means that Network 2 details need to be used
3 <-This means that we have 3 valid networks as shown above
eg.2)
SAP <-Means the ESP should operate in SAP mode
Dummy1 pass1 <-Network 1 SSID is Dummy1 and Password is pass1
Dummy2 pass2 <-Network 2 SSID is Dummy2 and Password is pass2
Dummy3 pass3 <-Network 3 SSID is Dummy3 and Password is pass3
example example <-This is a dummy value which means this is not a valid network
example example <-This is a dummy value which means this is not a valid network
0 <-This is always set to 0 when operating in SAP mode
3 <-This means that we have 3 valid networks as shown above
Example paths.txt :
eg.1)
Initial recording
3 <-Means we have 3 valid paths stored
x1 y1 x2 y2 x3 y3 uvw<-Path 1
x1 y1 x2 y2 x3 y3 pqr<-Path 2
f1300.0 b980.50 r1900.2 l1200.00 xyz<-Path 3
eg.2)
After path to coordinate conversion for path 3
3 <-Means we have 3 valid paths stored
x1 y1 x2 y2 x3 y3 uvw<-Path 1
x1 y1 x2 y2 x3 y3 pqr<-Path 2
x1 y1 x2 y2 x3 y3 xyz<-Path 3
The other method is the way we store the paths and path names in .txt files. The Wifi.txt file is the same as method 1 in this method the path names are stored in a different file called pathname.txt file and the current path which is executed in auto mode is stored in currentpath.txt.In the pathname.txt file, the path names are stored in different lines. Currentpath.txt just holds one path which is currently being executed in auto mode; once the whole path is executed the file is deleted.
Example pathname.txt :
eg.1)
floor1 <-dummy pathname
xyz <- dummy name
Example paths.txt :
eg.1)
Initial recording
3 <-Means we have 3 valid paths stored
x1 y1 x2 y2 x3 y3 <-Path 1
x1 y1 x2 y2 x3 y3 <-Path 2
f1300.0 b980.50 r1900.2 l1200.00 <-Path 3
eg.2)
After path to coordinate conversion for path 3
3 <-Means we have 3 valid paths stored
x1 y1 x2 y2 x3 y3 <-Path 1
x1 y1 x2 y2 x3 y3 <-Path 2
x1 y1 x2 y2 x3 y3 <-Path 3
Example currentpath.txt
eg.1)
x1 y1 x2 y2 x3 y3
The robot must be trained to navigate autonomously in auto mode. The paths are stored as follows: “f1.3000 b9.8000 r1.9002 l.1200 f1.2400”. The first letter tells about the executed operation forward-f, backward-b, left-l, right-r and followed by the distance traveled in meters for forward and back and in case of left and right the letter is followed by the angle rotated in radians. When the user records the new path, the path is stored based on the operation in terms of the distance traveled or the angle rotated and is converted to a 2D grid coordinates system that is used in auto mode to traverse the path autonomously. The grid coordinates are calculated by using basic geometry calculations as we have the distance traveled in meters and angle rotated in radians using this information the grid coordinates are calculated. The variable result length is allotted dynamically by estimating the path's length; this way, it makes it possible to avoid storage issues. This logic is whenever the user records a new path and this logic is only implemented to one path which is recorded as the other paths are already converted into grid-based coordinates and saved in the path.txt file. The paths which are already in grid coordinates are copied to a temp file whereas the path which is yet to be converted is stored in a string which is passed to the convert to coordinates function, then transformed to grid coordinates and stored in the variable “result”. It is then written in place of the previous path format.
Fig. 2. Path to coordinates conversion flowchart
The key role of a battery monitor is to constantly measure the battery pack SoC. Battery pack Soc is calculated based on the battery pack voltage by using the coulombs counting method. The battery pack used in the robot is made of Li-ion cells with a capacity of 10Ah and a voltage of 36V. Each cell used in the battery pack is 3.6V with a capacity of 5000 mAh. A typical battery pack voltage would be within the range of 2.8 to 3.0 V, considered the discharged/low voltage state. Considering 3V as the complete discharge state of one single battery, the battery pack's complete discharge voltage would be 30V keeping the factor of safety for long battery life as 8%. The threshold for considering that the battery is running low is 32V. After research on battery voltage measuring, we came up with 2 different approaches. They are using a Voltage divider circuit or using an op-amp-based circuit.
Voltage divider circuit for monitoring battery pack: The easiest way to monitor voltage is by using a voltage divider circuit which can bring down the voltage of the battery pack (36v) to 3.3v logic level and then ESP32 ADC is used to estimate the SoC then displaying on the webpage. Using a voltage divider circuit can help us in monitoring the battery state but it's not an efficient way of measuring the battery SoC, due to power loss via the resistor.
Fig. 3. Voltage Divider
Op-Amp based circuit for monitoring battery pack: Usage of the op-amp inverter is energy efficient and we can adjust the gain to attempt bringing down 36V to 3.3V level. But using an inverting circuit gives the output voltage of reverse polarity and the microcontroller is not able to measure the output voltage. So we cannot use this approach unless output from the inverting circuit is given to another inverting circuit with gain 1 to get the +ve voltage which can be measured by the microcontroller.
Fig. 4. Op-Amp circuit
Comparison between op-amp and voltage divider circuit:
| Voltage Divider | Inverting Op-Amp |
|---|---|
| Uses simple resistors to step down the voltage. | Gain is adjusted for limiting the output |
| Needs +Vcc and GND | Needs +Vcc and -Vcc |
| Construction is simple and needs no additional components. | Circuit construction is simple but the resources needed are not present in our robot(-Vcc supply). |
| Power loss can be minimized with a high resistor value but it slows the high-frequency response(not required in our case). | Power loss is the same as the voltage divider but a high resistor value doesn’t alter the response. |
| Provides no isolation between the voltage source and the microcontroller but can be isolated using galvanic or optical tech. | Provides isolation/infinite resistance. |
The control algorithm implemented to move the individual motors at the desired speed for straight, left, right, and backward motion is PID. For localization and replicating the motion, it is important to know the right position of the bot, and in the current stack, as we are only utilizing the dead reckoning method to record the path[instead of using other sensors like LIDAR and IMU], it becomes necessary to match the output to the input. For these reasons, a Proportional Integral and Derivative control is applied on top of a velocity feedback function. The feedback to the closed-loop control loop is obtained from the encoders, and the control signal is the PWM which is passed to the motor driver. The same control algorithm is used for both linear velocity and angular velocity loops, only difference is in the desired velocity given as input to the function. In the case of linear motion, the linear velocity of both the wheels should be equal to the linear velocity of the bot, hence the required velocity is directly passed to the function. For angular motion, both the wheels contribute to the angular velocity of the bot, and for point rotation(about the bot center), each wheel should contribute half the angular velocity required that’s why half of the desired angular velocity is passed to each of the wheels.
current_error = desiredvel - actualvel
accumulated_error +=current_error
pid = Kp*current_error + Kd*(current_error - prev_error) + Ki*accumulated_error