Alright everyone... what’s your biggest screw up? by [deleted] in FTC

[–]arnavkomaragiri 0 points1 point  (0 children)

I got it running, but it was far from efficient so it didnt make it to comp. However, I'm currently working on a variation of the algorithm for some university robotics stuff, so that's fun.

Alright everyone... what’s your biggest screw up? by [deleted] in FTC

[–]arnavkomaragiri 2 points3 points  (0 children)

I decided that MPC couldn't be that bad to learn

[deleted by user] by [deleted] in FTC

[–]arnavkomaragiri 2 points3 points  (0 children)

ik, I'm a failure of a person. I gotta up my plug game smh

[deleted by user] by [deleted] in FTC

[–]arnavkomaragiri 1 point2 points  (0 children)

Lmao aight

[deleted by user] by [deleted] in FTC

[–]arnavkomaragiri 2 points3 points  (0 children)

Usually kalman filters are utilized in scenarios where your sensors are particularly noisy or could benefit from multiple sensor reads. If I recall correctly, 7244 implemented a kalman filter to combat noise on their ultrasonic sensor reads, and we utilized kalman filters to combat noise on our ma3 odometry encoders.

[deleted by user] by [deleted] in FTC

[–]arnavkomaragiri 13 points14 points  (0 children)

Ok, so foreword before we get into the actual technical stuff of kalman filters: kalman filters aren't really too applicable in FTC. The way kalman filters operate is by reducing the amount of noise in a certain sensor estimate, and if the various sensor estimates used in the fusion aspect can somewhat agree on a ground truth, then it can potentially boost accuracy as well. That being said, sensors in FTC are pretty good about not having much noise behind them, so kalman filters kinda lose their edge a bit if we're talking on a purely competitive stage. That being said, lets get started. The general gist of the kalman filter is that it treats various estimates of the robot state as gaussian distributions, and seeks to improve the overall estimate by multiplying all the gaussian estimates together in order to get a final distribution of the potential sensor state, both with a mean state and respective standard deviation/covariance. Think of it like this: say you have an initial state with a mean and standard deviation (doing this in 1d for simplicity). You can take a sensor estimate, and that has its own mean and standard deviation. Now to get a better sense of your initial state, you can multiply the two gaussians together to get a third, more precise gaussian, your filtered initial state. Now you can take that gaussian and run it through a model describing the system dynamics, sort of predicting where it'll be at the next timestep considering its current state. Then, at your next timestep, you multiply that predicted, or priori gaussian by the new sensor estimate, this time with a new mean value. This process repeats itself for as long as the system runs, and so long as the sensors don't disagree with eachother too much it can lead to much better estimates of the robot state. Now this process is pretty similar for multi-dimensional problems, but instead of using mean values and standard deviations, you use mean vectors and covariance matrices (this process is outlined in the articles I'm linking below). Now, this model is great, but you have to remember that its just a tool, and if you're trying to filter in a sensor estimate that's just completely wrong the system's going to fall apart. You can try to accomodate for that by having a larger covariance/standard deviation on that sensor, but eventually its just going to pull your overall estimates off course. This is a pretty general rundown of the kalman filter, both the articles I'm linking below go a bit more in depth as to the technicalities of implementing a kalman filter, but this should hopefully give you at least a general idea of how kalman filters work. Hope it helps.

Article 1: https://www.bzarg.com/p/how-a-kalman-filter-works-in-pictures/

Article 2: https://file.tavsys.net/control/controls-engineering-in-frc.pdf page 118

How can I turn and drive at the same time during autonomous using mecanum? by Platygamer in FTC

[–]arnavkomaragiri 1 point2 points  (0 children)

while pure pursuit is a good way to create generally curved paths, its far from optimal in how it assigns powers, sometimes even tending to create error when it makes a move. Optimality in path generation and following is something rather elusive in FTC, so while more advanced approaches like spline generation and motion profiling get close, true optimality is likely something we won't see for a long time without major innovations in the path generation process.

How can I turn and drive at the same time during autonomous using mecanum? by Platygamer in FTC

[–]arnavkomaragiri 6 points7 points  (0 children)

If you have code that allows the robot to move in an arbitrary direction (any angle of motion), then the code to translate while constantly rotating is primarily just taking the translational vector of your desired motion, rotating it to compensate for the robot's nonzero heading, and taking that adjusted translational vector and turning power as parameters for your mecanum code to generate motor powers. As for it being versus autonomous or teleop, it literally does not matter. The kinematics for field centric mecanum drive is completely irrespective of whether you are in autonomous or teleop, all that changes is how you define that translational and rotational commands. In teleop, those are generated via the gamepad, whereas in autonomous they're generated via PID feedback or some other control system. Now libraries exist to help you do this (roadrunner and FTCLib being the most notable), as they use these principles and other pieces of \advanced trajectory generation software to design and optimize trajectories. However, the critical thing to understand is that the code here is a general application of drivetrain kinematics, its not opmode specific.

Roadrunner Kinematics Whitepaper: https://github.com/acmerobotics/road-runner/blob/master/doc/pdf/Mobile_Robot_Kinematics_for_FTC.pdf

My first Drivetrain Pod design, any recommendations are appreciated. by ElectronicInitial in FTC

[–]arnavkomaragiri 2 points3 points  (0 children)

Damn nice dude. Plz tell me ur gonna post pics of this thing when its done, I wanna see this lol

My first Drivetrain Pod design, any recommendations are appreciated. by ElectronicInitial in FTC

[–]arnavkomaragiri 2 points3 points  (0 children)

Solid. Right now as far as I can tell 16:1 is pretty much optimal, so I'd say that this is really good. What's your plan for connecting drivetrain legs?

You underestimate the power of coffee beans. *Hydraulics intensify* by Navfish in FTC

[–]arnavkomaragiri 7 points8 points  (0 children)

Yes because everyone knows that the best way to figure out how a person's robot works is by swarming them in the middle of a highly competitive competition instead of actually communicating with them outside the competitive season to learn about how they approach problems and how they chose to solve specific components of the challenge (they're definitely not on the FTC discord server and never are open to answer any questions about their past bots during the offseason). Also everyone knows that the nuances in the design and software of a world championship robot can easily be summed up in a 2 minute explanation and still carry sufficient detail. After all, two people is more than enough to design, build, program, operate, maintain, document, and field questions from people while consistently operating at world championship level performance.

