Open ryalisuchir opened 10 months ago
Maybe the splines are just taking too long to generate? Ideally you could time that section and print out how long it takes. The easiest knob to make generating splines faster is reducing the resolution (or at some point consider migrating to RR 1.0 which generates trajectories more quickly).
What do you suggest reducing the resolution to? Will this still be accurate? What does the resolution change?
You can change the resolution to something like 2-4 inches. The resolution affects the sampling of constraints for motion profile generation. The higher the number is, the coarser the profile is and the less strictly constraints will be followed.
You mentioned constraints, are these constraints like velocity or specific to accuracy? Will decreasing the resolution cause motions to be less accurate?
Also, if I switch to rr1.0, my arm subsystem uses RR0.5.6's MotionProfile class. Would I need to copy in the Kotlin function for that? Also -- I'm looking at this Action system. If I need to run a PID loop or something similar, should I still create an Action and just run that Action within the loop?
You mentioned constraints, are these constraints like velocity or specific to accuracy? Will decreasing the resolution cause motions to be less accurate?
Don't worry too much about accuracy here.
Also, if I switch to rr1.0, my arm subsystem uses RR0.5.6's MotionProfile class. Would I need to copy in the Kotlin function for that?
You can use https://rr.brott.dev/docs/v1-0-0-beta6/core/kdoc/core/com.acmerobotics.roadrunner/constant-profile.html or copy the old code. Whatever floats your boat.
Also -- I'm looking at this Action system. If I need to run a PID loop or something similar, should I still create an Action and just run that Action within the loop?
You can write your own action or use whatever FSM/asynchronous system you have already.
Alright sounds good. I'm looking at the FTCLib sample command written in https://rr.brott.dev/docs/v1-0/guides/ftclib-commands/ Assuming I use this for my drive command like so:
Action movement1Left = drive.actionBuilder(drive.pose)
.splineToConstantHeading(new Vector2d(26.03, 42.57), Math.toRadians(270.00))
.splineToConstantHeading(new Vector2d(26.03, 53.19), Math.toRadians(270.00))
.splineTo(new Vector2d(48.67, 36.65), Math.toRadians(0.00))
.build();
CommandScheduler.getInstance().schedule(
new SequentialCommandGroup(
new ActionCommand(movement1Left) //error on this line since I'm not specifying any requirements
)
);
Requirements can't be left empty but I don't believe I have any. What is generally used in the requirements section? Can I just set this as null? Or Collections.emptySet()?
Each command should declare any subsystems it controls as requirements. This backs the scheduler’s resource management mechanism, ensuring that no more than one command requires a given subsystem at the same time. This prevents situations such as two different pieces of code attempting to set the same motor controller to different output values.
(from https://docs.wpilib.org/en/stable/docs/software/commandbased/commands.html#getrequirements)
If you don't care about the guarantees provided by requirements, you can give it an empty set.
This has persisted as an issue for us for RR0.5.6. Changing the resolution to any number has not changed anything, unfortunately. We ran a Profiler to check CPU/Memory. The image is attached.
CPU spiked at 53% and 253mb Memory. Is there a fix for this?
I'm wondering if this is a FTCLib/RR issue. I tried directly creating trajectory sequences in init without using the subsystem, and it still lagged out until an eventual "stuck in stop."
We ran a Profiler to check CPU/Memory. The image is attached.
This image unfortunately is not very helpful. I need more granular information about what the CPU is executing. See this section on the timeline view. I can be most helpful if you export a trace and attach it here for me to take a look. Make sure you capture the trajectory generation process in the trace. I would start the trace in Android Studio, initialize the op mode with the trajectories, and let it collect data for 15s before stopping.
I'm wondering if this is a FTCLib/RR issue.
Seems unlikely given that you can comment out a few trajectories and have everything run fine. (As an aside, one of the trajectories you commented out is likely the problem. Consider trying to reproduce with one of them in a smaller op mode with less going on.)
So I'm trying to export the trace now, but it's not an option. I right-clicked on the CPU part. Although it's an "option," it doesn't let me select it. I've also tried going through the sessions pane. It only gives me an option to delete the trace there.
Since the control hub is Android 7 (I think?), it doesn't allow me to record the trace...
Maybe you need to follow these instructions: https://developer.android.com/studio/profile#advanced-profiling
You can also (1) make a small example without dependencies on your code and have me profile (like what happened in https://github.com/acmerobotics/road-runner/issues/97#issue-2082585152) or (2) print timings in your opmode of each segment individually to find the problem segment.
I'm trying to run a RR command in an OpMode by initializing it in init, and it keeps stalling in init and then says "Stuck in Stop." This only happens when I add multiple splines.
When I add the trajectories in start, the init process works fine, and then it stalls in a position when I click start, waits 15 seconds, and then says "Stuck in Stop." Everything works fine when I remove the trajectories or some of the splines.
OpMode:
DriveSubsystem: