How do we get good repeatability in XRP line follow PD control when the battery voltage level appears to affect the performance?
I just wrote a line-follow demo program of PD control for my young students.
https://youtube.com/shorts/Oi6MzjQznoE?feature=share
However, I do not get good repeatability.
With the same setup, the robot would overshoot the turn about 10% of times when the battery is freshly charged. I am thinking that perhaps the battery power is not regulated on the XRP board, resulting in variations in motor and sensor performance over time. I could not find the circuit diagram in PDF format in XPR Github. I do not have KiCAD installed yet to read the circuit CAD file.
Would it work better if I add a 5V regulator circuit to the AA battery pack?
or if the max. current draw is the issue, should I switch to a 2S Li-ion battery pack with regulated output?
Please advise. Thank you.
Charles
Can’t say about line following, but the board does include a voltage regulator, a buck converter that lowers the input voltage to about 5.1V, which is used to power the motors. However, it only works if the battery voltage is higher than 5.1v (in fact, there is some voltage drop on the regulator, so you probably need around 5.5V input). If the battery voltage is lower than that, the motors will get (battery voltage - voltage drop) voltage.
For context, a 4-cell NiMH has nominal voltage of 4.8v; in real life, voltage will range from 5.6v (fully charged) to 4v or lower when discharged.
I do not think the current draw is the issue - these motors do not need much current unless you stall them.
What XRPLib motor functions are you calling during your line following?
When my FTC team is having issues with repeatability of their AUTO routine based on battery level, I talk with them about switching from motor.Power (Effort) to motor.Velocity (Speed). This brings motor encoder data in and adjusts the power commands to maintain wheel speed. An overshoot with freshly charged batteries would create similar behavior.
If you’re working from the Delivery Challenge Guide, I’m not sure how the Arcade command is built (power v. speed). Given that the Forward argument takes values between 0 and 1, I predict it is using Effort commands.
It may be beyond your young students, but you can program your own Arcade function using Speed commands to determine if you continue to see behavior differences based on battery charge level.
The motor drivers use the raw battery voltage, so lower battery voltages will result in the motors having less power. This is pretty normal in the world of robotics, so it’s best to use the encoders in some way to compensate for variations in battery voltage. Though if you really want a stable voltage, providing a regulated voltage (eg. regulated 2S LiPo like you mention) could work too.
This page has a PDF of the schematic if you want to take a look! Resources - SparkFun XRP Controller Hardware Overview
This thread got my brain stuck on a speed based Arcade function. I finally got around to building it today.
This has been working for me so far. See if it can help make your line follower more consistent. I did have to tune the DriveEffort and Proportional Gain (Kp) to get the XRP to stay on my course.
I wanted this to be a drop in replacement for the Arcade block, so I used the same function arguments: Straight [-1,1] and Turn [-1,1]. I did a quick run with a print blocks to see what Effort 1.0 with no load would produce for speed, which was around 200 rpm, so this is a local variable/constant.
I’ve been doing several Outreach Events with our FTC team. I wanted an XRP running a closed line following course to create motion in the booth and draw people towards the booth. This means the robot is going to be running for hours. It’s best if it can run on its own so I can get in a conversation with someone and not have to constantly be tapping the robot to keep it on the line. What happened most recently is that we had a booth at an outdoor flea market. The grassy area where the booths were had uneven ground. As the XRP was climbing the hill, it would get stuck at the top corner. Once we pulled it around the corner it would continue on the path fine. As Dryw showed in the Movement Guide video, as the load on the motors change (I.e., driving uphill) the Speed command compensates by applying more power to maintain wheel speed. It also means that the XRP doesn’t slip off the corner driving downhill.
I use a different approach to avoiding clipping by the motors than is used in the differential_drive.py code for the arcade function. Someone may have to walk me through how the Turn/(Straight + Turn) works the same way.
