The Zebracorns - Behind the Stripes - Design, Code, and Build Blog (2023/2024)

[marshall]

This post has been a long time coming. Some folks probably know who we are and what we are all about but others might not so let me introduce any newcomers to The Zebracorns.

The Zebracorns (Team 900) started competing in FRC in 2002 (technically the name was “Team Infinity” back then). The team was started as a partnership between mentors and students at the North Carolina School of Science and Mathematics with the goal of introducing students to engineering principles through practical application. The team has since opened up membership eligibility to include students from the local community. Durham Public School students, other local public school students, private school students, and home school students are encouraged to join the team. The team now openly recruits students from all over the triangle area and routinely has over 50 student members (we don’t yet know what that count will be for the year).

The mission of The Zebracorns, a FIRST® Robotics Competition team, is to inspire and empower students across North Carolina to be exceptional innovators and leaders. Our students and adult mentors work together to learn and apply real-life multi-disciplinary skills, fundamental engineering techniques, and cutting-edge technologies through a creative design process within a culture of personal and team excellence.

Our Zebracorn mascot, though a bit fanciful, has a significant meaning. Our team was founded in a boarding school in Durham, The North Carolina School of Science and Mathematics, whose mascot is a unicorn; however, our team is made of students from various schools around the area and home-school students. To represent this diversity, we added stripes to the original unicorn mascot and created the Zebracorn (upon the chance of some re-branding).

We work out of our space in the Mechantronics Lab at the North Carolina School of Science and Mathematics. The lab is in the Hunt dorm (it’s a residential high school - some of our students live on campus!) and we share the space with robotics classes, programming classes, occaisionally the rocketry team, FLL teams, and FTC teams.

Our biggest sponsor (don’t worry, other sponsors will get their own posts later, we know some of you are watching), by far, is the NCSSM Foundation, an entity founded in 1979 to support the mission of NCSSM. The North Carolina School of Science and Mathematics Foundation has been organized to operate exclusively for charitable and educational purposes, including, but not limited to, receiving, administering and granting funds for the support of the academic and educational programs of, and any other phase of operation or program of, the North Carolina School of Science and Mathematics, as the Board of Directors of the NCSSM Foundation in its discretion may deem appropriate for the advancement of education. We can’t thank these folks enough for literally everything they do to enable and support us. It’s a tremendous amount of work and we’re humbled by it.

Ohh and we like to use ROS… and talk about it. We’re also big fans of neural networks and doing interesting things with them. Feel free to ask us questions about it! There will definitely be more posts about it as we work our way through the coming season.

• So what’s up with this post then?

Well… in true Zebracorn fashion, we are experimenting with what it means to have an open build process for the 2024 season (and possibly beyond). We already go above and beyond with sharing a ton of information with everyone, including teams all over North Carolina and all over the world so we are embarking on this effort as an extension of that work.

• Does this mean The Zebracorns will be an Open Alliance team?

We don’t know yet but we are hopeful we will be considered and plan on applying. Even if we aren’t considered one, we are going to document quite a bit here over the coming season, including opening our designs, our ideas, and our code.

• So what do The Zebracorns have to share today?

