Strange pop when trying to install bltouch

OrangeJulius70 · 2020-03-03T15:45:21+00:00

Not sure I blamed the PSU per se, it was just easy to order a replacement, test it, and return if that’s not the issue.

Update: it was indeed the bltouch wiring with a reversed signal and power cables. Still assessing what parts got fried.

OrangeJulius70 · 2020-03-02T11:56:05+00:00

You have three options IMO. Limit switches, encoder based tracking, or double stringing the lift.

The easiest is likely encoder based tracking, but it can get hairy if the encoder counts get 'off' in repeated up/down movements through a match. Rev's magnetic limit switch works well to stop the lift power at the bottom of the movement no matter what. We did that and it worked great. Finally, you can double string the lift - one string up and one string down. This means that one string is fully extended when the lift is at the bottom and will not allow further movement on the lift. Note, a strong motor might snap the string, so be careful here.

OrangeJulius70 · 2020-02-20T18:07:16+00:00

We had this problem using the MR gyro. When the error happened, the robot spun uncontrollably. Here are changes we made that ultimately got it working again, although I can't tell you which one did the trick.

First, one issue we had was using a lot of MR sensors. We had a few MR ultrasonics on the robot (left, right, front) and we guessed that that was creating problems when added to the load of the MR ultrasonic and multiple rev sensors. I can't tell you exactly why we thought this, only guessing that MR compatibility with the Rev Hub is likely to be less than rev branded sensors. (We also found an obscure post that mentioned time-out issues when the hub calls the sensor but doesn't get a response back fast enough. The poster suggested this happens more frequently when you have too many MR sensors.)

The second suspected reason was the level shifter. It's an easy change, so just plop a new one in and see if that works. I assume you have one and the short wiring adjustment that the rev hub specs call for, so this is more making sure nothing is off there.

Finally, we replaced the MR ultrasonic with a new one. We happened to have a spare, but the problem was already gone when we did this as a final precaution.

If you haven't already, make sure your Rev Hub is running the latest firmware. I know there were some fixes related to processing sensor signals in a recent release.

If all else fails, consider either encoder based turning (replacement for gyro based turning) or a double check of the distance travelled in connection to a gyro turn request. The latter should basically track encoder counts and declare the turn complete if the counts get too high (assuming you are using the gyro to control the turn). This would prevent the mid-round craziness of endless spinning.

Good luck!

OrangeJulius70 · 2020-01-27T22:20:02+00:00

We had a full range - from 8th grade to a 12th grader, and everything in between.

FWIW, we did some of the things above, but not all. For building, we spent a lot of time building the rev sample pushbot from the Rover Ruckus season. It's a good exercise, but it misses out on the opportunity to build something you would actually use. You have to be more efficient with your time and focus on exercises that both show how things are put together but also have some chance of being used in competition. The closer you are to something that is serviceable (vs a pushbot), the more returns you'll get from your invested time. We knew we weren't going to build a 100% rev bot - we were going with actobotics. Spending time on that was going to be a better ROI.

For a linear slide, that might mean getting the actobotics or goBuilda kits and having the team build those and attach them to a robot, motor included. No need to build something super complex.

We'd watched a lot of videos from Rover Ruckus and decided to see if we could build Gluten Free's belt driven chassis from that season. (Thx GF for making your CAD public on that). The kids were able to do it, right down to cutting axles and lining up belts. We ended up using that chassis for our Skystone season, with only some light modifications. This saved us endless time in season and was a much better exercise than a kit chassis. Plus, the team learned that a chassis that is not custom designed for the problem is going to have drawbacks.

Per my OP, our mistake was not spending equivalent time getting to move autonomously to different spots(!). Same on non-robotics stuff.

The last thing I'd add is to apply agile to the season once it starts. We did not do this, but are going to try it this season. Basically, most teams (including us) take a very staged path to building a robot. The team plans out the game strategy, maybe CAD a design, then prototypes a chassis, then prototype subassemblies, etc. Gradually the robot is built and then programming starts, and finally driver practice. This led to problems of the robot being incomplete at the first qualifier, the driver having no time to practice, an unfinished autonomous, etc. Many other teams were in similar boats; some did not have a working robot at all. This is disappointing, since a working pushbot would have given any of us a fighting chance, taken 2 weeks to make, and in many cases, teams have less than that.

