Vector 8177 Build Thread | Open Alliance 2024

Vector is glad to be joining the Open Alliance again for the 2024 Season!

Team History/Introduction

Vector 8177 is based out of Tomball, Texas. We are one of three school teams within the district, along with 7691 the TSA All Stars and 7312 T3. This will be our team’s fifth year as a team and our third year as an Open Alliance team. Not only has our team grown tremendously over the past year, the Open Alliance has grown tremendously over the past year as well, and we hope to help it continue to expand in order to help more FRC teams around the world. Looking back on our last season, we can confidently say that the openalliance was monumental in the aid it gave to the FRC community. Thanks to teams sharing prototype data, strategy advice, cad models and code libraries to reference, and feedback on our own work, we were able to progress all the way to division playoffs at the World Championships.

This year, we hope that our OA posts during the build and competition season will help out other teams and help them grow. Whether it’s ideas about robot designs and iterations, the organization of different subteams, or our workflow, we hope that other people are able to find valuable insight from our experiences.

We realize that our format last year wasn’t amazing at encouraging conversation and interaction, so this year the plan is to format our posts more closely to how Spectrum recommends. (If you haven’t already, go check out their “How to write a build blog” post).

Team Links

GitHub

Onshape

Website

Youtube

Instagram

Merry Christmas and Happy New Year! Oh Yeah!

42 Likes

“PreCadding” a Robot

I thought I’d take a minute to talk about Vector’s new and improved CAD organization that takes place before the season even starts, as I think any team could apply some of these concepts.

File Organization

I try to keep my file organization very clean and very searchable. This means every mechanism gets its own document, all named according to a standard. This standard varies team to team, but I personally like the “TEAM#-MECH#” format. I believe I first saw it in 1678’s bots, but I’m not positive.

I’m not big on individual part names, as long as the mechanism assembly gets named according to the standard.

Personalized Parts

Everyone knows aesthetics are the most important part of any FRC bot. (I’m joking. Kind of.) So why would you leave out your swerve module’s coloring?

Having standardized components readily available (and publicly available of course) has multiple benefits.

  • Any bolt or spacer we will ever need I can easily get from just a few documents that are easily searchable(using a standardized naming system of course)
  • You can make the models you use as simple as you’d like, lowering your documents load time significantly.(100 threaded nuts and knurled bolts will add up, trust me)
  • Actually editable properties, unlike pulling from MKCAD. I’ll make my locknuts whatever color I want, thank you very much.
  • Configurable documents are much more intuitive than standard content. I know standard content has all of the same fasteners and finishes, but in my experience it’s more confusing for rookies to use than something like this.

Finally, I want to thank @AndrewCard because I took some of this stuff from him. (ie the simplified swerve)

Small post, but I thought it wouldn’t hurt to put it out there. Merry Christmas and happy holidays! Oh Yeah!

19 Likes

Rookie Cube Bot

This fall, we had our mechanical and electrical rookies build and wire up a simple cube only bot. It was a good project both for me to understand a bit of our limitations for the build season and for the rookies to get some assembly practice.

Onshape here.

A Few Observations:

Gear Pivot
I would’ve used chain pivot instead, but I wanted to keep it really compact and completely over the swerve modules. I’m not sure why, it was an arbitrary requirement I set that ended up negatively hurting the design. Not by much in this instance, but it’s important to recognize mistakes like that to hopefully prevent them from happening again.

Power Transfer Hex
The hex shaft transferring torque from the MP side to the unpowered side twists every time it raises. This is partially due to how long it is and partially due to the nature of the intake. The only standoffs holding the two sides together are the two hex shafts inside of the rollers. I’ll probably do a little bit more tweaking and testing to get a more quantifiable effect.

Cat’s Tongue Tape
This was Vector’s first time using a dead axle roller, so we wanted a grip solution. These two rollers used about 5 feet of tape each, so about 10$ a roller. Not great, but not horrible. They are very grippy though, no complaints there.

Dead Axle Roller Hubs
Due to a skill issue, I printed these hubs with supports inside of the nut pocket. This meant that once we cleared out the support material, a small amount of the nut retention was also scraped away. Or maybe a little bit was left in the nut pocket. Either way, it meant that 2 out of 4 nuts came loose while the bolts were being tightened.

It is worth noting, this is the V1 design. The V3 has much better nut retention.

V3 pictured below

