send a picture of your chassis, I’ll measure it in cad. I do not believe that measurement is possible
edit: @1408F the wheel width is 1.125 so 1.125/2 x 2 which is 1.125 so like subtract that by the values u gave me 14.685 - 1.125 which is 13.56 this is impossible in the vex system unless you’re doing some wack stuff
Wheel track means the shortest distance between the center of the tire treads on the same axle. On vehicles having dissimilar axle widths, the axle with the widest distance is used for all calculations.
try to remeasure
You could really do with looking at the okapilib definition of track width.
Just because it says this on law insider doesn’t mean its the same as the okapilib definition, see my previous posts.
the okapi definition is the same basically. The math I did is the same as the okapi definition
can you just show how yours has that measurement
I’m not in the position to do that right now but I can tomorrow!
ok besides, that’s the only reason I think it’s off
Why does it seem to be off to you is my question though? We have checked it multiple times.
u know tolerances exist right? this is vex we’re talking about lol
2 Likes
The chassis is pretty dodge but there are a multitude of different factors at play here, spacings, structure, collars, etc. As @Ethan5956F, it is likely that you won’t stick to the strict positions and hole sizings that vex offers purely due to tolerances.
My advice to my team is to use a ruler to get an initial value.
Then, program the robot to turn 360 degrees. Invariably, it won’t turn exactly 360. From there, one can adjust the track-width empirically.
Prior to doing this, you’ll probably want to have the robot drive straight for some distance (4 feet maybe) and make sure that 4" wheels really travel 12.56" per revolution. (Tip of the hat to anyone who can explain why the sequencing - working on straight-line drive then on turning - is critical)
Program to spec but adjust to reality.
5 Likes
Because if you apply magic number for rotation before correction for wheel circumference then you will need to do it again after you do the straight line experiment.
However, if you just measure exact rotation after commanding 360 deg turn (several times, then average) and then measure exact driven distance after commanding 1 m driving forward (several times, then average) - then you can enter into the program both corrections at once regardless the order of experiments and as long as correction to the rotation takes into account circumference correction.
4 Likes
So I have fixed the issue with the turning, after putting in the correct values for everything and inverting the middle encoder, it finally works. The middle encoder was accentuating rather than correcting lateral drift! However, I have another problem!
I cannot seem to get the current Odom state to print in the terminal. I get this when I run my code:
the code is:
#include “main.h”
#include “okapi/api.hpp”
using namespace okapi;
std::shared_ptr<OdomChassisController> chassis = ChassisControllerBuilder()
.withMotors({1, -2}, {-4, 3})
.withDimensions(AbstractMotor::gearset::green, {{3.25_in, 393_mm}, 540})
.withSensors
(
ADIEncoder{'A', 'B'},
ADIEncoder{'E', 'F', true},
ADIEncoder{'C', 'D', true}
)
.withOdometry({{2.75_in, 212_mm, 120_mm, 2.75_in}, quadEncoderTPR})
.buildOdometry();
void initialize() {}
void disabled() {}
void competition_initialize() {}
void autonomous() {}
void opcontrol()
{
chassis->setState({0_in, 0_in, 0_deg});
while (true)
{
printf("%s\n", chassis->getState().str());
pros::delay(100);
}
}
1 Like
Now I am getting (null) until I move the bot, at which point I get a data abort exception!
GetState() returns a structure of type Odomstate where it’s data elements are of type QLength QAngle, you need todo some C++ pointer and conversion stuff to display it’s values
chassis->getState().str().c_str() seems to work, dunno if this is what you meant but thanks anyway!
1 Like