Ohh do we have some truly cool stuff for you today. We’ve got a long overdue revision to our very popular battery whitepaper (ZebraPower 2.0 - The Zebracorns's Battery Paper Update). We also have an update to our ZebraSwitch paper (Zebraswitch 2.0 - The Zebracorns upgraded Ethernet switch paper). They have their own threads but we’re happy to answer questions about them here too and felt like the combination of the two would be a pretty great way to kick this off.

We also released a paper from design and research work that one of our recently graduated seniors worked on this past year as part of the first ever cohort of the EE4300 Topics In Engineering - Robotics Design class at NCSSM: 2023 Intake Design Report

That’s all for now but you can expect more from us very soon. We are hopeful we can do about one post every couple weeks in the pre-season and average about one per week in build season. We’ve got a lot to share this coming year and we’re excited to share it with all of you. If you have questions then feel free to ask below.

Most of the posts here will likely be coming from Marshall (yeah we know, but he’s already on CD so it’s easier on us to get him to post) but the work going into those posts is coming from a lot of mentors and students and they’ll likely be posting and answering questions too so you can probably expect to see some new characters from time to time. While many of the posts might say “marshall” is the author, please note there is an army of people in striped pants writing things and contributing!

[Jimmyy]

Gotta love NC teams for being open! Excited to see what yall put out here!

[David_IsMe]

I’m very excited to not only see the progress but to get information on the why’s behind design choices! Gotta love NC teams for being mostly transparent.

[Katie_UPS]

I really like the intake design report and plan to share it in my engineering classes as an example. It hits all the documentation points that I want my students to demonstrate and its something half of them are already interested in

[marshall]

Ok, it’s been a while. We’ve been busy - but in a good way. Our pre-season has so far seen over 60 students join The Zebracorns for the 2024 season. Which is awesome but it’s keeping us very busy!

What’s a normal pre-season meeting like?

For us, we meet twice a week and broadly divide the team into two areas “mechanical design” and “programming”. That doesn’t mean that is all we do but we ask that all students choose one of those areas to focus on and learn about to help keep them grounded to the robot and the competition, no matter what they are working on. One meeting each week is a required curiculuum meeting and the other is a non-required but highly suggested project meeting. We alternate which sub-group has the required meeting so we can keep things reasonably divided but still have everyone meeting.

We’re very fortunate in that the school doesn’t just provide us with a classroom that we work out of but we’re also able to book other classrooms on campus and expand into them as we need quieter areas for more classroom based work. We’ve found this can help some folks focus a bit better than in our lab so we will hold curriculum lessons there!

The curiculuum meetings are where we teach the basics - things like OnShape and Python. Our aim is to get students familiar enough with some subset of tools/skills that they are willing to spend time outside of the lab on their own doing their own experiments.

The project meetings are more hands-on learning. Things like tool use… locations of parts. Taking old robots or game elements apart. Organizing and prep for the season. Lots of stuff. We also talk about ongoing projects and work on them, bringing new students along for the ride and helping them find their passions.

We finish every meeting with a really big human circle where we go around and have each person (mentors too!) say their name, their preferred pronouns if they’d like to share them, and something they learned that day. Sometimes, that can be something completely unrelated to robotics and it can be quite funny - other times it is something from the lessons and projects of the day. This process can be slow with 60+ people in the room but we’ve found it is one of the best ways to get to know each other and help build our team.

After the meetings are over, our leadership students (and others) will post a summary of events into the “Meeting Summary” channel in our Mattermost. We’ve found this helps us keep up with what happened and keep anyone who missed it informed:

What else have The Zebracorns been up to?

We took some time last weekend to compete at the Doyenne Inspiration East event. The Doyenne events are off seasons hosted by FIRST North Carolina and keep the pits and drive team roles restricted to female and non-binary participants (both mentors and students). The male members that went, were in the stands cheering and bringing the team spirit!

While we recognize that FRC is a sport for all genders, these under-represented groups deserve a day in the spotlight. We had a group of 3 female leadership students over the summer propose that we go and it was agreed, provided they helped recruit more young women to participate on the team in the fall. Not only did they hold up their end of the bargain but they’ve given us one of the highest percentages of female members that we’ve had since pre-2020. That’s a huge win for us and our team’s diversity goals!

At the Doyenne East event, after ranking 4th place, we captained the Winning Alliance (Alliance number 3) with our our first pick, the Eastbots (4795) and our second pick, The Chargers (5160). Huge thank you to both of those teams! And a huge thank you to all of the teams there and especially the Jag-Wires (7443) for hosting it!

We did learn one REALLY important lesson from the Doyenne East event that we want to share with everyone - teams… educate your drive teams (no matter how new or old) about the E-Stop button at the events. It’s the big red button in the driver station.

At some point, things in our driver station got swapped around and that resulted in our robot hauling itself at 2.5m/s across the field into the opponent’s community where it proceeded to fuse it’s wheels into the carpet (seriously). We had explained the E-Stop procedures in the lab to our new drive team members but… as it turns out… they are different at a competition. So, lesson learned. Big red button. Smack it if you need to or unplug the Driver Station from the Ethernet connection. We’ve also told our Friendly Neighborhood FTA (Hi David!) that they should have FIRST add something about the E-Stop to the drivers meeting script since teams can’t practice with it at home).

Pics of the damage (no, we really are not proud of this but we wanted others to know what can happen - even when you have a current and velocity limited robot with colson wheels):

Shockingly, after getting it back to the pits, all we had to do was scrape the major crude off the wheels and it went on to drive just fine for the rest of the event. Colson Collective FTW!

Anything else to share?

