PROS 2D Motion profiling **HELP**

Programming Support PROS Support
#1

I am attempting to use the okapilib 2D motion profiller for autonomous movement of the chassis. However there are quite a few issues that I am having:

If I change the code for the pathfinding generator even one tiny bit eg.

profileController->generatePath({
{0_ft, 0_ft, 0_deg},
{3_ft, 0_ft, 0_deg}},
"A"

to

  profileController->generatePath({
  {0_ft, 0_ft, 0_deg},
  {3_ft, 0_ft, 0_deg},
  {3_ft, 0_ft, 90_deg}},
  "A"

then the autonomous simply does nothing, the robot does not move!

Also, if I change the _ft to _cm it does the same.

Another thing to note is that if I use the code below, the robot moves less than 2 feet instead of the 3 that I told it to go!

#include "main.h"
#include "okapi/api.hpp"

using namespace okapi;

auto chassis =
  ChassisControllerBuilder()
    .withMotors(1, 2)
    .withDimensions(AbstractMotor::gearset::green, {{4_in, 14.9_in}, imev5GreenTPR})
    .build();

auto profileController =
  AsyncMotionProfileControllerBuilder()
    .withLimits({1.0, 1.0, 5.0})
    .withOutput(chassis)
    .buildMotionProfileController();


void autonomous()
{
	#define SIG_1			1
	pros::Vision vision_sensor (20);
	pros::Motor leftdrive (1);
	pros::Motor rightdrive (2, true);
	pros::Motor leftintake (3);
	pros::Motor rightintake (4);
	pros::Motor lift1 (5, true);
	pros::Motor lift2 (7);
	pros::Motor cage (20, true);
	pros::Motor liftIntake (9);
    pros::ADIAnalogIn sline (2);
	leftdrive.set_brake_mode(pros::E_MOTOR_BRAKE_BRAKE);
	rightdrive.set_brake_mode(pros::E_MOTOR_BRAKE_BRAKE);
	leftintake.set_brake_mode(pros::E_MOTOR_BRAKE_HOLD);
	rightintake.set_brake_mode(pros::E_MOTOR_BRAKE_HOLD);
	lift1.set_brake_mode(pros::E_MOTOR_BRAKE_HOLD);
	lift2.set_brake_mode(pros::E_MOTOR_BRAKE_HOLD);
	cage.set_brake_mode(pros::E_MOTOR_BRAKE_HOLD);
	liftIntake.set_brake_mode(pros::E_MOTOR_BRAKE_HOLD);
	cage.set_gearing(pros::E_MOTOR_GEARSET_36);
	lift1.set_gearing(pros::E_MOTOR_GEARSET_36);
	lift2.set_gearing(pros::E_MOTOR_GEARSET_36);
	leftdrive.set_gearing(pros::E_MOTOR_GEARSET_36);
	rightdrive.set_gearing(pros::E_MOTOR_GEARSET_36);

  profileController->generatePath({
  {0_ft, 0_ft, 0_deg},
  {3_ft, 0_ft, 0_deg}},
  "A"
);
  profileController->setTarget("A");
  profileController->waitUntilSettled();

}

Are there any PROS 2D motion profiling tutorials besides the https://okapilib.github.io/OkapiLib/md_docs_tutorials_concepts_twodmotionprofiling.html
one? < this one is not really a tutorial, just a model for one particular piece of code, it doesn’t explain how you customise it or even change it slightly to fit your needs!

#2

I am not an expert on using motion profiling for Pros, but my take on this is that I believe you are asking the controller to make too sharp of a turn.

In that tutorial, it says,
"Pathfinder cannot generate negative velocities, so backward movements and very tight turns do not work

Backwards movements do work by the way, you just say setTarget(“a”, true)

Anyways, pathfinder (which is what creates the paths in the motion profiling) doesn’t like arc’s . In my experience, it only worked well with S-curves. I’d do some testing to see the limitations of what you can do with it.

For your second issue of the robot not going far enough, it may be because you have a gear ratio on your drivetrain. There may be other ways to fix this, but you can adjust how far the drivetrain drives by changing the “4_in” in the chassis constructor.

Also, I advise you to change your .withLimits to the tutorial’s 1,2,10. Those constants work very well for every robot I have built.

Good Luck!

4 Likes
#3

The 1,2,10 made my robot jolt so that’s why I changed it! PS: Our robot is way too heavy!
I have a 1:1 ratio for drive so I don’t know what’s going on there!
Thanks for the help, but are you saying that the 2D motion profiler can’t do point turns, because if so I can’t use it for the auton!

#4

Hm, unless ur not using 4in wheels, I don’t know why it would be driving short. I guess you may just have to compensate by changing the wheel diameter in the constructor, not the most elegant solution but it should work.

And yes, it definitely can’t do point turns. In my set-up last year, I used the okapi PID for point turns, and motion profiling for distances. From my testing I found the motion profiling for distances to be a lot better than the okapi pid for distances. Theres nothing wrong with using multiple controllers for different parts in your auton

1 Like
#5

ok, thanks [20 characters]

#6

Also of note is you can use different profiles for different paths.

Here is a test I did in Okapi3/Pathfinder that drove fast for straight line and slower for s-curves. I would assume it works in Okapi4/Pathfinder too.

okapi::AsyncMotionProfileController profileControllerF = AsyncControllerFactory::motionProfile(
  1.06 * 0.9,  // Maximum linear velocity of the Chassis in m/s
  2 * 0.9,  // Maximum linear acceleration of the Chassis in m/s^2
  10.0 * 0.9, // Maximum linear jerk of the Chassis in m/s^3
  *chassis // Chassis Controller
);

okapi::AsyncMotionProfileController profileControllerM = AsyncControllerFactory::motionProfile(
  1.06 * 0.66,  // Maximum linear velocity of the Chassis in m/s
  2 * 0.66,  // Maximum linear acceleration of the Chassis in m/s/s
  10.0 * 0.66, // Maximum linear jerk of the Chassis in m/s/s/s
  *chassis // Chassis Controller
);


 profileControllerF.generatePath({Point{0_in, 0_in, 0_deg}, Point{36_in, 0_in, 0_deg}}, "A");
 profileControllerF.setTarget("A");
 // calc next path during this path 
 profileControllerM.generatePath({Point{0_in, 0_in, 0_deg}, Point{32_in, 28_in, 0_deg}}, "B");
 profileControllerF.waitUntilSettled();

 profileControllerM.setTarget("B", true);
 profileControllerF.removePath("A");
 profileControllerF.generatePath({Point{0_in, 0_in, 0_deg}, Point{36_in, 0_in, 0_deg}}, "C");
 profileControllerM.waitUntilSettled();
3 Likes