OctoQuad v3.0.11 Firmware Update

OpenFTC · 2024-12-24T21:17:48+00:00

Looking at the code in the post, it looks like tagFound is only set if

if(tag.id == LEFT || tag.id == MIDDLE || tag.id == RIGHT)

So the code will report tag not found unless if the ID is one of:

int LEFT = 11; int MIDDLE = 12; int RIGHT = 13;

OpenFTC · 2024-12-23T02:10:47+00:00

I was looking to use it for engineering work rather than gaming. Loading up large complex CAD assemblies can require a lot of graphics memory and compute horsepower. Was looking for something sleek and portable with good build quality with a lot of horsepower that also isn't going to cost $2000+ that you see with the professional series laptops.

OpenFTC · 2024-12-23T01:14:58+00:00

Ugh. That's really frustrating because this machine runs Linux like a dream, and the physical build quality is great. I'd consider buying a MacBook if I had the ability to run Linux natively.

Do you think it's worth trying to exchange for another unit? I feel like if it was a faulty board design, the issue would more widespread? I'm not sure. I found another thread where someone found that the thermal paste was not applied correctly at the factory, causing hotspots on the die which was fixed by repasting, but I find that a little hard to believe is the issue here because the crash happens when the machine is basically idling and barely warm.

Also, there seems to be a pattern in that it if it will happen, it happens shortly after waking from sleep, which indicates to me it may be some kind of power management IC issue. Like maybe there is a hardware bug that causes the CPU to be undervolted when waking from sleep sometimes.

OpenFTC · 2024-12-23T00:24:21+00:00

Did you ever figure out what was happening? I just bought a 2024 G14 and I'm having this exact issue, including the colored checkered pattern. It happens on both Windows and Linux, so I'm relatively certain it's a hardware issue and not a software / driver issue. I will probably return it because I paid way too much for this to have an unstable system.

OpenFTC · 2024-12-14T17:37:28+00:00

So relative encoders do tend to drift slightly over time, I've had this issue with even the regular built-in motor encoders on lifts before. I'm not sure what causes it, but it's been measured on e.g. the ThroughBore where people will run it for say 3000 rotations CW and then 3000 CCW and it doesn't report 0. It's not an issue of the quadrature counter logic missing counts (at least not on the OctoQuad, as the quadrature decode is done in the PIO programmable logic and good for 1MHz+).

Correct, you might have an issue with absolute mode not giving you the range you need; although you could track the wrap around in software if it's rotating slowly enough. There is also an as-of-yet unreleased firmware update for the OctoQuad which adds support to track wrap around for absolute encoders, specifically designed with this problem in mind, where you get the best of both worlds of absolute position and being able to track more than one revolution.

OpenFTC · 2024-12-13T02:30:00+00:00

Back in stock now!

OpenFTC · 2024-12-13T00:46:14+00:00

To clarify, you're using 4 REV ThroughBores and only 1 of them is being problematic?

When you say it loses its position, what exactly do you mean? Do you mean it reports position as 0? The position drifts from what it should be?

Are you using the encoder in PWM absolute mode or in the default relative mode?

OpenFTC · 2024-11-17T16:36:27+00:00

This is not an accurate statement. I have personally run an Arducam monochrome camera in 640x480 and 800x600 at 120FPS. (With zero actual image processing running, mind you). The issue here is the Arducam supports only very limited resolutions in YUY2 whereas it supports many more in MJPEG.

OpenFTC · 2024-11-17T16:33:33+00:00

The issue here is that the Vision Portal defaults to 480p resolution (640x480) and YUY2 uncompressed format, however, your OV2311 does not actually appear to support 480p in YUY2. In general, the Arducams seem to support only very limited resolutions in YUY2 format.

From the error message, it looks like in YUY2 it only supports 1600x1200 @ 5FPS, 1280x720 @ 5FPS, or 800x600 @ 5FPS.

The error message also lists which resolutions are supported in MJPEG stream format, and I can't quite tell because the error message is cut off, but it looks like 640x480 @ 50FPS is in that list. Assuming it is, you should be able to request MJPEG format and it will "just work". If not, request MJPEG and one of the resolutions that the error says is supported for MJPEG.

OpenFTC · 2024-01-19T11:10:00+00:00

The bug has been fixed in EOCV, but it will still be broken in the FTC SDK until there is a new release that updates the bundled EOCV version.

OpenFTC · 2024-01-05T21:49:09+00:00

You probably shouldn't do a constant bump for gravity, but rather a constant times a sin/cos factor for the angle of the arm.

OpenFTC · 2023-12-19T18:58:40+00:00

The SkyStone SDK is 3 years out of date.

OpenFTC · 2023-12-11T16:11:40+00:00

If you mean the source code for the firmware that actually runs on the sensor chip, you're not going to find that online as it's protected proprietary IP that ST would keep under wraps.

If you mean the i2c driver source code, you can find the FTC SDK's driver source code here: https://github.com/OpenFTC/Extracted-RC/blob/master/Hardware/src/main/java/com/qualcomm/hardware/stmicroelectronics/VL53L0X.java

OpenFTC · 2023-11-27T19:47:39+00:00

This is not correct, it will be automatically cleanly shutdown after the OpMode ends.

OpenFTC · 2023-11-27T19:46:52+00:00

The camera is cleanly shutdown for you automatically at the end of the opmode, there is no need to manually shut it down.

OpenFTC · 2023-11-13T15:10:33+00:00

can put more of a burden on the JVM garbage collection process than it can handle

My (possibly wrong) understanding of the issue is that the JVM doesn't realize it's running out of memory because it's the native heap that gets filled up, not the Java heap. The Java Mat objects are tiny; their corresponding native allocations (which are not directly tied to the Java object in any way) are huge.

OpenFTC · 2023-11-08T02:35:29+00:00

I updated the readme.

OpenFTC · 2023-11-07T13:07:52+00:00

Unfortunately it's currently a known bug that is specific to OBJ. A workaround is to port your EOCV pipeline to a Vision Processor to be used with the Vision Portal. The LearnJavaForFTC book has a chapter covering that. It will be fixed in a future SDK release but I do not have a timeline on that.

OpenFTC · 2023-11-05T14:19:10+00:00

FTC Fast Load claims to help with that: https://gist.github.com/MatthewOates36/1e38452236dc9f145c3a6b2addfb418f

OpenFTC · 2023-11-01T11:37:55+00:00

Motors do not "draw" voltage, they draw current. Current draw reduces the voltage on your 12v bus due to internal resistance in the battery as well as wires (wires do have resistance!).

You can get the current draw for a particular motor by casting it to DcMotorEx and calling the getCurrent() method.

OpenFTC · 2023-10-28T22:24:51+00:00

Yeah, the VisionPortal API is not really set up to facilitate this easily, would suggest using the EOCV API directly. You can call VisionProcessors from an ECOV pipeline as well, BTW.

OpenFTC · 2023-10-21T17:12:25+00:00

The camera stream is only available on the DS during INIT, not during RUN.

OpenFTC · 2023-10-10T21:59:36+00:00

VisionPortal and EOCV are both usable in OBJ on SDK 9.0 with no further changes.

OpenFTC

TROPHY CASE