@AndrewCard 's configurable roller also has options for epoxy/super glue and heat set insert, so if the nut stripping out is a concern there’s other options.

Lessons Learned:

I will preface this by saying that a large portion of our rookies last year were very bright seniors in technical classes, so we had an abnormally skilled rookie group. This year’s rookies are “true” rookies with varying experience and knowledge, most on the lower end as expected. This year is also the first year without the majority of the “original” group of precovid/covid students, and knowledge transfer is still something we’re figuring out.

Assembly is Rough
By no means an insult to our rookie group, I was not clear enough towards the rookies in how they should assemble this bot. I pointed them towards a veteran for help, gave them the CAD, and said “good luck have fun.” This was a mistake on my part, and it slowed down assembly a lot.

Wiring is Rough
With the graduation of our seniors, we lost most of our members that are experienced in wiring. We have a new electrical lead who stepped up and a group of rookies who are interested, but it means that wiring will take longer than expected. Not because the actual wiring is slow, but getting clean(ish) wiring will take a bit longer than last year.

Designing for Your Team, Not for You

This boils down into two main categories.

  • As the designer, assuming a minor detail(such as bolts vs rivets, precise dimensions, spacing, etc) is obvious, when it really isn’t
  • Designing around your team’s assembly abilities

The cube bot uses 3 different sizes of 3dp spacers, all within .25” of each other, in .125” increments. During assembly everything was off by .125” for some strange reason. Wonder what happened there.

Having a simple/cheapish project like this cube bot was very helpful in figuring out what Vector’s assembly abilities will be in the upcoming season. It created a metric for me as a designer to set my expectations around. This “metric” will be different for every team, but it’s an important one to have. One team might settle on “Ok so we can’t build a custom swerve with no instructions, even if we have the design.” Another team might settle on “Ok so we need the everybot in step by step pdf instructions.”

Happy New Years! Oh Yeah!

Many edits because I’m still figuring out how to format posts. Bear with me.

14 Likes

Vector’s Kickoff Recap

Whoo boy. This game’s a doozy. Where to even start? Vector met today along with the other two FRC teams in our district, T3 and TSA All Stars for a combined kickoff. We spent about three hours combing through the manual and brainstorming before all going home, and I’m pretty happy with the day overall.

Initial Game Impressions

While every individual aspect may not be difficult, making a competent robot that can score in every possible way seems very difficult. Vector will do a strategy deep dive with the full team in the next few days to determine optimal scoring strategies. This game is a mix between 2013 shooters and 2017 intakes, pretty interesting.

Priority List

After thoroughly going through the rulebook, Vector compiled a list of Must-do, Should-do, and Could-do items to prepare for archetype brainstorming. This list is our first time doing a proper priority list, but already it’s proved very useful.

Strategy

Before even thinking about mechanisms or robot design styles, a few teams broke off and specifically discussed alliance strategy for optimal points. This is assuming ideal circumstances where each cycle takes the same amount of time and does not cover Auto or Endgame.

This doesn’t even touch on the endgame, which is a whole different ball park with the trap. I’ll have to see how difficult that is once Vector builds their own field elements.

I’ll be doing a deep dive on scoring combos with Vector sometime within the next few days, but there’s plenty of tools available for teams to do their own, such as this score calculator from @DAflamingFOX,

This strat spreadsheet from the Washed Cadathon members(@howlongismyname , @Nick.kremer , and @AndrewCard ) adapted to Crescendo(unfilled) here, and this strat spreadsheet from @Richstar123 . I’m sure there’s many more, but these are three that I’ve seen that are very well done.

General Brainstorming
A link to the most legible whiteboard brainstorming can be found here.

I’ll try to summarize as best as I can

Summary
  • Must/Should/Could list
    • shown above
  • Ways to score
  • Safe Zones
    • Stage Zone, Source Area
  • Point values for various endgame situations
  • Expansion and frame perimeter rules
    • 120” frame circumference with a height of 48” starting zone
    • Maximum of 12” expansion in multiple directions, no height expansion
  • Misc sketches of ideas
  • Cycle calculations
    • Shown above

Notable Mechanism Concepts

We had a few out of the box concepts that I think are fun to look at and take inspiration from, viable or not

  • Hungry Hungry Hippos(pronounced “HHH”)
    • 12” extension, arm or linear actuator
    • Auto only
    • Grab Center Notes first

  • “The Foot” ©
    • Kick the Note
    • We realized the note slides really well on carpet, so the natural inclination was to kick it
    • Having a fast, no intake required Note mover could be helpful for shuffling notes to teammates quickly

KrayonCAD

Talking about whiteboard designs leads perfectly into the next step in the brainstorming process, cad archetype brainstorming!

But first, a shill. KrayonCAD is a system that allows robot concepts to be created in Onshape within minutes thanks to fully customizable subsystems. More information can be found here.

Anyways, back to Vector. All of the KrayonCAD brainstorming so far can be found here. I don’t need to go through all of them, but I’ll point out a few promising archetypes.

The Virtual Four-Bar linkage of Krayon 6 looks like it could be a very compact, easy way of intaking notes off the ground and transferring them into a shooter area.

The elevator found in Krayon 6 and Krayon 1 serves dual function as a climber and as an Amp mechanism. I always love a good mechanism mashup.

Also from Krayon 1, an under the bumper intake is a very compact intake strategy that completely eliminates the possibility for intake damage during collisions. It does, however, limit the width of your intake.

A pivoting shooter like the one found in Krayon 8 could allow shooting directly into the Amp as well as shooting up into the Speaker.

Overall Takeaways from Day 1(That I haven’t mentioned already)

  • Drive coaching is going to be very complicated. There’s a lot of moving elements to consider
  • 3 piece auto(preload + 2 mid field pieces) is 100% viable
  • A short robot is a winning robot
  • Cranberry Alarm has some really good prototypes already, definitely worth paying a lot of attention to in the next few days
  • Notes are very easy to work with. They squish, they flex, they twist. It seems like any wheel will grab them in any orientation
  • A lot of teams will attempt the trap, it remains to be seen how many teams will succeed
  • Wow this is really similar to 2017
  • Wow this is really similar to 2013

Future Posts

  • Various shooter prototypes
  • Various intake prototypes
  • Lots of game piece testing
  • Lots of field interaction testing
  • Maybe a strategy post?
  • Design and game analysis posts

I know our cone drop tests were very popular last year, hopefully we can produce similarly useful data early on this year as well. Oh Yeah!

29 Likes

Appreciate the credit, would it be beneficial for others if I posted the excel file?

Best of luck Vector!

4 Likes

Would love to have it!

2 Likes

Here you go!

1 Like

Final(?) Archetype

We have officially decided on our archetype!

Functionalities

  • Pivoting intake with a dual function as a shooter
    • Simplicity is king, especially when the trap hits our dof limit
  • Multiple options for Amp scoring
    • Shooter or Trap arm
  • Continuous elevator for climb and Trap
    • Continuous elevator = continuous torque
    • Needed for hooks on the carriage
  • Support bars to react against the Trap
    • Hopefully provide more stability

Design Constraints and Requirements

  • Low bot
    • Reduce COG and prevent ever tipping
    • We feel that driving under the stage will be key to avoid congestion
  • Robust Design
    • Our drivers have a history of driving as if they were controlling bulldozers, so we have to design accordingly
  • Trap
    • We feel that being able to consistently score in the Trap will be necessary at high levels of play
  • Separate Trap and Speaker Mechanism
    • Worst case scenario, we just don’t put the Trap mechanism on for our week one competition
    • Programmers will be given the competition chassis with the shooter, mechanical will be given a chassis with the climb and Trap mechanism. This way, there’s zero downtime for programming while also allowing for iteration of the Trap mechanism
  • Single Speaker and Intake Mechanism
    • No handoffs = easy to program
    • Very compact

Possible Postions

Inspirations

Week 1 Update tomorrow. Oh Yeah!

27 Likes

Week 1 Recap: Prototyping

We went into the prototyping season with the goal of prototyping multiple different types of shooters and multiple types of intakes. Unfortunately, this hasn’t happened and probably won’t happen. Prototyping is something we’re getting better at, but we won’t be at 1678 level for a long time.

We have prototyped one type of intake and shooter each though, and we’re very happy with the results from those. Our intake used Hype Blocks, and our shooter was just done on some scrap plywood from the old 2023 field. If it works it works. Along with this, we also tested some material interaction. All of the testing videos can be found HERE.

Material Testing

We tested five materials. Vinyl(car wrap), Polycarbonate, Plywood, Aluminum, and HDPE. In order from best to worst:

  1. HDPE
  2. Vinyl
  3. Aluminum
  4. Polycarbonate
  5. Plywood

Surprisingly, Polycarb was awful. I’m pretty sure if we sanded the plywood it would have performed better than the polycarb. As for what this means, it kind of depends. While we have HDPE, we only have thick(1”) slabs of varying straightness. Anywhere from no warp(currently on the cnc bed as a spoilboard) to 5” of warp along a 36” edge. Right now our two main considerations are buying thin slices of HDPE or using vinyl on polycarbonate. As HDPE is lighter and we don’t really care about strength as a Note tunnel backing, we’ll probably go with HDPE.

Intake Prototype Testing

  • With our two testing of a dual roller intake, wheels from 2.25” all the way up to 4” in various configurations successfully sucked in the Notes
  • Various angles from 0 degrees(parallel with the ground) all the way up to 90 degrees also sucked in the Notes
  • Various durometers and stiffness all the way from 40a flex wheels to 90a stealth wheels sucked in the Notes
  • Various compressions from 0” to 1.5” of compression sucked in the Notes
    • Note that at 1.5” of compression the entire intake prototype started flexing. It’d probably be smart to not run that in competition

So What’s the Conclusion?

While we don’t have any hard statistics to back this up, it seems that if you touch the note at all with a wheel, you will be able to intake it. Intaking really doesn’t need more than .5” of compression, if even that much. This is ideal for Vector, as the archetype we’ve decided on relies on an intake that also functions as a shooter.

Shooter Prototype Testing

Our shooter had limited testing, as it was a proof of concept. Vector is going to a week 1 event, so I only expect us to be shooting from the fender and maybe the launchpad on the Stage. I’m not incredibly concerned with fiddling with the dials of a horizontal roller shooter right now.

  • .25”-.5” is ideal compression for a top and bottom roller shooter
  • Feeding matters a lot
    • Inconsistent feeding can wildly throw off shots
  • “Lobbing it” is fine for close range shots
    • I’m not sure how well no spin will work for long range shots, but Vector will never be doing long range shots so that’s not something we will be trying to solve

Downsides of horizontal roller shooters

  • Less contact time
    • We might mitigate this by having 2 shooter rollers
  • Axles must be perfectly parallel to shoot well
    • Some deviation is allowable, but it makes shots wobble

So What’s the Conclusion?

Are horizontal rollers perfect for shooting? No. Will it matter for fender and launchpad shots? Probably not. It seems to be good enough for Vector’s goals, and that’s what matters. If you would like more in depth horizontal roller shooter testing, go check out this post from 4481. They do amazing work over there.

Field Building

We built the amp earlier this week, but we’ve now nearly completed the speaker and have prepared all of the wood for the stage, so hopefully we’ll have more field interaction videos soon.

Once we debug our swerve chassis, there will hopefully be a programming update detailing the issues we had, and I’ll post some periodic updates if anything major happens before the next weekly post. Oh Yeah!

13 Likes

Love to see the progression!

That’s going to be a challenging archetype you all drawn up in KrayonCAD. I can’t wait to see you guys build this thing and get it up and running :smiley:

4 Likes

Electrical Update

Last year, our electrical team was nearly all seniors. I and another member have stepped into electrical co-lead roles without much prior training, so over the last couple of weeks I have been working hard to learn as much as I can about frc electronics. Over the offseason and early season, we’ve been preparing the electrical rookies to wire up the competition robot.

Skills that we have worked on since kickoff:

  • Understanding all the basic electrical components needed and how to wire them.

    • I made a diagram to show them this (not the fanciest diagram but if it works it works).
  • Utilizing a testing board that was made over the offseason, we worked on using the REV tuner client to test motors

    • A simple program was written to run the testing board (which can be found in our github)
  • We also used the testing board to ensure all our radios are flashed and functioning

  • Using the board, ethernet cables were tested, motors were tested, and radios were configured

|219.24324324324326x292.0436817472699

  • Worked on rewiring the cube bot (our main off season project) to practice wire management

  • We removed all the default CAN wire connectors and switched them to lever nut connections

    • The original CAN connectors are annoying to use and not as secure
  • We are still learning and practicing on making our wiring more clean and organized so suggestions are appreciated :slight_smile:

  • Labels were put on components, which we realized is unideal. In the future wires will be labeled instead

  • As programming began debugging swerve code, wiring errors were discovered leading to components being rewired

  • We are currently using cube bot to test the v1 shooter, which electrical wired up

|211.07964207607068x280.00000000561084

Electrical plans for comp bot:

Vision

Last year, we used two limelights running photon vision for april tag tracking. After having a few cameras break, we realized that we wanted to switch away from being dependent on 400$ cameras. This year, we are going to be running photon vision on Orange pis.

We are going to try to use the 5V/2A port on the voltage regulator module to power the orange pi; however, we are not sure if that would be sufficient amperage.

Sensors

I like the idea of using an infrared sensor to determine when the game piece is fully inside of the robot(Inspired by this video.) I think that using an infrared photoelectric sensor or a beam break would work fine.

We are going to be using the rev magnetic limit switches since they are not as likely to break compared to the mechanical limit switches.

We will be using the through bore encoders for pivots and potentially other reasons.

Things to look forward to:

  • Last year we ran into problems with various electrical problems at competitions that were detrimental to our performance so I am going to be making a debugging binder/document to make sure that if something goes wrong at a competition we can use this as a reference to debug it.
  • We are going to use this electrical configuration spreadsheet for making sure we know where/how everything is connected.

Oh yeah! :slight_smile:

4 Likes

Week 2 Update

This will be a fairly short update, as I need to get back to cadding the robot. We lost part of our week two to the cold snap, so there’s not too much to write about.

Mechanical

Most of this week was spent building field elements, so there’s not much mechanical work to document outside of that.

  • Finished building all field elements
  • Assembled our v1 shooter(with some questionable tensioning)

|624x280.95957282716626

  • Started working on new prototypes

We haven’t been able to test the shooter, but I hope to test that in the coming days.

Design

Around the middle of week two, I had a realization. I had let scope creep get the best of me, and the archetype that we had picked was much too ambitious to build and get functioning by our week one event. I sat down for a few days and seriously thought about the pros and cons of continuing with the arche, and decided it wasn’t worth it. There will be a full post discussing the change(or maybe it’s already out, I haven’t decided yet as of writing this).

#$ Plans for Week 3

  • Test V1 shooter
  • Finish cad :crossed_fingers:
  • Test note durability and degrading
  • Test note centering
  • Test new amp mechanism
  • (Fully) fix swerve

I’m writing this on Wednesday night of week three, and there’s so far much more progress that will be posted in the week 3 update. I would post about it now, but I honestly don’t have time. Here’s a sneak peek.

|267x594.4712918660287

Oh yeah!

4 Likes

It Was Not The Final Archetype.

So it turns out I accidentally told a little fib. Oops.

What Were We Planning?

You can read the full design post HERE, but in case you don’t want to do that, here’s a quick summary.

  • Combined intake and shooter
    • Dual purpose as amp mechanism
  • Elevator for trap scoring
    • “Trap arm” on top to score the note

Why pivot?

The more I looked at the design, the more the flaws became apparent. When conceptualizing it, I had made too many “just” statements.

  • “The robot just has to consistently shoot up into the amp"
  • “We just have to assemble the internally rigged belt elevator before week one competition”

It was a lot of design choices driven by what I know how to design(elevators and intakes, not shooters) and fear of a faulty mechanism. If the trap mechanism didn’t work before week 1, we just wouldn’t attach it to the final robot. This design choice actually contributed to the growing pile of issues with the archetype instead of helping it. Let’s go over those.

Issues

  • Shooter was blocked by the elevator if we shot from more than 4 feet away from the subwoofer
    • Would have to spin 180 during auto to shoot and intake
  • OTB intake is more likely to get damaged than UTB intake
    • Would almost guarantee losing the game of chicken over the middle notes during auto
  • Elevators are hard
    • This isn’t really an elevator game, yet I was trying to stick a pretty complicated(albeit compact) elevator onto the robot. That goes directly against Vector’s design principles
  • Full width shooters aren’t ideal
    • As demonstrated by multiple team’s prototyping, horizontally compressing the note provides the most consistency. With a full width intake/shooter, this is quite literally impossible.
  • Middle shooter wheels aren’t ideal
    • Again, with a full width intake/shooter it is impossible to not have wheels in the middle of the shooter.

Scope Creep

This is probably the biggest issue and the main driving factor. I would be fine with an unideal shooter, we could always just be a closer shooting bot. I would be fine with a vulnerable OTB intake, we could always just not run mid field note autos. The nail in the coffin however, was how complicated the design was getting. This was the final state of the cad before the pivot.

