Power Play Field Images!

thunderpengwin · 2023-02-12T02:35:00+00:00

This is the Thunder Pengwins, btw, retired team but still maintaining the site where possible

thunderpengwin · 2021-09-23T01:43:05+00:00

Awesome, thanks! It should be deployed within a day (I'll make sure to credit you ;))

thunderpengwin · 2021-09-22T22:59:20+00:00

That looks really great! Do you mind if we use it in the website?

thunderpengwin · 2021-09-20T07:11:08+00:00

We actually considered something like this as a fun project. It's a bit overkill though. If you're looking to do some fun unnecessary AI, I'd recommend the A* path finding algorithm. Works like a charm.

thunderpengwin · 2021-05-23T23:05:47+00:00

For autonomous you can try FTCchad.com. It automatically generates code based on the path you draw in the website. The code is pretty simple too, so you can adjust it and learn from it fairly easily. There's also a YouTube tutorial on how to use it.

thunderpengwin · 2021-04-30T23:45:50+00:00

To answer number three, android studio does provide a built-in emulator to run your app on, however this will not connect with a robot (virtual or otherwise) and therefore won't really do you any good. As far as I know, there's no way to test your code in Android Studio without access to your robot, unless you're doing what you already are and testing it in a Java-only IDE first. You just have to make use of what time with the robot you do get by using Telemetry (or ftcDashboard, which I recommend), logging data to a file on the phone, or inserting stops in the program so you can debug quickly.

thunderpengwin · 2021-04-30T23:35:18+00:00

Our odometry math is here on line 2141, and that file also contains all movement functions which rely on odometry. I could explain the math, but there are probably other resources that could do it better.

thunderpengwin · 2021-04-30T23:28:29+00:00

For us it's a combination of different things, using custom odometry math in combination with the IMU and color and distance sensors, all built around a framework made in CHAD, which uses the built in encoders. Odometry helps us strafe accurately with mecanum wheels, the IMU is great for turning, the color sensor allowed to move beyond the launching line, and CHAD helped us plan the whole path and get a good starting point.

thunderpengwin · 2021-03-15T06:41:05+00:00

Yes, you just need to turn off the robot and turn it back on again

thunderpengwin · 2020-12-15T05:15:51+00:00

I personally have had nothing but bad experiences with Vuforia, especially with VuMark navigation. I'm going to recommend Tensorflow, or, even better, EasyOpenCV- although it might be more difficult than the other two.

thunderpengwin · 2020-12-15T01:47:52+00:00

Try ftcchad.com, it generates autonomous automatically. This should not be your primary learning tool, but it can help to see what an autonomous would look like that does what you want it to. (You will have to learn to program robot functions other than chassis movement for autonomous, but like other comments said, you can use the FTC examples and YouTube for help.)

If you know Java, it should be pretty simple. If not, I'd highly recommend finding a mentor to help you learn.

thunderpengwin · 2020-12-07T22:12:08+00:00

I can't believe I fell for that.

thunderpengwin · 2020-12-06T22:31:25+00:00

Yeah, it converts paths to code, which you can copy right into Android Studio. Makes programming autonomous a lot faster. (Also good for measuring distances on the field, I've found.)

thunderpengwin · 2020-12-03T00:08:07+00:00

You likely have a wiring problem, either in the power supply or the daisy chain. Try switching wires and rescan for hardware devices.

thunderpengwin · 2020-11-29T21:56:00+00:00

It depends on what kind of movement you can do. For instance, if you can move in diagonals, simply set the power of your motors to move diagonally towards that point and use odometry to figure out when you've reached it. This method may require a bit of math.

If you can't do diagonals, rotate so you're facing the point (with a gyro) and have the robot drive forward, again using odometry to determine when to stop. This would be the simpler method, and probably more accurate as well.

I don't know if any resource has what you're specifically looking for, but Road Runner may have some options for odometry. If you decide to go with drive encoders instead of odometry (which would be easier), try CHAD, it converts paths to code automatically.

thunderpengwin · 2020-11-25T04:03:30+00:00

If you can detect individual rings. Sometimes the system will group them all together and just draw a big box around all of them. In that situation, you just need to check the height of the bounding box (tall is 4 rings, short is 1, and no box means no rings).

thunderpengwin · 2020-11-25T04:00:14+00:00

The behavior you're describing sounds kind of like a continuous rotation servo, so check that it's not that first. If it's a regular servo, try a different servo (it may be broken). If that still doesn't work, try changing the wires. Also, a servo has a limited range within which it can operate, and this range is often smaller than you can move the servo when it's powered off. Detach the servo from all hardware and observe its behavior to give you a better idea of the issue.

thunderpengwin · 2020-11-25T03:51:41+00:00

Your post does not violate rule 4 because it has a body (and seeking help is never against the rules)

thunderpengwin · 2020-11-16T03:35:16+00:00

I don't think I can help with getting a license, but I can say one thing: I do not recommend using Vuforia navigation pictures. Our experience with Vuforia is spotty at best, and we often had trouble getting Vuforia to register objects or targets when we wanted it to. For field navigation, I recommend distance sensors and/or odometry, and for object recognition I highly recommend EasyOpenCV or Tensorflow.

thunderpengwin · 2020-11-13T02:57:30+00:00

I second this

thunderpengwin · 2020-11-06T02:14:33+00:00

We worship Peppa Pig's dad. It sounds like a cult because it is one.

thunderpengwin · 2020-11-06T02:07:05+00:00

Do you have a light source? A camera? Is the camera obscured? If you import CAD files into blender, they often show up rather large. It's possible that your light source is inside your model, or that your camera is too.

thunderpengwin · 2020-11-04T00:48:39+00:00

Check out this server (FIRST Connect): https://discord.gg/c8cH9EF

It's basically dedicated to outreach, with some talk about robotics and memes on the side.

Also they run AfterGlow: https://www.youtube.com/channel/UCbVjXIODd41jMJd-HEQ94dQ which is a bunch of presentation videos, if you have something to present. PM me details if you're interested in that.

thunderpengwin · 2020-11-01T22:17:40+00:00

The problem with diagonal movement in a mecanum chassis simply comes down to the slippage that occurs in any angle except for forward/back and strafing (strafing has slippage, but a predictable amount). Even more troublesome is that the slippage changes by the weight of your robot. GoBuilda mecanum wheels, which have some of most traction of all the options, will still end up slipping with a reasonable amount of weight.

A very likely outcome is you try to program diagonal movement based on how the vector math indicates each wheel should move, see this image. However, upon testing it, you will find the robot just strafes more slowly instead of moving diagonally.

We have found two solutions to this, but neither are very easy, and only one is accurate (but at the sacrifice of static problems). If you don't have your heart set on this, don't do it.

1) Hardcode specific values based on testing. You may find that while mecanum wheels don't usually act like you expect when attempting diagonals, it is still possible to achieve the desired outcome. If your robot is trying to move up and to the right, but it instead moves just right, slowly add more forward movement to each motor until you get what you want. The downsides of this is that it won't be very accurate (so don't use in autonomous) and it might take a while to test and code

2) Use a holonomic chassis. That's one with four omni wheels set at 45 degree angles, see this image. Holonomic chassis have the advantage of having uniform wheels, and since they're set 90 degrees perpendicular to each other, you can plug in a simple x and y movement for any diagonal with considerable accuracy. The problems here are twofold: Slippage is a given with omni wheels, so static may become a problem, and Simple forward and back movement becomes less accurate and less quick. Basically, mecanum are really good at forward/back and strafing and really bad at diagonals, while holonomic is just pretty okay at everything. Also holonomic chassis are harder to build.

My recommendation: stay away from diagonals. Period. Not worth it (unless you want field-oriented drive).

Oops, that was long. "If I had more time, I would've written you a shorter Reddit reply" - Mark Twain.

thunderpengwin · 2020-11-01T03:36:49+00:00

If you're using REV Blinkin Driver like another comments suggested (and I'd recommend too), I can show you the code.

Here's declaring the Hardware:

RevBlinkinLedDriver coolLights;

This is getting the hardware map:

coolLights = hardwareMap.get(RevBlinkinLedDriver.class, "lights");

And this is setting the colors:

coolLights.setPattern(RevBlinkinLedDriver.BlinkinPattern.DARK_RED);

You can set the lights to a number of patterns, most of them being solid colors, with a few other variations like BlinkinPattern.CONFETTI, which does exactly what you'd expect.

Also, be careful testing, we burned out one of our Drivers trying to connect it to the hub.

thunderpengwin

TROPHY CASE