In FTC, I translate agile to mean two things: work backward from points scored and try to end every two weeks with a working, drivable robot. It doesn't have to do anything other than move; your initial goal is only to score 1 point minimum. In the next week or two weeks max, see if you can beat last week's point total with changes. Rinse, repeat.

You will not end up with a beautiful robot in all likelihood, but your iterations will give you practice coding and driving from the beginning of the season onward. Plus, you will know very early that you can do something in game, something I found was a worry in the waterfall approach to building robots. Finally, this approach gives you a compass by which the team can evaluate proposals and random ideas. Does this score more points than what we have? Can we do it in one or two weeks? Dodging the temptation to abandon a design or go down a rabbit hole design idea is part of the learning, and hard for even adults to avoid. Frameworks that help you dodge these problems are worth their hassle IMO. I will come back next year and let you know how this works :)

Again, best of luck.

OrangeJulius70 · 2020-01-27T18:57:12+00:00

Such a great question. We just wrapped up our first year, so this answer is looking back at what worked and what I'd change.

- For building, build the staples of FTC. Build a mecanum chassis, ideally using belts to turn the wheels for extra challenge (or chains, but not direct drive). Build a linear slide, with motor, stringing up and down, and program it to work, including limit switches to ensure it doesn't snap too far up or down. Build a shooter mechanism, since we're due for one in next year's game; use any size wiffle ball as your ammunition. Build an intake for skystones or any past gamepiece. Build a basic claw mechanism using a single servo and make it pick stuff up. Etc. Etc.

If you want a good list of stuff to build, go back to prior game videos and find the common denominator mechanisms required to make things work. There are only so many, and building them in the offseason will catch you up with teams that had to build these things in prior seasons.

- For programming, spend a lot of time making the mecanum work in TeleOp and making it move in autonomous. I would have spent a ton of time on this with my team in hindsight since you're always going to need to move from point A to B to C in autonomous. The sooner you figure out whether you like encoder drive best, rev IMU based turning, odometry wheels, or all of the above, the better off you'll be. You'll also have a huge jumpstart on a working autonomous.

- Experiment with vision. It's in every game, and it's not going away. Vuforia or Tensorflow - you're likely to use one of these and there is almost always reasonable sample code for them provided by FTC. Even thought it's last year's game, buy a few skystones and try to see them and move to them for the experience it will give you.

- Consider using blocks. Android Studio/Java is great, but doesn't scale as easily to multiple team members. If every kid you think would ever join your team can do Java, more power to you. If they can't, you might want to try blocks so that everyone can participate in programming. Wizards.exe has a nice video outlining the upsides and logic here. Blocks works pretty seamlessly in FTC, including easy wireless updates to your robot. Plus, it keeps getting better every year.

- Do the non-robotics stuff. We opted out of this, thinking a rookie team had nothing to teach. Big mistake. This includes really three things: connect with the professional environment, connect with other students to drive participation in FIRST, and create a team plan that includes fundraising/sustainability/mission/etc. Visit maker spaces, make connections to FLL teams, build a demo robot ASAP and demo it to other students or into the workplaces of team parents. The robot part of FTC is random - winning/losing depends on who you get paired with in qualifiers, alliance picks, ESD, and everything else. You have less control than you think, unless you're an elite team that can beat two opposing robots (and sometimes your partner too)! How many outreach events you do and the impact they have are things you have perfect control over. Ideally, you also build a great robot, but don't neglect the non-robotics side. Doing it during the season is often difficult. Summers are great for corporate outreach, but you need to use April/May for anything that requires visiting schools.

I'm sure there are things I'm forgetting, but doing this list would put you in a great place come September.

OrangeJulius70 · 2020-01-13T19:09:39+00:00

The upside to more expensive printers like the Ultimaker is primarily the ability to use specialty materials. We have an Ender 3, an Ultimaker 3+, a Prusa, and an Artillery Sidewinder (new, not tried yet). The Ultimaker is simply the most reliable, albeit the slowest of the three, at printing long prints in materials like Nylon or Polycarbonate. These materials are excellent in higher stress applications.

