Team 2980 2022 Open Source Thread

Back to being as Pollyanna as I can?

Let’s see how long this will last.

Today’s team agenda

The dump box that belongs on the wall of fails;

Cutting out letters for the blanket drive:

Wiring before my tirade/tantrum:

One of my favorites (“The encoders aren’t working”):

Wiring after some cleanup work was done:

Well…that didn’t last long. :-p

I am probably knit picking more than necessary, and they ignored my “suggestion” that they clean up the wiring and instead decided to focus on getting the swerve drive running. Especially hard is that it was mainly 2 kids working on it, and instead of teaching anyone else pretty much anything, they just struggled to do it on their own.

We decided to use the laser cutter to cut out the letters for decorating the blanket collection boxes. The kid who took that project on seemed to really enjoy working with the laser cutter. Hopefully that can become a new thing.

A couple more kids are over working on electronics…Maybe my words of encouragement worked…I said I would post a pic of their wiring at the end of today’s meeting, so they still have about ½ hour to get it clean enough to share.

Our current plan is to elevate the cargo (balls) to a box on the back of the robot, turn around, and dump them out into the hub. The intake necessitated moving the ball elevator back 2 inches. This necessitated shortening the box on the back by 2 inches, 15 - 13 inches deep and 21 inches wide.

I know how what I said got me what I got, but…

So…that will need to be redesigned.

At one point one of the kids suggested we just dump the balls one at a time…Thankfully they decided that was a bad idea on their own.

I was mean today.

The two kids who have been working furiously to get the robot driving, running wires every which way, felt really called out by my introduction to today’s meeting. I posted the agenda slide show showing all of the problems that I could see right off the bat in looking at their wiring and pointed out how important it is to run things in a logical manner.

I reminded them that we had competing goals. They wanted to get it running as quickly as possible, and I wanted them to do it right so that it would be reliable moving forward.

They didn’t listen to me, and at some point I said that I wouldn’t bring it up again. I am going to have to work really hard to do that.

At some point before saying that I had said what I needed about the wiring and wouldn’t bring it up again, a kid told me that they had made a longer wire “for me”. One of the encoder wires was way too short and stretched tight enough that when you plucked it it made the tone of the C on the treble clef. (that is a bit of an exaggeration.) I resisted telling them that they weren’t doing any of this “for me”.

Hard to make them see that.

I really hope I don’t end up saying something along the lines of “I told you so” when they end up having something not work and can’t figure out why.