Old elevator CAD found HERE and Intake CAD found HERE

There’s a lot of parts there without even having the trap arm on top of the elevator. The further the bot got along, the more complicated it began. Somehow I had shifted from having a vertical elevator with plenty of room for supports to a diagonal elevator with barely any room for supports. With a week one competition, I had to admit to myself that whether we could or couldn’t have assembled it in time for week 1, it wouldn’t have enough code time or driver practice to be as competitive as I would like.

New archetype

So, let’s address the issues.

Problem. Elevator blocks shooter

Solution. Remove the elevator

Problem. OTB intake is too likely to get damaged

Solution. Switch to UTB intake

Problem. Full width shooter + wheels in the center of the shooter unideal

Solution. New shooter design

Problem. Unwieldy intake pivot, too much weight at the end of the arm

Solution. New pivot is better balanced

Problem. Trap mechanism has too many “just” and “as long as” statements

Solution. New trap function has 0 added on mechanical components. If it works it works, if it doesn’t work it’s a regular climb and amp mechanism

Problem. Scope creep

Solution. Removed the elevator, reduced DOFs

Problem. Sketchy amp scoring

Solution. Not a complete issue, but amp scoring could be more consistent if we’re not relying on shooting into the amp

New CAD Progression

KrayonCAD

I spent way less time on Krayon this go around(about an hour instead of a day) since I already had a feel for what I wanted to fix about the old arche.

We’ll have a 95 inspired UTB intake that centers into a pivoting shooter. Flipping the shooter up, we’ll have a neo550 actuated hood that will function as a redirect for our notes to push down into the trap and amp. We’ll be climbing on 111 2020-esque ratchet strap climbers since that’ll allow us to pull down to the bumpers while remaining extremely compact.

Master Sketch

I deep dove into the master sketch this time to try and prevent any issues from popping

up later on.

Nearly Finished Shooter

Chassis + UTB Intake

|623.9999999999999x441.0802631913034

While the space constraint is fixed, we’ll probably play around with roller spacing to see what works best. Seven dead axle polycarbonate rollers wrapped in either cat’s tongue grip tape or rubber sleeving, driven by two neo 550s.(I didn’t want to deal with reversal gears)

Full Assembly

I think it kind of looks like a tank, which is pretty dope

Inspirations

111 2024 - shooter

111 2020 - climber

95 2024 - undertaker

5987 2024 - self centering

4481 2024 - amp mechanism

Assuming we don’t pivot later in the season this is likely our final final for real this time archetype. As always, all of the cad files are public. If they’re not linked somewhere convenient, feel free to ask here anytime or ping me in the OA discord and I can link the individual docs. Oh Yeah!

|624x470.97513521997297

35 Likes

if i had a nickel for every time the depression/mania curve has been posted in an open alliance thread i would have two nickels which isn’t much but it’s weird that it happened twice no this isn’t shameless self-advertisement

5 Likes

This looks like a great redesign, I’m excited to see how it turns out.

10 Likes

It was exciting this year chopping out degrees of freedom and still finding ways to work with what’s left to accomplish the tasks with minimal “extra”. There were a few key eureka moments in there with solutions just emerging, which I thought was neat.

Agree. Redesigns gang really help you distill and wind up with a competitive bot. Excited to see the final product.

2 Likes

Would recommend not going with a VRM for the OrangePi5. The current rating is half what is recommended for the pi so it will potentially not function properly, something like Pololu - 5V, 3.4A Step-Down Voltage Regulator D30V30F5 is a better fit.

3 Likes

Keep in mind you can also use external battery packs, as long as they meet certain requirements: R602

This might be easier and more robust. We are pursuing this strategy this season for our CV.

1 Like

Any time there is a separate battery I would be nervous that is a potential point that could be forgotten, and you end up in a match where the vision processing suddenly shuts down because the main SLA was swapped out, but the second pack for the coprocessor was not charged or swapped.

1 Like

I know we are cutting it close with a VRM. I’m going to measure current consumption when we get the vision processing running. The 4A recommendation includes support for an M.2 storage module and USB peripherals attached. In this application it will boot from micro SD, no monitor attached, only one low power camera attached with USB, so should not exceed 2A. Depending on how close to 2A it runs we might need to switch to a 3A regulator to have a little breathing room.