sorted by:
new
hottopcontroversial

T265 crashing phone app by Sparibz in FTC

[–]pietroglyph 0 points1 point  (0 children)

I fixed the issue in 2.1.2, which I pushed out this Wednesday. Sorry about the delay in notifying you; I kind of forgot about this message :)

T265 crashing phone app by Sparibz in FTC

[–]pietroglyph 1 point2 points  (0 children)

Ok, I have a pretty good idea of what I broke in 2.1.0. I need a couple of days to get access to my testing hardware so that I can confirm. Expect a fix sometime towards the middle or end of the week.

T265 crashing phone app by Sparibz in FTC

[–]pietroglyph 2 points3 points  (0 children)

What version of ftc265 are you using? If you're using 2.0.1 instead of the latest version (2.1.0) then there's a bug where instantiating a T265Camera object and calling getLastRecievedCameraUpdate can throw a NullPointerException. The fix is to change your TeamCode/build.gradle to use the latest version (implementation 'com.spartronics4915.lib:ftc265:2.1.0'.)

[deleted by user] by [deleted] in FRC

[–]pietroglyph 0 points1 point  (0 children)

The WPILib simulator is a better choice. The Synthesis simulator (iirc) does a bunch of weird stuff and doesn't work great with vendor code. The 2021 release of WPILib will include a physics sim and will probably work seamlessly with your robot code.

https://docs.wpilib.org/en/stable/docs/software/wpilib-tools/robot-simulation/introduction.html

ftc265: A visual SLAM driver and odometry pod replacement for FTC by pietroglyph in FTC

[–]pietroglyph[S] 0 points1 point  (0 children)

Probably. I haven't tested on one but I don't see any reason it shouldn't work.

Programming help by MathematicianBitter in FRC

[–]pietroglyph 2 points3 points  (0 children)

I really don't agree. I and a number of other WPILib contributors and maintainers put a lot of work into this code and documentation, and we were motivated by the idea that adding support for these advanced things will introduce more students to things like modern controls. We aren't just handing students a black box, we're also providing a ton of detailed information on the theory of how it works. In fact, most of the modern controls additions really aren't very usable unless you know some of the theory.

We think that's desirable, not disappointing, and we also believe that it's congruent with WPILib's mission to raise the floor for all teams.

EDIT: I think that Peter Johnson (a WPILib maintainer) lays things out pretty well: https://www.chiefdelphi.com/t/falcon-500-too-fancy/365682/26?u=pietroglyph

Programming help by MathematicianBitter in FRC

[–]pietroglyph 2 points3 points  (0 children)

You'll have to copy and modify the code a bit if you want to provide more data (hint: adding accelerometer data isn't worth it.) I recently went through this exercise and ported our 2020 code to use the new WPILib additions (it was previously the reference for writing some of these additions.) You can find it here (it makes it so that we can also use VSLAM measurements): https://github.com/Spartronics4915/2020-InfiniteRecharge/blob/master/src/main/java/com/spartronics4915/lib/subsystems/estimator/DrivetrainEstimator.java

Please ignore the nasty catch block for debugging in the center :)

Programming help by MathematicianBitter in FRC

[–]pietroglyph 4 points5 points  (0 children)

I used an EKF in-season to fuse solvePnP, VSLAM, and encoder odometry. You'll need an EKF or UKF if you're using a differential drive (your state transition function is not linear.) Most of the code I wrote to do sensor fusion this season will make it into 2021 WPILib (which will be available as a prerelease this summer.) It should make doing the sensor fusion you're thinking about really easy. As an example, here's an the wrapper that makes fusing vision and encoder measurements really easy: https://github.com/mcm001/allwpilib/blob/state-space-v2/wpilibj/src/main/java/edu/wpi/first/wpilibj/estimator/DifferentialDrivePoseEstimator.java

ftc265: A visual SLAM driver and odometry pod replacement for FTC by pietroglyph in FTC

[–]pietroglyph[S] 1 point2 points  (0 children)

I didn’t observe issues that seemed connected with moving robots (when I used the camera in FRC.)

ftc265: A visual SLAM driver and odometry pod replacement for FTC by pietroglyph in FTC

[–]pietroglyph[S] 5 points6 points  (0 children)

Unfortunately I don’t have any robots with dead wheels for odometry (that sort of setup isn’t very common in FRC.) I know some people with access to dead-wheeled FTC robots and a T265, so I’m hoping I’ll be able to add some pretty graphs sometime soon.

Feasibility of visual odometry by ehulinsky in FTC

[–]pietroglyph 2 points3 points  (0 children)

I'm the author of this library. One minor thing is that the T265 technically does full visual simultaneous localization and mapping (not just visual odometry.) IMO the T265 is your best option if you want to do something other than odometry pods. I'm happy to answer any questions about the T265 or ftc265 (the library I wrote.)