So…I told them that I would post the pictures of their wiring here, and that I hoped you guys praised them for doing a good job instead of ridiculing them for doing a terrible job. (Knowing the FIRST community I’m sure if we get any feedback it will come in the form of pleasant constructive criticism……with maybe a little bit of armchair quarterbacking mixed in. :slight_smile:

So…I am hoping a lesson will be learned. A part of me knows? That they won’t learn anything if they leave the wiring a mess. The kids will just have an unreliable robot and not understand why. Last year when we were trying to film our robot for the virtual competition, for “some reason” half the motors would disappear and stop responding. This happened despite the battery having just been changed thus proving it wasn’t a low battery that was the issue.

I finally figured it out. There was a CAN wire stretched across where the battery plugs in that was getting ripped out every time they took out the battery.

More than a couple of the kids who are currently on the team were also on the team then. But for some reason they can’t see the relationship between messy wiring and their robot randomly not working .

Unfortunately I think the lesson they learned today was that I can be mean and demanding when I don’t get my way.

Ok…It is late.

Enough for now.



It is hard. I think when we look at it, we think everything we do or say, or don’t say will end up being the reason why a kid won’t want to do this anymore, or won’t be inspired. Hopefully they are more resilient than that.

The kids I called out today over wiring felt it. Not enough to fix it, but they felt it.

I’m struggling with the fact that they don’t seem to understand that the failure to pay attention to details will lead to problems down the road.


The RSL is on (along with I assume the rest of the bot), which likely puts you ahead of a lot of teams in terms of electronics/wiring. Even the small wins are wins.

It took us a couple really bad wiring years (namely 2016 where the PDP and rio were stacked vertically to fit with a rats nest of wiring) to really start putting in the effort to our wiring after identifying it as a big problem post-season. You can see a noticeable improvement in 2017 (nothing 1538 level but progress is progress) and its been a good while since we had any real electrical related issues on the field since 2016.

I’m not really sure how to go about convincing them (if you choose to keep trying) short of living that failure if they haven’t/won’t take the hint already. Might be a question better answered by someone with more experience…

Thank you for helping me to find perspective and a little bit of hope. They are making progress…it may be best for me to just shut up and let them work through it. I also need to recognize that their path is not my path…Just because I know from experience that certain things lead to better outcomes does not mean that they need to understand that right now.

So…My fear based on past experiences is that they will have gremlin issues from match to match that are really hard to diagnose. I remember one year where the robot would work, mostly…and then randomly in the middle of the match the robot would just disconnect and restart. Happened pretty much every match. At one point a CSA came over and one of the kids waved them off saying it was just a low battery and that they had it figured out. (That was before we had a battery beak.) It wasn’t a low battery and when I heard that a CSA had come over to them and they had turned away the help… Later they found they had a bunch of different problems. Everything from a loose connection on their main breaker to exposed coper shorting out things on the roborio. It was really demoralizing for the rest of the team and it was one of several competitions where we ended things off either in last place or close to it.

None of the current batch remember things like that in more than an existential way. I’m hoping this isn’t the year for bringing back memories like that.

I can understand the frustration on behalf of both parties; it may be hard for them to see not just what is good enough, but why what is good enough, is good enough. You may want to make the “why” a little clearer, and give them a way of testing it. When I was coaching a team, we had what we called the “chuck test” (named for a famously gruff former mentor); we always had problems selecting the wrong connectors for wire size, properly crimping them, making sure they were properly seated in the PDP slots, etc. So after the wires were “finished” one of the students (traditionally the most senior) would perform a “chuck test”, giving each wire a light but firm yank, to verify all connections where mechanically sound. If you’re worried about the connection quality, you may want to have them do something similar (maybe include a multi meter), or if you’re worried about troubleshooting, have them verify that they can trace every wire from one component to the next in less than X seconds. If you’re worried about something snagging a wire, maybe have them (gently) wave a PVC pipe in there and see if it catches on anything. Give them the standards, and allow them to evaluate their solutions. If it passes all the requirements that you have, would it matter if it looks exactly the way you want?

A few years back, we had a problem mounting our router to the bot. We had no space. The kids wanted to mount it under a catapult arm, but I said no. The student in charge wanted to know why, and I told him I was worried about the catapult causing issues, such as striking the router, or catching a cable, or causing shock or vibration that would make it reset. A couple days later he came back with a mount for the radio that he’d custom made; it not only enclosed the router in a protective plastic case, but also had integrated in shock mounts, strain relief for the wires, and cable retention features. Not only were we able to mount it due to his protective case, but the case design was refined and reused in following seasons, and features from it were used for mounting other components as well. I didn’t get my way, but we ended up with a better solution, and the students involved learned quite a bit, and gained a sense of efficacy.

1 Like

Today was a good day.

The first words you see is how you will spend 2022:

More blanket drive stuff:

The actual thing is the prototype?

Cleaning up wiring?

Laser cut letters:

A small printing roller:

More of the print roller: (This isn’t our design by the way. It is a design our photography teacher found and wanted us to try to make for her and our 2d art teacher. We may have to turn the upper roller part on the lathe out of stainless steel…Not really sure.

Is it wrong that I sound shocked when I say that today was a good day? Honestly we do this because we love it right, so if we didn’t love it, then we wouldn’t do it right?

Sure…some of them test our patience and make us angry, and for some that seems to be their ikigai. But really…we love that too.

Today was odd. I started off by telling them what I thought they should get done, and some of them did some of it, while others went off and sort of did their own things. The blanket donation boxes got worked on, which is nice, actually…really nice, and the photography teacher asked us to make little print rollers for them. Those got done also.

(Ok…just sat down for dinner while I write this and I think I have a new standard for the mix. Steak…rare, sliced into cubes. Asian pear, Brie cheese, and montreal steak seasoning wrapped in a crescent roll and baked for about 20 minutes at 375. Oh man…so good.)

The kids also started assembling the ball elevator, though that is going to stall until we get motors, gearboxes, churros and belts in. Oh…and hex shaft couples which I am starting to think we will have to make ourselves and the bearings which should be in pretty soon?

The kid who had been working on CADDing the dump bucket didn’t come in today, and no one took up the mantle of CADDing the frame. Looking at all the subsystems currently on the robot I am a bit concerned about weight, but I suppose we can add lightness later.

(Yup…the food is good. )

More work got done on wiring, though I think the kids who had originally done it are a little bit sore with me because they chose to practice soldering instead of actually working on the robot. Others were more than happy to jump in though and things got done anyway.

Ok…today is going to be short because I am running on fumes.

Oh! And because the team isn’t meeting on Fridays I get to go cut up some Bow tree wood tomorrow. Not sure what I am going to try to make out of it a few years from now, but hopefully something cool. Maybe I’ll try to incorporate it into a kayak. The world may never know.

Enough for now.


I really like this idea, and yes, I do understand their frustration. I think for them more from the standpoint of, “we want to see it work and we can fix it later”, than from not knowing what “good enough” is. They know. They have done much better jobs of running wires in the recent past. (We are also FTC team 7676 and this years robot was pretty well wired.)

That said, I think you are right. I should simply set out requirements and leave it at that. The fact that they had 3/4 of their encoder signal wires plugged in backwards and the PDB was clicking away like a sewing machine because they had reversed polarity running to a few spark maxes…

Wait…sorry…Today was a good day. I am sticking with that.


Thanks for the advice though, I will try to incorporate it in my practice.



A seed planted

Sitting on the couch after a long day. The wife is simultaneously watching Star Trek TNG and a video of a guy playing with a rescued racoon cub and fox puppy on her phone.

So a young woman who graduated from our high school what must be a bunch of years ago and went on to become an electrical engineer reached out to me about becoming a mentor with the team about 2 years ago. On a whim I ordered her a lab coat (our team’s signature uniform) with her name on it and had it delivered to her directly. Barely heard from her again over the next two years.

Today she came in. Unexpected, and totally welcome. She jumped in with our programmers and got to work. She clicked with them in such a wonderful way. She promised to come back next week, but given that she has a little one at home and is working really hard at a newish job I will take what I can get from her.

Swerve drive still doesn’t work, and a part of me is starting to get scared, but…It will be what it will be. I’m sure they will figure something out before too long. Worst case scenario we punt and rebuild the drive base…

Who am I kidding?

We also figured out that the ball elevator was 1.5 inches too tall. So…I set about resizing it while a couple of the kids worked on re-CADDing the dump bucket. I had a realization. The kid doing the re-CADDIng is relatively fluent in Solidworks, The team uses Autodesk. Of course they struggled.

I went over how to do it and showed them how to make it.

We are running out of polycarb.

I think we are also going to have to swiss cheese a lot of this bot. I should probably step up the CADD models and start calculating weights…

This morning I noticed that a lot of the team is waiting for someone to hand them something to do. It is hard because the learning curve is so steep, and they all have so little experience. The overwhelming majority can cut out a part fairly accurately if you give them a print out from the CADD model, but not many of them have the overall vision of how things fit together. Even going through and showing them the block CADD and then the actual CADDed parts, there is little understanding of how things fit together. This is odd because the robot being worked on is a student design.

I think a lot of them are struggling to fit it all together in their heads.

I’ll keep working at it.

I’ll include pictures with tomorrow’s post.

Alright…Enough for now.



Do you have any tips on getting these types of students more involved? We have a few of these types of students on our team, and I would love to find some way to get them more involved. It just always feels like with our construction method for this year (no big machinery, hand tools only, no mechanical mentor presence), its hard to get our new students on a path to actually getting their hands in the robot. Yes, we sometimes do, but other times it just feels like our three veteran students are hard at work while everyone else sits back and watches.

Here is part of why I am struggling this year.

A few years ago we had a bunch of amazing kids graduate all at once. This happened 2 years in a row. The problem being that they were almost too good. The kids below them got used to having people “hand them things to do.”

The hard part is, the younger kids didn’t ever really grow to generate their own things to do.

I sort of ended up falling into that role to some extent.

Some things that I have had limited success doing:

  1. Empower your doers. The veteran kids on the team. Start calling them mentors or junior mentors or team leaders…Something like that. Pull them aside and let them know they aren’t allowed to “do” anything anymore. They have to direct a group of other kids. Tell them that they have to do this because otherwise at competition they will be all by themselves surrounded by a team of kids who have no idea what is going on.

  2. Have a buddy system. Assign each of your doers a buddy or two. Make your doers explain each step of the way, what they are doing, and why they are doing it. Have them exchange ideas through engineering notebooks.

I call them thinkers and tinkers btw. (not out loud anymore) The thinkers are the generators. They are constantly generating work, coming up with projects, designing parts, finding solutions. The tinkers are the ones doing the work that has been generated, making the parts, and implementing the solutions. At one point we as a team joked that only the thinkers were allowed to think. The tinkers…No thinking, just doing.

I have ended up doing a lot of the CADD work this year. I have 4 kids who are really good at CADD, 1, has been working really hard on programming though, so they don’t really count. The other three have really let me down a lot, not being willing to do the work involved in actually designing things, or even figuring out how and where those things can be. I’ve gotten to the point where now I am simply not going to CADD anything, unless a kid is sitting next to me working through the problems and telling me what they think I should do.

In the least that 1 kid is going to be a rock star some day.

So…Unfortunately I think it means convincing the kids who are doing the work that they need to bring other people along, even though it means going slower and getting less done.

I hope this helps.



FIRST UP…A plea for help.

Ok…So the team is scrambling to get swerve working. They are trying this and that with little success. We are using the SDS swerve MK2 modules. They have absolute encoders and are programming the robot in JAVA. The robot is lifted up on blocks. When they try to run the robot some of the wheels point in a steady direction, others will jitter around violently. There is a lot that could be wrong, so help would be greatly appreciated. I feel like if they can get off of this sandbar they will be OK, and I feel like they understand enough that this can still be a learning opportunity for them.

Here is what one of them sent out in an email yesterday when asking for help:

Alright, so far we’ve tried 3 different programs and here are the results of each of them. I didn’t include the programs themselves because they are currently on the laptop back at the robotics room, I can try to send out copies of the program when I get the chance tomorrow.

  1. We have a program that was created by Mr. Carman and it sort of works. This program doesn’t use the absolute encoders and therefore requires the wheels to be manually reset to the zero position before running the program. This program also doesn’t have any field orientation or swerve module angle optimisations. So what I mean by “it sort of works” is that it goes in the direction that you tell it and it rotates, but it starts in the opposite direction before going the way it is supposed to go.

  2. We have a program that Branson modified that was based on the wpi api swerveBot example. This program on paper is promising as it supposedly has the angle optimizations, field orientation, and uses the absolute encoder. I’m not sure what is wrong with this program, but when we run it all of the motors violently jiter back and forth, even without any joystick input.

  3. We made a program today using the teleop code from this video (excluding autonomous) . This program also looked promising as the team in the video seems to be using almost the same setup as our setup. We are using the mk2 swerve modules on our robot just like the people in the video. When run this program seems to work and turn the wheels in close to the right direction, but one of the four modules is jittering with joystick input. I’m not sure if it is related but we seem to receive an occasional CAN error from all of the turning motors except for the one that is jittering.

It sounds like Mr. Carman will be able to come take a look and see what there is to see tomorrow. Some things that we will try doing tomorrow are setting the drivetrain on the ground to see if maybe the PID controller is constantly over shooting the target location because of lack of resistance of the ground. Although the more I think about it, the more I think the jittering might be a misconfiguration in the PID controller. I’m not sure what the PID values in the first 2 programs are but in today’s program we had a P value of 0.5 and the other two values were 0. We will also look into using a different gyro for field orientation.

Let me know if you have any input.

CodeForSharing - Google Drive

Here is the code they made today…It still doesn’t work, but the jittering is gone. They stopped using the “fancy method” for getting the voltage the analog absolute encoders was supposed to be sending. They also decreased the P value from .5 to .25 which seems to have stopped the jittering.

Link to video of it running:

What I wrote over the last few days:

I don’t know if the kids know…The part they don’t understand.

If you have been following along, you know that I sort of lost my proverbial mind over the job the kids on my team did wiring the robot. It was a mess, which has largely been cleaned up…not to my standards, but enough that you can actually maybe think about seeing what is or isn’t wrong relatively clearly.

One of the encoder wires was stretched super tight, something that I pointed out to them during my trade, before I told them that I was done and wouldn’t mention wiring again. Something I actually have managed to not do.

So…I was walking past the robot minding my own business and a kid said, “We made that wire longer for you.” :frowning:

I hope I hid my disappointment, and said something like “cool, looks good!”, and went on my way.

It is now something like a week later. Swerve still doesn’t work.

So…last night I went to bed at 11…took too long to wind down, and woke up at 3…

I’ll finish this tomorrow, but you get the point…I’m starting to stress and it isn’t good.

The thing that I don’t think that kid understood is that we aren’t doing this for me, and it breaks my heart to see some of them flailing away at something and falling farther and farther behind, while others on the team don’t know enough to know how much trouble they are in, and how much this might suck if things don’t turn around pretty quickly.

One of the kids does Skills USA. They have been working on, and have made very little progress on, the same project for 2 years. They presented a non-functional part of said along with a write-up and poster and qualified to move on to states with it…They work a couple hours a week, and feel like they are putting in overtime if they come in and work on it during lunch.

That kid’s only experience with FIRST was last year when we were remote for the entirety of build season. Every meeting, they complain about how much time we spend in robotics.

I don’t think they get it.

The other day another kid came in after the meeting was over, really upset. They had CADDed a part and had planned on making the part by themself, start to finish while other kids on the team were sitting around doing nothing…(some were bored enough to start being a little bit destructive.) So I asked the kid who had CADDed the part to take some kids through and let them actually make the part so that they would A) have something to do, and B) learn something in the process.

