Welcome to the Team Rembrandts 2024 build thread, presented by openalliance!
We are back for yet another year with the Open Alliance. And in spirit with the 2024 theme, we will Make it Louder than ever! That means, among other things, that we will produce even more content for you to enjoy and learn from.
Every Wednesday until kick-off, we will highlight one off-season project from each of our departments on a rotating basis. But before we do that, some background information is in order.
What is Team Rembrandts?
Team Rembrandts is an FRC team based in Eindhoven, the Netherlands. The team operates quite different from the average US based team. Where the average team has students leaving high school after senior year, and possibly return someday after college to become a mentor, we try to keep our alumni engaged through university in order for them to quickly progress to becoming a capable mentor.
While this sounds good in theory, it brings some added difficulty. Because you effectively create an in-between support layer that also needs to be managed. Plus itâs difficult to keep a right balance between students, supports and mentors.
Weâve believed in this philosophy since the team was founded back in 2012, but it proves quite difficult to realize. Since 2019, weâve begun actively changing the team organization. This included getting our very own build location in 2022 and major restructuring, more stable partnerships with mostly companies and a steady influx of high school students. With further developments in the current off-season like restructuring our Notion environment (more on that later) and writing an official handbook. (Shoutout to the Zebracorns for theirs frc900 )
Team Structure
Since 2022, the team functions like an SME. We have two Team Managers overseeing the operational part of the team alongside five Department Managers, each responsible for one of the five departments: Hardware, Controls, Strategy, MarCom (Marketing & Communication) and Resources. In turn, each department is split up in sub-departments, with a Sub-department Lead being responsible for all internal projects. New for this year, we also have Supervisors for our two permanent projects: Skills Class 1 and Build Season.
Having such an elaborate structure makes the team future proof and prepared for eventual growth. Next to that, it also opens up more positions for people with leadership ambitions. The positions are mixed between students, supports and mentors.
Because we are a pretty big team, we need to coordinate a lot of different projects and store a lot of information. For this we have a digital workspace in Notion. If used correctly, Notion can be a very powerful tool. Past seasons however, we did not use it to its full potential, there was a lack of structure and information was often outdated.
Off-season is the time to evaluate, reorganize and plan for the upcoming season in order to kick-start the new season. Therefore we decided it was time to change up our online team workspace in Notion entirely, as it would greatly improve the teamâs productivity.
The Old Workspace
A group of members dedicated to managing our Notion workspace came together to discuss why we did not like using the current workspace. All these points came down to:
You can never find anything you need on notion because itâs hidden somewhere in an unstructured mess
You can never find anything you need on notion because itâs not on notion
Using Notion is not effective if we donât all use it
Using Notion is difficult for first time users
In order to make the new Notion actually effective, we looked beyond the old Notion, but thought of other problems we might be able to solve within Notion, such as:
A document we need is stored somewhere or with someone we canât reach
Thereâs documents which could help us, but people never actually share, which means we have to re-invent the wheel⌠every single season
We have a lot of meetings, events and partner visits to keep track of, a team agenda would help everyone to keep up with this
The Plan
The plan started by figuring out a system which would help us remain structured. We decided to give each department a color of the rainbow, so any mention of said department would stand out (and also who doesnât love rainbows). We made a list containing every single new feature we had thought of, and started ordering them in: must, should, could and would. A deadline for all projects was set and the project group got to work.
A Walkthrough of our New and Majorly Improved Notion
General Home Page
Our Notion tour starts at the general home page, where you can find everything youâre looking for. This home page starts with a general view, containing all department and sub-department pages to use as your everyday workspace. Underneath, thereâs the team agenda for all team wide events.
Besides the general part, thereâs a personalized agenda, event passport and even a personalized scrum board for you to quickly see what tasks you still have left. On this homepage, you can sign up for events and see your event passport, as well as the event leadership board, showing the TR members who have visited or volunteered at the most events!
This new version of notion contains some awesome features such asâŚ
A Library
Which will function as the TR search engine. Containing guides from every single subdepartment such as our TR branding guide, the beginner guide, a guide to awards and more! Whether youâre starting a project, using a machine or following a procedure, youâll find it all in the library. A Team member overview which functions as a database for everything member-related. Looking for a member with a specific skill set? Just look for the skills that are tagged and youâll find the right person!
With such a big team, a solid planning is one of the most important factors to success. Our new workspace contains a scrum-like planboard that the entire team can use. Based on certain filters, usable subsets of this board can be viewed. This enables team members to only see tasks assigned to them, or (sub-)departments to only see tasks relevant to them.
While the team is still adapting to using the new workspace, we have already seen a great increase in regular users and lots of positive feedback on the improved user experience!
Every build season, our hardware department is busy with the development and assembly of our robot. Unfortunately, there are no off-season events in Europe that our team can attend. However, this does mean that there is ample time during the off-season to work on fun internal projects!
The goal of these projects can be split up into two categories:
Personal growth of the department members
Improving the design and manufacturing process for the upcoming seasons
In this post we will zoom in on the first point. As mentioned in the first post, we strive to keep our students engaged when they leave high school in order for them to quickly become valuable mentors. This means we need an adequate challenge for everyone. In order to facilitate this we have several projects running at different levels. This goes from the initial exploratory phase, all the way to mastery.
Exploratory - New Skills Class 2 Program
When new students enter the team, they follow our Skills Classes. During their first year, they follow the general Skills Class 1 track together with all other new students. (More info on Skills Class 1 can be found in last yearâs build thread)
Contrary to the Skills Class 1 program, Skills Class 2 (SC2) is handled by the individual (sub-)departments. During the off-season, we completely redesigned the Hardware SC2 program to be more in line with the desired future of the department. For the upcoming season, we have 7 students following SC2 within the teamâs Hardware Department. This group is a mix between second year students and first year students with prior FTC experience.
During our team evenings, the students attend weekly lessons. Every lesson is designed to take 45 to 60 minutes with a mixture of practical skills and theoretical knowledge. The goal is to have the students get a basic understanding of every subject within the mechanical sub-department of the team. After following the program students should be capable of taking part in the discussions during build season and comprehend why certain design decisions are made.
The classes are taught by hardware mentors (who are generally young professionals in work life) in combination with the more experienced students (3+ years with the team) who developed the previous robot.
The lessons are divided into the following categories:
Workshop Introduction
Motors and Gearboxes
Conceptual Design
Power Transmission
Production Methods
3D-printing
Pneumatics
After the lesson the students can partake in building the robot designed by the experienced students to put their newly learned skills into action. The rework of the SC2 program aims to make students more engaged and ready for their first full build season with the Hardware Department.
Deepening - SolidWorks Lessons
To give people inside of our team the chance to dive deeper into SolidWorks we set up a set of SolidWorks lessons. These SolidWorks lessons are meant to increase the general knowledge of SolidWorks inside of our team, in practical terms this means that everyone inside of our team is allowed and encouraged to follow these lessons.
To test the knowledge they have gained during these lessons, we give our members the chance to get a CSWA (Certified SOLIDWORKS Associate) certificate. This is something we have done in the past for the whole team, but with the current size of the team this was not viable for the whole team and thus we focused on a smaller interested group.
Mastery - Off-season Robot Developed by Prospective Mentors
A group of experienced members (4-5 years within the team) wanted to design an off-season robot without any help from mentors to test their independence.
The members had from April till the summer break to finish the robot design. The end result is a cube runner robot containing a 12 motor swerve based on REV modules (the new rules regarding motors in the drivetrain had not been implemented at that timeđ). It was made to be as small as possible with a result of a frame size of 17" by 17". The arm can fit exactly over the bumper so that cubes can be picked up from the ground without a hole in the bumper. They scheduled feedback sessions with experienced mentors by themselves. Then they made the parts and some parts were outsourced to be made by partners (again without help of mentors).
After the summer break most of the design was finished. This meant that the robot could be built. To make sure this was used as a learning experience for members of the team, this robot is being built by the skills class 2 students of hardware with guidance from the experienced members that designed the robot and other mentors from the hardware department.
We continue to improve our way to teach our students, members and mentors to improve our team. By using a learning curve from students to mentor we create an environment that will teach the next generation how to be an effective Hardware department member.
We werenât planning on releasing them because they arenât that relevant anymore. But here is a STEP file and a SolidWorks Assembly of the design. If you would like any different file type just shoot me a message. (Be warned these are very much in a prototype state) 3 motor swerve.zip (78.4 MB)
Have you guys ever experienced issues with a second order kinematics swervebot driving in circles in simulation? When developing our swerve codebase, I noticed that our robot seems to drive fine while in simulation(driving straight while turning, and moving at the correct velocities when in closed-loop control).
However, once second order kinematics is swapped in, the robot seems to drive in circles when we command it with an x velocity and a rotation velocity. In addition, there are occasions where field-relative drive broke after driving while turning in sim(havenât replicated it consistently yet).
Weâre using kotlin, so it might be hard for you guys to debug anything, but weâre directly calling the SecondOrderSwerveKinematics class that you guys use(in addition to using a CorrectHeading class that basically encapsulates itâs usage in a seperate class). Has this issue been present for you guys, and if so, how did you fix it?
Hereâs the SecondOrderSwerveKinematics class we use:
Iâm not very familiar with Kotlin and how exactly your code works, but there are some things that you can try.
I would first of all check if the angle that is put into the secondOrderSwerve function is defined correctly. If I remember correctly we defined 0 in the positive X direction and positive rotation counter clockwise, but to be sure I would try different orientations.
I would also try to only use heading correction or second order kinematics to see if the problem is in one of the two or in the combination.
I also noticed that you donât use the moduleTurnSpeed output. Without using this, the second order kinematics is just regular first order kinematics. The way the second order works is that the modules donât just move to a certain angle, they also make sure they have a certain velocity at that point. We multiply the turnspeed with a feedforward constant and add this to the voltage of the turn motor to make sure the turn motor turns a bit faster of it is commanded a turnspeed by the second order kinematics
Yeah⌠Thanks for pointing that out! I wasnât using the moduleTurnSpeeds output; thatâs probably why it didnât work!
I believe that the heading is correct, as the robot turns counterclockwise when given a positive turn output. It also seems to move forward(in sim) when given a forward x output too.
I have a question about the units used. Iâm assuming them to be angular velocity, but are they in radians/sec or degrees/sec? Thanks!
Theoretically, the units of the module turn speed is radians per second. In practice, it does not really matter if you use rad/s or deg/s, because the output is multiplied by a feedforward constant which needs to be tuned. If you assume a different unit, the feedforward constant will just be different.
I tried testing second order kinematics with your suggestion, and second order kinematics works!.. with a catch.
You see, I diagnosed the issue, and found out that second order kinematics only did the circle spinning thing when I was driving while turning, with those kinematics, with field oriented drive⌠once I disabled field-oriented drive if the turning speed was > 0.0, it seemed to solve all the issues, and the robot drives perfectly.
Iâm also using WPILibâs fromFieldRelativeSpeeds, so I donât think thatâs the issue either⌠anyways, Iâll count this as fixed for now. Iâll let you guys know if it becomes an issue sooner or later.
Welcome back, everybody, to a new build thread update. This week, it will be about our software sub-department. More specifically, we will talk about how we prepare new students for the build season.
Educating new students was the most important project for the off-season and pre-season. We noticed in previous build seasons that during crunch time the students heavily relied on input and guidance from mentors. This was especially noticeable as the robot we built was one of the most complex ones in our history. We also noticed that the lack of well-trained students was limiting the output of the software subdepartment.
Software pathway to top tier contender
To take our software sub-department to the next level, we spoke to many teams at Worlds to see what resources they had available. We created an overview that defines different performance levels of our team and the required criteria and resources to reach those levels .
These criteria range from the amount of students and mentors needed, to necessary knowledge levels in the fields of control engineering, computer architecture, different communication protocols etc.
Our goal wasnât to increase our in-depth knowledge but mainly to focus on a sustainable foundation to keep the sub-department healthy. This meant mainly the main part of all our energy was put into the current and new students in order to get them up to speed and about software for the long term to increase the longevity of the sub-department.
Programming FLL Robots
Programming an FRC robot can be quite challenging, so we decided to start with programming FLL robots because the basis is very similar. Using blocks is much easier in the beginning than writing code. This makes it an easy way to start with programming. The end goal of of working with the FLL robots was to program them in such a way that they could balance on a piece of wood, similar to the charge station from 2023.
Whatâs a better way to get students hooked on software other than programming a robot? After an introduction to actuators in FRC and the structure of our code, we began reprogramming our 2022 robot, Resurrection, with students interested in software. We started simple with the intake and worked our way up in complexity to the shooter and drivetrain.
And what better way to learn how to program a robot than by programming a robot?
Previous seasons, we struggled quite a bit with the structure and logic of subsystems. Sometimes we even had to pull all-nighters to fix things like the logic of the 2023 arm subsystem. Therefore, a lot of focus was put on the code structure. More specifically, on how to divide the robot into subsystems and assign functions to these subsystems before actually programming it.
For the intake, this would, include: turn on, turn off, fold out, fold in. This makes programming much easier as these functions can be easily implemented into Java, and it also makes reading and debugging the code much easier.
This project was also a great way to introduce everyone to our Notion. Every student keeps track of their progress on their plan board in Notion, which makes it easier to see everyoneâs progress. It helps people get used to Notion as well before the start of the build season. We also added useful links and documentation to each task to help everyone along.
Student Autonomy
During this project, we focus on the autonomy of students too. In the build season, we want students to take more responsibility and ideally become responsible for the software part of an entire subsystem. The Notion plan board is also a great tool for this because it gives students more freedom to choose on which parts of the robot they will work and to take the initiative to ask for help and conduct research.
Future steps
We will continue with reprogramming Resurrection for the remainder of the pre-season. We are also going to prepare for build season by looking into the exact task division during build season. We are of course also looking into other development projects, but you will hear about that in a future post
So, just as a heads up⌠I noticed that whenever the drivetrain was set to a x, y and rotation speed of 0.0, the kinematics would return NaN for the turn speeds. This might have something to do with the matrices, as they might be dividing by zero at some times.
It wasnât really a problem for us, as we just made it return 0 if it detected NaN in the turn speeds; however, you guys should probably look into it, if possible.
Thatâs very good that you noticed that, I have actually never realized that this is an issue in our code Because the code for our swerve modules only runs if the targeted velocity is larger than 0.001, we have accidentally worked around the issue. Although it is not the cleanest solution, I would also advice you to do this, because it saves computational space on the rio when there is no input from the Joystick.
Yeah, we normally use deadbands from the controller side, and not the drivetrain side. Essentially, we have a custom wrapper around a xbox controller that would contain a customizable deadband value; then, we had a filtering function that would zero out all values of the joysticks that were below the deadband. As you could tell, that would be the prime breeding ground for NaN errors, lolâŚ
Hello everyone and welcome to a new update! This week weâll be talking about the Scouting & Gameplay projects that we have been working on. This post will be about the Scouting & Gameplay progressions weâve made within the Strategy department. In future posts we will also be talking about our other sub-department: Data Driven Decision Making (3DM). For now, lets start talking about Scouting & Gameplay!
Enhancing Scouting Skills
During the off-season we focused on teaching the new strategy members everything about scouting. Fortunately, Most of the current strategy students already went to regionals last year, and therefore they now have a better basis to continue learning in our department. During those regionals they did most of the scouting and strategy talks which gave them a lot of practical experience. To continue expanding their knowledge, we worked on a project that not only teaches them more, but also improves the scouting sub-department as a whole.
Previous Years
Team Rembrandts has a database where all the data from our scouts is gathered. But as most of you will recognize, events are stressful periods, and it takes a lot of time to effectively analyze the data and makes decisions based on that analysis. We wanted to create a system that automatically sets up a picklist for us. It would use pre-selected parameters so we could set priorities to automatically generate a close to perfect picklist.
Last year we started by just filtering the teams on important things for specific roles like: having a fast maneuverable drivetrain for playing effective defense, having autonomous starting positions that fit with our own preferred positions, minimal level of scoring on specific levels etc. Based on that we could start playing with the calculations a bit so it would choose the perfect fit for us.
Automatic Ranking
Using several filters we could get sets of teams that would be good for different roles i.e. defensive oriented, robots that scored a lot, robots that didnât score a lot but moved cubes and cones close to the scoring positions etc. But after this we were left with often very subjective discussions on tradeoffs, some teams score less points but move loads, which could end up being more valuable. While we have no regrets about our alliances this season (it would be an understatement to say that we loved working with them!), it would be nice to have some better statistical help with this.
So we set out to make a system that would help in ranking teams. This will also need input from us before competition on important qualities, and also requires us to make some adjustments afterwards. In the end, subjectivity probably wonât entirely be eliminated, but toned down a lot, and maybe even more importantly we will be able to make decisions a bit quicker in the stressful time we have during the last hours before play-offs.
Developing the system
We started by determining what features were important to filter on. For example: the autonomous starting position (which indirectly implies their auto path) is one of the most important features. When a team has an autonomous very similar to ours, we cannot maximize the autonomous score since we will be blocking each other. After having determined what to sort by, we applied these filters on the teams. To our surprise only 8 teams popped up, which is very good. With only these filters we already have a very small selection to choose from. This means no further software calculations are needed.
As there are always subjective features that should be taken into account, we rank the final 8 teams manually. For example: a team pops up at our top 8, but after having a closer look at the subjective and objective data we find that their robot is not a reliable scorer. So that might lead to us deciding to rank them lower. We cross-referenced our final top 8 with our hand-made picklist we made during worlds and they were largely identical. This proves that this way of ranking gives us the same result as we would have manually, however the automatic picklist can save us a lot more time during competition.
Future steps
The most time consuming part of constructing a picklist was to filter out all the teams weâre not interested in. This is currently done automatically so we can focus on perfecting the smaller list that this system generated for us. In the future, we want to use a better filter system to make the filter more accurate. Weâre thinking of using a weighted scoring model were every feature has it own weight (importance) and each team has unique scores per feature (based on scouting data).
For the past months, our Media & Branding sub-department has been working hard on our 10th anniversary TR-X video series! In these videos we take a look at every aspect of our team from the past ten seasons! This project is an excellent example of how we work together within the Media & Branding sub-department. This Open Alliance post will talk about how we regulate and maintain the branding of our team, using this project as an example.
Organising & regulating our department
Our Media & Branding sub-department currently consists of six team members. Within the team, our task is to keep our socials up-to-date. Besides this, we also take care of a lot of other projects. This is everything branding-related from flyers to posters to videos. We make sure that everything is organised and put into practise!
Every team member within our department has a role, for example: creating concepts, filming, editing and sorting and archiving our photos and videos. Normally, every Monday and Wednesday we work on these projects.
For our social media, we have agreed on posting three times a week. This can differ depending on which part of a season it is, we normally post more in the buildseason then in the off-season. To plan and organise these posts, we make use of a content calendar. For every part of the season, a different content calendar is made. Within this calendar, we can easily see what should be posted when, who is responsible and the status of the posts.
Content Calendar of how it is right now.
We mostly fill out our content calendar a few weeks before the new part of a season starts. So during Off-Season, we created the content calendar for Pre-Season. We mostly get our inspiration from previous years, such as the team member posts the Opa Foss History posts or our annual partner posts. But we also think of new concepts from time to time by finding inspiration online.
Our content calendar is not only used for Social Media, but also for other projects. Every year we write down a list of different kinds of posts, photos, projects and videos that we already know we need to make for the upcoming year. These can be projects such as the REV review videos, our annual reveal video, weekly buildseason recaps and for example our TR-X notebook. This is also a nice tool for knowing when your deadline is.
TR-X Video Series and how we handle productions & projects
The TR-X video series is a concept that one of our team members thought of during the 2023 regionals last year. We wanted to promote our tenth season as Team Rembrandts while highlighting every aspect of the past ten years.
Pre-Production
Like we do for every project, we start brainstorming on a simple concept and work it out into a full production plan. We started by answering two very important questions: âWhy are we making the video?â and âWho are we making the video for?â Our answers were: âTo show off every aspect of our teamâ and âFor a wide audience, every follower on our socials should be able to understand it with a minimal knowledge of FIRSTâ. With this information, we knew that the videos should be made in a short format, easily understandable with quick cuts for a nice attention flow and should obviously be filled with our recognizable orange branding. And so we came up with a format of ten videos, where four team members would each be asked four questions. The video should be in between about 1-2 minutes with a nice background music. After laying out the base format, we could divide the ten videos into ten different subjects. In the end, we came up with these ten:
My FIRST Year
My FIRST Volunteering
The FIRST Year
The FIRST Buildseason
The FIRST Regionals
The FIRST Worlds
My FIRST Impact
My First Impact
My FIRST Crescendo
My FIRST FIRST
My FIRST series
The worked-out concept for these videos is run past our intern Media & Branding sub-department. For this, we use a different channel within Slack than our usual #Sub-department_Media&Branding. We do it this way to keep our âspamâ divided from our more important messages to the team.
During the pre-production phase, we also make sure to plan everything that is needed for the filming day ahead. For this, we would send messages to team members who we think fit with the subject and ask them to take part in the video. We would send them the questions beforehand in a worked production plan and ask them to wear orange on the day of filming.
Production
For our production days we would work the same as with most of our review videos. Beforehand we make sure our cameras and microphones are fully charged and everything that we need is available at our buildlocation. We start with choosing which background we want in the video. For the TR-X series we chose between our office area, our workshop and the field. To prepare our location we place the camera on a tripod. We place our lamps from both sides of the interviewed person and we would place an extra orange light from the side.
Further we would pin the microphones to the collars of our team members. The microphone wire would be hidden underneath their t-shirt and they would place the transmitter in their pocket. This way the microphone is nice and cleanly hidden for the video. We would ask our team members to sit on top of a high chair and look at the Canon logo. This way they look in the direction of the camera, but never directly in the camera. Since this can give an eerie feeling to the viewer. Following, we would stand behind the camera and ask questions. We would work with the concept where one team member sits down and answers all three or four of the questions. Then we would pin the microphone to the next person etc.
Post-production
Within post-production one of our team members would edit the video. We mostly use the Adobe Premier Pro software for this. We would cut the video up into every suitable answer and then mark each person by colour. Then we would see which answer fits after which and add in music, the questions and our outro.
After the video, or any other post ever, is finished, we send it out to the team for review and feedback. For this, we use the same system as last year. For this review and feedback round to run as smoothly as possible, we use the âemoji systemâ. Within Slack, you can react to different emojis to different messages. This system also works in Discord or WhatsApp. If a team member has read the post, they react with the Blue Banner emoji. If the team member agrees with the video, flyer or post they react with the Foss Approval Face.
How to design
Within the Media & Branding Sub-department we do a lot of designing. We designed everything from our social media stories to our TR-X Notebook of last year. Our workflow of designing something is quite similar to how we film a video.
We often start by thinking of a concept and thinking of the questions of why and who we make this for. For example, if we take the TR-X Notebook, we start by thinking about why we were making this and for whom we were making this. This concluded with the fact that we wanted to make a book that from start to finish screamed âTeam Rembrandtsâ. A book that covered everything of our 2023 season, from hardware to outreach, but also strategy and team building. The book should show our hard work and complicated robot in an easy simple understandable way. This way, not only our team was able to read it, but also our parents, friends and partners. For this, we started with the structure of the booklet and which subjects we all wanted to write about.
After this, we started the design process. We always start to google for inspiration. We will search for things such as âcool poster designâ or âbest flyer designâ. Based on what we find, we will start designing.
For this notebook we wanted to make every page in the same style. This way you could see our team is connected with one big orange bloodline, even if our departments are so different. For this, we made sure that every page had the same layout. The information was added afterwards. However, during the further designing of the booklet, the layout did still change.
Adobe Creative Cloud
Currently we have two Adobe Creative Cloud licences that we use with four different team members. The apps we use the most for video editing are Premier Pro and After Effects. Within Premier Pro we edit all of our videos and we use After Effects for things such as our Safety Animation.
For the designing of Instagram posts, we used Photoshop and for the designing of Instagram stories, posters and our TR-X Notebook we used Indesign and Illustrator.
How to maintain a constant branding
Within Team Rembrandts we have a clear and orange branding. To make sure this branding vibrates back in every single piece of media we create we have created a Team Rembrandts Branding Guide. In this guide you can find our standard colours, the fonts we use and when and when to use and not to use our intro and outro on videos.
Further, all of our partnerâs logos, the FIRST season logos and our logos, fonts and colours can be found on our Notion page.
The #TeamREV Challenge
This year again we are participating in the #TeamREV Challenge. REV Robotics is a well-known name within the FRC Community. They make a lot of great products such as their swerve modules, their new REV NEO VORTEX and their new NEO SPARK FLEX. Last year REV started with the #TeamREV Challenge and this year it is back. Within this challenge, you can gather points by completing different challenges. Last year we made some awesome review videos about different REV products and this year we will continue these!
Further every month we make sure to use our #TeamREV hashtag under every post we make and we show off our volunteering work at FTC on our stories! REV cares about these initiatives where you help other FRC or FTC teams and support them by giving points for it!
REV Robotics offers us a lot of Media and branding opportunities through this challenge and we are grateful to be #TeamREV once again this year!
What are some tips we can give to teams who want to expand their branding?
As said in our previous post, start on time! Planning and organising is one of the most important things in our department. The better a post or project is planned, the easier it will to put the project into practice
Use Google for inspiration. We never start designing a poster, flyer or story post without looking for inspiration first. Starting from zero is almost impossible and looking up other posters or flyers of which you already like the design saves up a lot of time! Take inspiration from what you love and convert it into something with your style and branding. Donât try to re-invent bread when youâre already sold on focaccia (or any other type of bread!)
When starting with posting regularly on your social media, itâs smart to plan things. Start by taking 15 minutes every week to make a post about what you have been doing that week. From this, you can lay a base for maybe posting two times a week or maybe eventually even three times! We wouldnât advise posting more than three times a week since this can easily be too much.
Engage as much as possible with other teams online! This will expand your network around you. You can do this by tagging other teams (if they appear in your post) or by using hashtags such as omgrobots or #2024Crescendoseason.
And if youâve got something FIRST-related to share, itâs always a great idea to let @First_official know!
Keep your stuff well organised! Keep all of your different layers or maps within your project named and organised. Keep it so organised that, when at any given moment you can not finish the project, someone else can!
Future Steps
We will keep our Media & Branding department running smoothly as it is now, trying to produce the best content we can!
Hey guys, sorry for pestering you, but I have another question.
Does second order kinematics automatically apply field-relative drive?
In sim, our robot is driving field-relative with second order kinematics, without applying ChassisSpeeds.fromFieldRelativeSpeeds()⌠However, it still seems to drive field-relative.
In fact, when we then apply ChassisSpeeds.fromFieldRelativeSpeeds on top of second order kinematics, everything seems to break down.
yes it does indeed apply field-relative drive. Looking at the SecondOrderSwerveKinematics class, all matrices are constructed using the field relative module angles. In case youâd like to have robot centric drive, Iâd suggest changing moduleAngleFieldCentric on lines 75 and 76 to moduleAngle.
Because the code for our swerve modules only runs if the targeted velocity is larger than 0.001, we have accidentally worked around the issue. Although it is not the cleanest solution, I would also advice you to do this, because it saves computational space on the rio when there is no input from the Joystick.