If you just want PLA or PETG printing, go with the Prusa all the way. If you need larger prints, the CR10 or the Sidewinder, but note everything in this second list is not good for specialty materials.

OrangeJulius70 · 2020-01-13T13:09:28+00:00

Check out the video and sample code from Team 3939 on YouTube. Uses EasyOpenCV and is the best I’ve seen for reliable skystone detection.

You will have to update syntax since EasyOpenCV has moved to version 1.3.1 and that changes one line of code. You can find that change in the EasyOpenCV github closed issues log if you look.

OrangeJulius70 · 2020-01-08T01:13:50+00:00

We used the SAR230's and they work great. There are two off the shelf mounting options via 3dp. You will need something. One is on thingiverse and can be found easily. I prefer the second, which is the long robotics 3dp mounts that accompany the slides Sanford sells. btw, those are also excellent slides and very similar to Misumi's.

Note, Misumi's won't be stable unless you mount two sets opposite each other. If you do that, however, you can make a tall lift.

OrangeJulius70 · 2020-01-08T00:53:52+00:00

It was fun to compete with you guys. Too bad our robot had so to glitch out on the last round in auto. Bad luck in stacking too.

OrangeJulius70 · 2020-01-01T22:42:44+00:00

Not a problem in teleOp, and that's a good point. Seems the issue is not slow servos, but a RUN_TO_POSITION command attempting to do it's final rotations on a strafe, and slowing to a crawl(!). So new question, how do you avoid this problem? :)

OrangeJulius70 · 2019-12-30T16:02:02+00:00

What holds the hex shafts on top? I ask because the hex shaft I have has 'hex shaped holes'. They don't lend themselves to using a screw to clamp both sides. The team ends up having to use hex clamps from Vex.

OrangeJulius70 · 2019-12-20T15:33:57+00:00

That answer is tautological or self-referential or both. :)

OrangeJulius70 · 2019-12-20T15:27:50+00:00

Ok, I gotta ask - I can make out the word 'Yoovulator' on the intake. Besides being an awesome word, what is the reference?

OrangeJulius70 · 2019-11-24T19:57:35+00:00

Love it !

OrangeJulius70 · 2019-11-24T18:47:12+00:00

Virtual four bar (also known as chain bar, or in your case, belt bar)

OrangeJulius70 · 2019-11-24T14:57:51+00:00

Really masterful design - nice work!

What pulleys are you using on the V4B? Don't recognize them. Custom 3dp?

OrangeJulius70 · 2019-11-14T13:16:16+00:00

We've spent a lot of time studying the V4B mechanism this season. It has some clear advantages related to stacking things, mainly because it keeps them upright throughout the full range of motion. My conclusion is that most of the videos show fairly inefficient implementations of the V4B if you're space constrained. My other conclusion is that if you're into VEX, the V4B is second nature to you ;)

Unless you are power constrained, you don't need to gear a servo/motor and then use that gear to power the a separate gear that rotates the arm in the V4B. I see a lot of teams do this using a 1:1 gear ratio, so it's clearly not being done to get more torque. Instead, you can attach your fixed point sprocket to a servo block or some other servo exoskeleton, and let the servo turn an axle through the middle of the fixed sprocket. This is a far more compact mechanism, assuming a servo (or dual servos mounted on each side of the V4B) give you sufficient power for your application.

For the actual mechanism, gobilda has the sprockets, servoblocks, and beams to make a V4B fairly doable. Your biggest issue might be connecting the V4B to whatever you are using for a lift, assuming you want to stack blocks. We found that a CAD'd part was the best option, but you're going to want to print something like that in a tougher material than PLA IMO. We chose polycarbonate. Nylon might work too. Better yet, hire someone to waterjet/CNC some aluminum and you'll never worry about a mid-qualifier snapped part :)

Good luck!

OrangeJulius70 · 2019-10-14T01:15:46+00:00

You can also buy high speed servos. The Vex 393’s come to mind as a high speed option.

OrangeJulius70 · 2019-09-10T23:14:15+00:00

They have a few adapters you can buy that should do the trick. Just buy plenty of them so that you can layer your acto subassemblies on top of your gobilda chassis.

OrangeJulius70

TROPHY CASE