The kid who CADDed the part wasn’t interested in that and went off sort of in a huff. They ended up helping to cut out letters for our blanket drive boxes. So the other kids went ahead and made the part on their own.

The kid who CADDed the part was upset because they felt like they had wasted their time cutting out letters instead of “having fun”. They only come to robotics to “have fun”, and not to waste their time on “stupid sttuff like cutting out letters’’.

I have strongly debated putting this out there as part of this blog. Not because I want to hide the warts and the ugly, but because it depicts a moment where a person was struggling to see what is important.

I struggled with how to handle that one.

How do I explain to that kid that I am going to carry that interaction around in my head for a long, long time? How do I let them know that every time I see them I am going to wonder if I handled that one properly. If I said the right things to let them know that I sort of understand the real frustration and reason that they were upset…Probably more than they did.

That I understood that they were really upset because something was “taken away from them”. That they felt like they had earned the right to make that part because it was their design, and that I was trying to get them to bring other people along with them so that others could learn to do what they can do. How do I convince them that we are a better team when we put others before ourselves.

The part ended up being too small anyway. Probably should have caught that before they made it…My bad.

Another kid ended up redrawing the part the correct size and got some other kids to make it.

Didn’t sleep well again last night…I kept waking up thinking about things that we need to get done, things that I need to remember to do, or remind the kids to do, and things that I don’t know the status of.