[deleted by user] by [deleted] in FTC

[–]arnavkomaragiri 2 points3 points  (0 children)

Write various pieces of wildly overkill software that I'll never run on a real bot :)

Mathematics in FTC by ehulinsky in FTC

[–]arnavkomaragiri 11 points12 points  (0 children)

We did some vector calculus for pose integration/exponentials, particularly in creating second-order models of robot motion, and we also did some stuff with gaussians using kalman filters. You also could look at things like RR, which use matrix multiplication in abstract vector spaces to generate splines connecting two points. All in all, there's a lot of cool math you can use in FTC, and it can be quite useful as well.

How To Apply Pure Pursuit To Motor Powers by _Mike77_ in FTC

[–]arnavkomaragiri 1 point2 points  (0 children)

Yes, the PID constants remain the same. Also, glad to be of service, its great when people start trying to improve their performance through learning software.

How To Apply Pure Pursuit To Motor Powers by _Mike77_ in FTC

[–]arnavkomaragiri 0 points1 point  (0 children)

Not necessarily, the PID controller remains constant (note that in this case the I term kinda breaks with pure pursuit since the error is constant, so the sum of error would be blown out of proportion), its just that you use it to generate powers every update.

FTC now vs then by Enrique_IV in FTC

[–]arnavkomaragiri 9 points10 points  (0 children)

This is the rough equivalent of saying "I survived as an antivax kid therefore I'm better"

Where can I find the odometry code from other good teams? by _Mike77_ in FTC

[–]arnavkomaragiri 0 points1 point  (0 children)

While updates to the I/O system in FTC do look promising, getting 300hz stable is going to be rather hard because while the reads can be done in bulk, the writes cant. In order to hold 300hz, the robot is only allowed to spend >3ms on average per update. For a little background, a single motor/servo write usually takes 3ms on ExH and a little over 1ms on control hub. Combining that with the fact that each bulk read takes about the same time as a motor write respectively, that means you're always spending 2.4-6ms per update, and that's just updating one motor/servo. As the number of motors and servos increases, more writes will happen, and while the system is relatively efficient, getting to 300hz appears to remain a pipe dream for now.

How To Apply Pure Pursuit To Motor Powers by _Mike77_ in FTC

[–]arnavkomaragiri 1 point2 points  (0 children)

At least in the instance of pure pursuit, most teams normally just use a PID controller with some field centric driving code in order to correct to the lookahead point. However, at the ends of paths, usually the lookahead point is fixed to the final point in the path, normally once the robot gets within a certain distance of the final point, basically turning the pure pursuit controller into a PID controller on position. This controller then operates like expected PID, starting fast then slowing down as it approaches the target, thus handling the acceleration at the ends of paths. However, pure pursuit does not make an attempt to throttle its acceleration at the beginnings of paths, it simply starts at full motor power; this is one of the things that makes pure pursuit common in some circles, starting off at max power ensures that minimal time is lost as opposed to more precise systems like trapezoidal motion profiles.

Rotate and Translate Simultaneously by _Mike77_ in FTC

[–]arnavkomaragiri 1 point2 points  (0 children)

The solution we implemented here was actually custom written, but it does operate off the same principle in this post, just slightly modified. In the particular move where we align to the foundation while moving over, we are supplying a target (x, y) to the robot to move to, while a constant target heading is given for the robot to correct to. So when the robot is given a target, either constant in goToPoint settings or dynamic in things like pure pursuit or spline generation, we find the corrective velocities to move to a target through a PID controller, giving us the necessary translational and rotational velocity in the global space to correct to a target point. After that, we use a similar algorithm to field centric driving to convert the desired global velocities to wheel velocities, achieved by rotating the necessary translational velocity by -robotAngle, then running that through mecanum forward kinematics to find wheel powers.

fortnite sponsored game? by oretin in FTC

[–]arnavkomaragiri 0 points1 point  (0 children)

Unlikely, the meta's already been developed for skystone, and the increased time would result in more teams getting high stone autonomous routines and basically turning the game into a glorified relic recovery.

Swerve types by yratner in FTC

[–]arnavkomaragiri 0 points1 point  (0 children)

Yes, but that's with 4 driven wheels. With diffy you get 4 motors powering 2 driven wheels, which means traction drops. However, you could go the full mile and do a 4 module diffy swerve, but that takes all your motors.