Our programming team has been hard at work! We’ve been working with NVIDIA and, thanks to a generous donation from them, we are getting ready to put an Orin AGX onto the 2023 season robot for testing. It was an extremely generous gift from our partners over there. We’re eager to do some testing with it and see what we can do with it beyond our existing vision pipelines. It might seem silly to some to put a piece of tech on a robot that is illegal under the current rules because of the cost limits but one of our goals is to put tech like this into the hands of our students and prepare them for what they’ll be working with when they hit college and beyond. We look at it like any expensive tool - the more exposure and experience we can provide, the better outcome for the students in the long term - teams aren’t putting Haas mills on their robots but that exposure and experience to machining is useful - same is true of machine vision and ML technologies.

Speaking of… our next ZebROS paper is coming very soon. It’s been in the works for a while and the students and mentors are putting the final touches on it… maybe one more week? We hope.

Stay tuned. More to come.

As a PSA: We highly recommend everyone get their COVID boosters and Flu shots as soon as they can! A lot of our members come down with illnesses this time of the year and we want them to stay as healthy as possible so they can be positive contributing team members. So get your shots if you can! It’s worth it for your teams! We won’t use it as the reason this post is so late but it was definitely a contributing factor! Go get your jabs!

[marshall]

The paper (and it’s thread) can be found here:

ZebROS 2023 - Zebracorns Whitepaper

Better late than never! We continue to use the Robot Operating System (ROS) as the foundation for all of our robot code, for the seventh year in a row. During the 2023 season, we began to harness ROS in a way we hadn’t before to gain a competitive advantage through streamlined code and ROS-based autonomous actions. We also had an extremely reliable robot; code ran successfully in 98% of our matches. Our work with ROS won us three Innovation in Control awards, giving us district points needed to…