I tried to spend some time playing Forza Horizon 5 last night, but my mind wasn’t really in it. After about a half hour I gave up.

Moving forward.

As much as I really wanted to keep last year’s robot I think today I am going to have a number of kids on the team take it apart. I think I’ll have them salvage the parts we can off of it, and use them to get some of the current robot up and running. For example, we are waiting on motors and bearings for the intake and ball elevator. We have what we need…It is just tied up in the old robot. The reason why I wanted to keep it in one piece is because it has a launcher and it does all the things. It is perfect for community demos and showing people what we are capable of, but…if that comes at the cost of us not having a robot for this year then…

So…Hopefully that can get us some progress, and help our chances of having some sort of success this year.

We set Saturday as the drop dead day for swerve. If we can’t get it done by then, then we are going to go with a KOP drive train. We will have to modify a lot of stuff in order to make it work, and we may end up struggling to do very much on the other end of the changes, but at this point I am not sure what else to do.

And I wonder why I can’t sleep at night.

So…I’m going to fight to not let a few frustrations get in the way. I honestly do love this program, and my kids…I think that is part of what keeps me coming back. The hard part is waiting for them to grow into the people that I know they can be and watching them take all of the lumps on the way down the hill of growing up.


Today we worked on awards. Some of the kids get it, some don’t. We used to have an awards team…Times have changed…So, we spend about an hour on Tuesday’s writing as a team. Everyone is supposed to do their part. Some contribute more than others.

The hard part is that the kids who are capable of contributing the most are expected to do so in all areas.

After awards time I had them work on taking apart last year’s robot. A few of them seemed to really like the experience, figuring out how things worked and how to take them apart. Some of them were frustrated that I wouldn’t just let them hack it all to pieces, but instead made them take out each subsystem and then take the subsystems apart individually, salvaging as much hardware as possible. Others were sad to see it go. We had originally planned to keep it in one piece and use it for demonstrations, but, not having the parts we need in time to get things done is making it much more important to have something now, than to hope to have something in the near future. Really I was after the bearings, motors, and shaft couples for our ball elevator and intake. I am hoping that with those parts free and clear we can get to work on at least the first level by Saturday.

The progress on swerve was hopeful, but maybe not enough. I’m glad I was able to at least get them to understand they actually have to tune the PID loop, and we had them look at the actual values they were getting from the sensors instead of just making blind changes to their code and hoping for the best. It was nice that Mr. Carman and I were actually able to make things better to some degree.

I’m hoping that we didn’t bite off too much this time. I need to be willing to give up and cut bait if it isn’t going to work out.

So…End of Saturday.

I’ll try to keep you all posted.

Enough for now.



Hi! A couple suggestions in terms of code:

  • So high P could definitely cause jittering. One other thing to look at would be setting a tolerance for the PID controller and not running it if it’s within a tolerance of the setpoint.
  • I think the “fancy method” you’re referring to is using feedforwards and a ProfiledPIDController. While the drivetrain can certainly work without these, they can improve performance significantly in my experience. A feedforward controller is simpler than a feedback controller in that it takes a model of the system (derived from system identification testing or physics calculations, WPILib includes SysID which is great for this). It seems like in the SwerveBot code, the students may have inputted feedforward terms themselves instead of determining them from robot characterization. This could certainly cause jittering as well. The WPILib docs include good walkthroughs for system identification. A profiled PID controller caps maximum velocity and acceleration in order to smoothly control the system, so is also a good idea (although certainly a “once it’s working” thing).
  • Also a “once it’s working” thing, I would look into controlling the turning onboard the motor controller. This significantly improved performance for us (since it runs at . Essentially, you get the position of the absolute encoder when the desired position is first set, and then use that as a reference to set the desired position on the motor controller. Our code for this year might be a good example of this (although it’s for mk3/4 falcons and not mk2 neos). You can also do motion profiling onboard the motor controller (Spark max example here). Feedforward is a little different onboard the sparks in that there’s just a configurable “F” term – this is essentially just kV but may be in different units.
  • Feedback control in addition to feedforward may be useful, especially if you plan to run autonomous paths.
  • Finally, I don’t know how viable this is for your team right now, but I would definitely look into using some sort of version control (probably Git/Github) instead of Google Drive, if you’re not already. It has saved us from really serious trouble many times.

When we ran mk2s with the same absolute encoder. It helped to post each wheels angle calculation to shuffleboard\smartdashboard or to the riologs.

One thing I noticed in the code was that wpilib code is counterclockwise positive, while the encoders we’re clockwise positive. Have you checked to see if yours are the same orientation.

If so, you should consider adding “1-” which is a little different than just negati g the value… I think?

public double getAbsoluteEncoderRad() {
        double angle = 1-absoluteEncoder.getVoltage() / 5;//RobotController.getCurrent5V()
1 Like

Did your students use the template from SDS as a starting point?

You’ll be better off having the kids post a separate specific thread on CD for their questions. Not everyone who can actually help with swerve is reading this thread.

Highly encourage you to get the programmers on CD posting for help.


Agreed on the second point. However, i would strongly recommend against SDS template for swerve as a starting point, unless it’s to figure out how to interact with the motors for control (ie how to run loops onboard the motors). Perhaps because it has to work for many different configurations, the code is fairly convoluted and very difficult to debug, understand, and change. (And since it only works for teleop, it’s very necessary to change the code even if nothing ever went wrong.) The wpilib examples, which they used, are a much better starting point (or the examples of code based off the wpilib stuff like this one or ours.

1 Like

Thank you for all of the tips and suggestions. I have recommended that the kids 1) Actually join chief delphi and 2) that we as a team start a new thread for solving their problems with swerve.

There was more to it than that, but I’ll post the rest in that thread. As for this one, I’ll try to get back to what we were doing before the robot went sideways, or well…didn’t go sideways on us.

1 Like

Cautious Optimism

It works.

It is actually remarkably smooth too.

Not going to lie…I am pretty stoked about this happening.

Are we still behind schedule? Yes, but I was worried that a massive hole would be blown in any potential progress on Sunday when we had to scrap the idea of using swerve at all.

So…What did they change?

The error had to do with a conversion where they were dividing two integers and returning an integer instead of a float. Adding a decimal point made the value returned a float so…not 0.

I’ll copy what they said in an email explaining it here:

So…they found it. I think part of what worked was displaying the angle they were actually asking the motors to go to and seeing that that was wrong.

So…for the future. We need to work on troubleshooting. How to diagnose a problem. The problem with robotics is that there are so many variables. Is it bad code? Is it a physical issue? Is it a wiring issue? There are a lot of things that can go wrong. In our case it was a complete storm. Physical, (broken/stro[[ed plastic gears, bent encoder mounts, Wires being unplugged or plugged into the wrong places, or upside down, and code issues (bad PID loop tuning, not understanding values coming in, and not understanding what was actually being sent out.)

But…they figured it all out, and it is time to move on.

We made some progress on the ball elevator. We also worked out a new way to mount the frame to the drive train that includes a mount for the bumpers. Part of it got bent incorrectly and will have to be done again tomorrow, but all in all I am hopeful.

Sorry today’s post is so short. I promised myself I would get to bed on time tonight and here it is, 11PM and…

I hope everyone is happy and healthy,

Ok…enough for now.



Congrats to you and your kids! Getting it going is a big accomplishment. Hopefully you spend quite a bit of time practicing with it!


that’s great! Make sure they put it on carpet to insure that they have their PID set high enough to rotate the modules smoothly and that they reach their target angles.


Totally in the plans. Also, it is really nice that we are at a point where we can tune the PID loop. Up until now it has been a series of pretty major problems both physical and in the programming that have made that impossible to even imagine.