The time has come to release another ZebROS paper upon the world! This one has been in the works for quite a while because of the never-ending COVID pandemic*. We’re excited to share it finally! It’s got a load of information about continued use of ROS(https://www.ros.org), videos of robot walkies(https://www.youtube.com/watch?v=tjJgNXBXBgQ), machine learning for AprilTags, visualization improvements, and even our findings about POV hats and significant digits.

A huge thank you to the student authors for getting this paper out into the world. It’s a long laborious process to make these but it’s something that we do to help our future selves when it comes to building robots. These papers serve as proof of what we’ve done, documentation for how we did it, the crazy stuff we learned along the way, and what mistakes to avoid next time. They inspire future students on their learning journey too. We really do reference them ourselves, a lot.

If you have questions about the paper then feel free to ask them below!

More Meeting summaries:
Some more examples of meeting summaries from our twice-a-week meetings. We promise we’ll get better about filling in more details for these later in the year but for now, you can use your imagination (or maybe ChatGPT) and fill in the gaps.

Mechanical 10/2:

• Really productive meeting today!!
• Built a frisbee scoring structure that we’re going to use for an off season practice game
• Got some new students using drills (thank you to everyone that helped)
• Worked on getting shelves organized and labeled.
• Worked on re-crimping battery chargers for SB120 connectors.

Programming 10/2:

• Did a tour of the robot, its mechanisms and sensors, and how we control them
• Tested Phoenix v6 code on the real robot, there are now more beeps from the Falcons and I think motor control might be mostly working using the new API (Editor’s Note: It does actually work now.)
• Tried to improve odometry quality, the Kalman filter now doesn’t crash (switched from a UKF to an EKF) but the data still isn’t great
• Python practice
• Also, people from both programming and mechanical tried to score frisbees in the goal that mechanical built which was very fun

This past week was a bit light as the NCSSM Durham residential students went home on break so they were not on campus but back at home with family/friends for a much needed break. We still had decent turnout for the local students and the residential students who live in range of the campus and wanted to join us - this means we’ve managed to get quite a bit done.

Mechanical 10/5:

• Learned about the limit feature in assembly mates
• Learned about variables in Onshape
• introduced our frisbee game, and started thinking of concepts for scoring mechanisms
• Began installing a TROPHY CASE
  
  

Programming 10/5:

• Working on tuning drive base for V6 Phoenix API
• 250Hz control on the 2023 robot is working:
  
  

Some cool stuff going on with klib and recalc:
We thought these were worth re-sharing. We’ve been talking about them and how to use them with our overall process this coming season. One prevailing thought we had is to copy judiciously from them (and our own internal tools) to build up two separate documents this coming year - one for “robot design calculations” and another for “robot documentation” as they are two separate ideas for us. At any rate, these are both great tools/resources for teams:

KLib: A Tool for FRC Design

New versions of KLib’s Design Accelerator and a brand new Strategy Calculator are now available! The Strategy Calculator allows you to calculate which tasks are worth a certain amount of points per second to allow easier and more accurate Strategic Design decisions Also comes with a robot cycle calculator using hypothetical numbers! Design Accelerator now includes an Intake tab to better calculate surface feet per second of that intake that’s always bothersome to calculate Comes with…

ReCalc - An online mechanical design calculator with shareable URLs

Hi all, Some quick updates. A new linear motion calculator is here: This now factors in acceleration, deceleration, and current limits, and should be much more accurate than before. Previously, the calculator assumed the motors were generating stall torque with no current limit, which is not really realistic. This loosely follows a trapezoidal motion profile, but it won’t be as accurate as the WPILib ElevatorSim class. It does some hand-waving and whatnot in order to prioritize speed of exec…

Spotlight on a sponsor: Cross the Road Electronics and the latest Phoenix API
The Zebracorns has been proud to be supported by CTRE for quite a while now. We’ve had a relationship with CTRE since we started with beta testing original Talon SRX back in 2014/2015. They have been receptive to our suggestions, feedback, and even our memes. We can’t thank them enough for everything they do for us and for teams across FRC to help advance the state of the art.

We’ve been testing the new v6 API for about 4 months now and working on the process to integrate it into our code base. This process takes us a while these days but we wanted to share our initial experiences with the community and to thank CTRE for their continued support of our stripey shenanigans! Seriously, thank you! You folks help make all of this possible.

One of our off-season projects has been updating our hardware interface to support the latest CTREv6 API (Phoenix 6 Documentation). For us, the “hardware interface” is the piece of code which is responsible for interacting with FRC hardware. A closely related piece of code allows users to specify configuration parameters for those hardware devices using a config file read at startup as well as a GUI to update values dynamically while code is running.

The hardware interface code has been around since we started running ROS in 2018, so it has “evolved” into something quite large. Updating to the latest CTRE API was a good excuse to rearchitect the code, make it more modular, and make it easier to work with. The new CTRE API was welcomed there as the improvements to make the API more consistent helped us simplify our code as well. While it was a bit nostalgic to say goodbye to some of the earliest code written by a student who is now about to graduate from college, using real-world units throughout the code is well worth it.

We’re in the last stages of porting our 2023 robot control code to use the v6 API. Once that is complete and we’re happy the robot is back to it’s original level of features using the new API, we plan to move on to trying out some of the new features. The fused CANCoder mode seems an obvious fit for our swerve steering motors (add model & config info), which use a CANcoder at a 1:1 ratio with the wheel position while the motor itself is behind a gear reduction. We’re going to use the sensor sync and latency compensation support to improve drive base odometry.

The updates to the closed loop control modes which add position+velocity targets will simplify the code we’re experimenting with for joint motion profile control of multiple mechanisms. We’re sure that we’ll continue to find new uses for the many new additions as we roll into build season.

As always, stay tuned as there is more to come!

*Reminder to go get your COVID and flu vaccines if you can. Seriously, it’s hard to do fun robot stuff if you’re sick.

[wilsonmw04]

i can’t deal with this tread anymore. coming from a team that is so black and white. I mean really.

[marshall]

@wilsonmw04

anymore. coming from a team that is so black and white

Wait until you see what we have planned this year.

[David_IsMe]

This is easily becoming my favorite thread learning new stuff laced with memes, I wish they did that in college next we need a subway surfers video playing in the bottom corner.

[marshall]

I promise, we’re not bad at updating this, just new to it. We want the posts to be something informative and different each time we post them. Life has been really busy though the past couple weeks and we want to keep the content interesting. With that being said, robotics is also a third place(Third place - Wikipedia) activity so we are doing this as we have time right now.

First, some more meeting summaries since last time:

Mechanical Design 10/16:

• Assembled the flat stock cart and found a home for it in the lab
• Worked on our prototype shooter mechanisms
• Cleared off a bunch of mess items from the work spaces that they were on
• Continued working on the configurable bumpers, and did the final touches for CAD. The weight issues were mostly sorted out by measuring outstanding items for more accurate densities and replacing them.

Programming 10/16:

• We learned that people have been called some interesting nicknames
• Learned about ROS publishers, the slides can be found here: October 16 - Publishers and Subscribers - Google Slides (we got to around slide 8)
• The code we wrote yesterday is here: https://github.com/FRC900/2023RobotCode/blob/tutorials_2023/zebROS_ws/src/beginner_tutorials/src/publisher.py

Strategy 10/17:

• Started analysis on 2013 game, got through keys rules and ways to score/actions with our estimate times and accuracy for them. Before next meeting we will need to come up with possible full cycles and compute the times and points/second.

Meachanical Design 10/19:

• Went over gears and pullies and worked on our prototypes

Programming 10/19:

• Was more individual, didn’t do anything as a group
• Helped some people go back over the code we wrote on Monday
• Did other programming-ish things, from bash scripting ascii images to web dev
• Helped a few people with their setups

TA Office Hours:
New for the past two years have been students serving as TAs (Teaching Assistants) as part of The Zebracorns. These positions are officially recognized as “work service” at NCSSM, which is awesome for those students as they can get credit for the work they do. Along with TAs, we have been able to host Office Hours for the past couple years. These TAs have setup an hour each week where they host a Zoom call and it’s available for others to join, talk about sessions from the past week, get help on a project, or just hang out and plan.

Leading the herd - Student Leadership on The Zebracorns:
The Zebracorns don’t really have specific leadeship roles for students. We don’t have captains or sub-captains or even grand poobahs. We just have Leadership Students. You’ll recognize them, they are the students who stand up at meetings to talk, to teach, to make plans, to try to execute on them, fail, and then do it again and again and again. They are the students who come early to help move tables and chairs around and they are the students who stay late to help clean up. They are the students that stand out with the work they do and they are the students who are willing to do the work and help with organizing many aspects of the team’s day to day work.

It’s also a pretty flat structure for leadership - we don’t have a heirarchy - it just doesn’t make sense for us at the scale we operate at. Our goal with leadership positions on the team is to ensure students are learning leadership skills, not to just give them a title, some vague responsibilities, and send them on their way. We back that up by emphasizing communication across the team as a whole among our leadership students - doing our best to create a culture where issues can be brought up in context and dealt with - be that a sensor not being in CAD or a concern about behavior.

Since we are open to all students in the area to join, it means that our leadership students have to be capable of working with peers from all over. Contrary to what some might expect, leading for us, doesn’t mean just working NCSSM residential students but also helping us cultivate 8th, 9th, and 10th grade students from all around and they are all at different points in their robotics/STEM journey.

We don’t have a bounding box around the number of students we take for these positions either. We don’t cap it or try to hold ourselves back. It’s not a popularity contest with voting and we do our best not to annoint anyone - sometimes field promotions happen when a need arises and a student steps up to the job though. The mentors are always looking for students who can step up with just a little push and the right motivation or project. Most of these students do have a particular area of expertise - typically programming or design but there are a lot of other roles, including some that aren’t so technical and extend into the realm of project management, media creation, and relationship management when it comes to sponsors.

While we do have limitless options for students to take on leadership responsibilities, those responsibilities aren’t necessarily the same as they are for other teams. Completing applications for grants is definitely something we work with students on from time to time but it is not something we do with great frequency as we (the royal mentor we) work very closely with the business and development offices at NCSSM and the NCSSM Foundation directly to make sure we are maximizing opportunities and not crossing wires for communication with sponsors/donors.

We do often work with students on approaching specific sponsors for donations but more common for us is working with a group of students to help tell our story and to help us with specific partnership opportunities that the school is working on. Ultimately, this helps us build up trust and rapport with sponsoring partners over time and that benefits multiple generations of students.

There’s a lot more to this than we can put into a short post and it gets a bit hand-wavey because every year is different and every group of students are different. We’re proud of the students who step into these roles though and thought it would be good to highlight them and talk a bit about how it works for us.

Simulated Button Box:
We’ve been hard at work on refining our “button box” that we use for our driver/operator. In recent years, this box has become very important to our automated actions on the robot. Through the magic of ROS, we could always emulate a button push with a quick command but now we have the ability to virtually create our button box and enable us to play with the layout in software and to even use it! This will let us design the box from year to year and tweak what each button, knob, or switch does before we ever get to a competition.

Big thank you to the folks who have been working on this one. It’s been a big project and we think it has the potential to improve our process for what has been a time consuming activity in the season.

Outreach with the TerrorBytes:
We were fortunate enough to be invited by Durham Public Libraries to do some outreach at an event they were hosting for younger kids. We got things a bit twisted up with our friends over on 4561, an amazing team and a new-comer to the Open Alliance as well. We had a lot of fun at the event showing off the robot(s):

More coming soon! Stay tuned!

[TheGuyWhoAsked]

We would like to share with the FRC community these fully configurable two-piece bumpers.

However, you’ll probably notice the “This document was shared via a link and is view only.” warning when you go to copy the file. This isn’t intentional, it’s because we are on the OnShape Enterprise Education plan and we can’t share files for export outside of the workspace easily. We will happily share files outside of it if you want a copy for yourself, just ask us. We thought this particular item might be something that others would want so we are making it available here. It’s possible it will eventually diverge from the other linked one but both are available for viewing.

It employs a full sheet metal backing, based on our bumper designs from recent years, to maximize sturdiness and help keep the center of gravity low. The document also contains mounting hardware, which is based on designs we’ve found to be reliable, and enables quick replacement of the bumpers, using sliding tabs and spring pins.

This mounting hardware is in the assembly, but not all of it is part of the measured mass of the bumpers, and teams will likely need to modify it to use it in their designs, such as adding clearance for frame gussets in some of the hardware. There are other modifications that teams may find useful, such as adding additional pocketing to the sheet metal backing, changing the mounting hardware, etc.

The reason we made this is the same as it is for any other configurable subsystems – it saves future working time, since we can input some variables and make minor modifications, rather than having to design it from scratch. This time is especially valuable during the crunch of build season. Along with saving design time, it also allows us to get our quote to Fabworks in as fast as possible, allowing us to receive the sheet metal backings much sooner.

The bumpers allow for the frame perimeter width and length, ground clearance, gap between the frame and bumper backing, and the respective gaps between the front and back sides of the bumpers to be modified using a variable studio. Using a separate variable studio with formulas that use those input values, it regenerates all the parts and mates from any changes made.

In the document, we provided descriptions for the input variables, but we’ve added them below for clarity.

The first two variables are FP_width and FP_length. These control the intended frame length on the side where the bumpers split, and the side where the bumpers are not split respectively.

The third variable is frame_gap, which controls the gap between the sheet metal backing and the outside of the frame, and it is uniform around the entire frame.

The fourth and fifth variables are front_gap and back_gap, respectively, and they control the width of the opening in the “front” and “back” sides of the bumper pieces, respectively. However, keep in mind that in some cases, it is beneficial to mount the bumpers such that the splits in the bumper pieces are on the sides of the robot, so those gaps don’t necessarily have to be on the front or back of the robot.

Here is an illustration of these variables from a top view:

The last variable is ground_clearance, which is not literally the ground clearance of the bumpers, but rather the distance between the ground and the highest point of the bumpers, which for these, would be the upper gussets. The reason it is specified like this is because robot rules in recent seasons have been specified by this height and it is almost always advantageous to minimize height off of the ground to keep center of mass as low as possible.

Another important note about this clearance is that this was designed for a chassis with SDS mk4i’s with the L-plate above the frame, so the value for that input will vary depending on the type of module. For instance, to use it for an SDS mk4i with the L-plate below the frame, add 2.25 inches to the intended distance between the ground and the upper gussets. This will vary depending on the module, but the “offset” that should be added to the intended distance between the ground and upper gussets is 4 inches minus the ground clearance of the frame tubes with that module.

Here is an illustration of the ground clearance from a side view:

[marshall]

Wanted to say how awesome this is, how fantastic @TheGuyWhoAsked has been working on it, and also highlight that we did share a version that is “public” in OnShape here:

@TheGuyWhoAsked

We thought this particular item might be something that others would want so we are making it available here.

The top-most link is direct to our workspace in OnShape and can’t be copied/cloned. We’ve got a request to OnShape to enable Public sharing of Enterprise Education docs but that’s another story.

Probably worth mentioning that most of our links will be for the NCSSM workspace, but if anyone ever wants to clone/copy something, let us know and we’ll work to get it “public”.

[Daniel1464]

Nice job!

[ty.sayman]

Thank you! @TheGuyWhoAsked for taking on a “not as easy as it looks” kind of project and wrangling into a very useable and useful thing.

[marshall]

Crashing our way to success

This pre-season, we’re examining a more capable processor, an NVIDIA Jetson AGX Orin (because why not, we like to do crazy things on 900 - Editor’s Note: We typically call this phenomena by an abbreviation “NFN” or Normal for Nine Hundred). This board has an approximate cost of $2000 ($1600 with a student/education discount), meaning we really don’t want to damage it beyond repair. We’re planning to add shock/vibration dampening to protect this coprocessor during violent collisions.

So, now the question is: how much shock do we need to absorb? Let’s quantify that:

crash boom bang

We used the ADXL345 accelerometer mounted on a breakout board from Adafruit, connected to our current Jetson via I2C. We wrote a ROS node to publish data, named very helpfully by one of our programming students. We then crashed the robot into the wall multiple times (as you can see in the video above) and used rosbag (the ROS logging framework) to record accelerometer data.

We’re still examining the data and the results aren’t yet what we expect. We are reasonably confident in saying that a robot can experience at least a 250 m/s^2 or roughly 25G acceleration (Editor’s Note: more like 25 OMGs when watching the robot slam into the wall) - we think this number may be higher but still have data to collect and work to do to validate it.

Odometry

Our odometry and localization performance is currently not great. This is somewhat surprising, given that we have a plethora of sensors (our ZED camera, our CTRE Pigeon2, and wheel encoders). However, we’ve been faced with more pressing technical issues and didn’t have much time to focus on this issue until now. It is now one of our priorities for the offseason – we want to run better paths.

Our first attempt at improving odometry was to experiment with ROS’s ekf_localization_node (which runs an extended Kalman filter for sensor fusion). We did previously have some code that theoretically ran a Kalman filter, but it was using a UKF where the covariance eventually got so large that the node just froze because the state had blown up. Switching to an EKF fixed this and we don’t know why but it works (NFN)! We’re now able to get a Kalman filter to fuse our IMU yaw and odometry, which was pretty cool. However, we’re still trying to figure out how to best fuse our ZED odometry with our wheel encoder-based odometry; right now the fused output is great at either following the ZED or following the wheel odometry.

We did many tests seeing how accurate odometry was (both with fusion and without), by driving the robot around and then back to its starting place. Unsurprisingly, all of our odometry sources were not right at the origin, and which one was closest depended on the situation. We ideally need a more rigorous methodology to see exactly how each source drifts over time from some ground truth.

Finally, we’ve been experimenting with doing odometry in a way more similar to WPILib’s code since that seems to work for most FRC teams. This sets up an inverse kinematics matrix to do a transformation from desired chassis speeds (x, y, and angular velocities) to wheel velocities (x and y, which can be converted to an angle and a speed using basic trigonometry). We can take the Moore-Penrose pseudoinverse of this inverse kinematics matrix to get the forward kinematics matrix, which transforms wheel velocities into the best-fit chassis speeds (minimizing the error between the actual wheel velocities and the wheel velocities corresponding to the calculated chassis speeds).

We wrote a ROS controller to compute this odometry. It uses wheel velocities and angles computed using CTRE’s latency compensation framework. We then publish the chassis speeds (after applying the forward kinematics matrix) as a ROS geometry_msgs/Twist message.

There’s a lot more going on here… and we’ll eventually share more about it as we develop it out.

Gazebo Testing (Editors note: 3 people are going to get this joke.)

Another one of our crazy projects has been working to set up gazebo which is a physics simulation that has built in ROS integration. Our end goal is to be able to have a full model of the robot and field (ideally before we have the robot built) to test our code. Perhaps it goes without saying, but this would be extraordinarily useful, and would allow us to easily verify mechanism control or try out moveit for controlling arms and complex joint assemblies.

Currently we are using onshape-to-robot to export our CAD as a URDF, and so far have found it to work with few modifications to CAD. Most of the modifications are just renaming mates that represent degrees of freedom.

The programmers even added colsons to CAD!

Now that we can successfully export a URDF of our robot, we have been working on integrating it with gazebo. Our goal is to make use of CTRE’s motor simulation to find the torque to apply to different joints, then simulate in gazebo and plug the position of the mechanism back into the motor sim, as if we had real mechanisms moving. We have some code for this but currently the robot does not move as expected in Gazebo. Here was one of the earlier attempts to try and spin, that’s almost the right axis!

Now that we can successfully export a URDF of our robot, we have been working on integrating it with gazebo. Our goal is to make use of CTRE’s motor simulation to find the torque to apply to different joints, then simulate in gazebo and plug the position of the mechanism back into the motor sim, as if we had real mechanisms moving. We have some code for this but currently the robot does not move as expected in Gazebo. Here was one of the earlier attempts to try and spin, that’s almost the right axis!

Gazebobo

After fixing a few issues, we have a moving robot!

Gazeb-woah

It still drives too slowly compared to our actual max speed, friction in gazebo is likely the cause. Regardless we are super excited with the progress so far, having a moving robot is a big first step.

Disc Launcher Prototyping

After spending the last month or so wrapping up our designs, we finally had our design reviews and began manufacturing and testing. Our “design reviews” are conversations about a design that allow for constructive feedback. The questions and suggestions presented by peers at these design reviews are used to refine designs and fix potential flaws. We encourage new students to think and examine each other’s designs for flaws as well as interesting/compelling aspects and provide feedback to each other in a constructive way.

In the past few meetings, after reviewing designs, we finally set our students loose and began manufacturing our frisbee launching prototypes. We started with cutting wood, and eventually added shafts, wheels, gears and pulleys until we had working mechanisms. This week has been mostly dedicated to testing, which consists of shooting disc golf discs into a scoring structure designed by our leadership students.

An example of the type of mechanisms that have been tested - they have all been successful at scoring, once tweaked a bit:

Disc_Prototypes3

Disc_Prototype4

We are very proud of how far all of our students have come and look forward to using our experiences designing and manufacturing during build season. Stay tuned for final prototype test runs!

[mjansen4857]

@marshall

This board has an approximate cost of $2000 ($1600 with a student/education discount)

Isn’t there still a $600 per part limit? Curious what you plan to do with this on a robot if it can’t be used in competition? Just a development platform?

@marshall

However, we’re still trying to figure out how to best fuse our ZED odometry with our wheel encoder-based odometry; right now the fused output is great at either following the ZED or following the wheel odometry.

Have you guys been able to get the ZED odometry to correct for drift with the area memory feature turned on? The docs make it seem like that’s what it should be doing but I have yet to see it actually correct

[BrendanManning]

@mjansen4857

Isn’t there still a $600 per part limit? Curious what you plan to do with this on a robot if it can’t be used in competition? Just a development platform?

from above:

@marshall

Our programming team has been hard at work! We’ve been working with NVIDIA and, thanks to a generous donation from them, we are getting ready to put an Orin AGX onto the 2023 season robot for testing. It was an extremely generous gift from our partners over there. We’re eager to do some testing with it and see what we can do with it beyond our existing vision pipelines. It might seem silly to some to put a piece of tech on a robot that is illegal under the current rules because of the cost limits but one of our goals is to put tech like this into the hands of our students and prepare them for what they’ll be working with when they hit college and beyond. We look at it like any expensive tool - the more exposure and experience we can provide, the better outcome for the students in the long term - teams aren’t putting Haas mills on their robots but that exposure and experience to machining is useful - same is true of machine vision and ML technologies.

[marshall]

@mjansen4857

Have you guys been able to get the ZED odometry to correct for drift with the area memory feature turned on? The docs make it seem like that’s what it should be doing but I have yet to see it actually correct

The short answer is “no” and the long answer is “no, and Stereolabs engineers have advised us that the feature isn’t fully baked at the moment”.

[Daniel1464]

How do you guys plan to use the power from the Orin GX? Considering that these days, full-blown ML models can be run on something like the limelight 3, I was wondering if you guys were struggling to fully utilize the power of the processor(unless you have some super-powerful ML model cooking up, of course…)

[marshall]

I suggest looking at this thread: ZebROS 2023 - Zebracorns Whitepaper and reading the linked paper. If we’re ever enabled to do so, we’ll find things to use it for.

Short video demo though:

Particle Filter Demo

Of note, that code was running on an Orin NX and it worked just fine. We had 100hz code loops and now have 250hz so the Orin NX has a lot of capacity left.

EDIT: It occurs to me that a folks won’t bother reading and won’t get it so here’s another video from the robot’s POV with the detections: https://youtu.be/p-PIHN8kKPE?si=nhCffOe42TGfJCpc

We are identfying many known objects on the field (object and its coordinates are both known) and using them to feed a particle filter. This is in turn enabling a localization to occur.