Recent Posts

Pages: [1] 2 3 ... 10
General Topics / Planet naming contest
« Last post by Louis L on July 22, 2018, 10:09:54 PM »
Use this thread to suggest names for the planet. Rules are below. We'll collect names until Monday Aug 6. Here are the rules:


DESTINATION: DEEP SPACE Presented By The Boeing Company brings us to a planet in deep space that is as mysterious as it is inhospitable. This lifeless planet presents many challenges: Its atmosphere is toxic, its ever-changing landscape is dangerous and unpredictable, and…it has no name. Would you like to name it? Now is your team's chance to influence our story and be forever known as the team that gave our planet its name!
The FIRST Robotics Competition 2019 “Name the Planet" Contest is open to all past FIRST Robotics Competition teams with plans on returning during the 2019 FIRST Robotics Competition season, as well as all rookie teams for the 2019 FIRST Robotics Competition season. Only ONE submission is allowed per team, and must be submitted by the Lead Coach/Mentor 1 or 2 as designated within the Team Dashboard. If your team does not yet have a permanent team number, please use your assigned temporary team number. Submissions must be complete by 11:59PM EDT on Wednesday, August 15, 2018 to be considered.

Name the Planet Contest rules:

(1) No submissions may contain material protected by intellectual property laws, including, by way of example, and not as limitation, copyright or trademark laws (or by rights of privacy or publicity) unless you own or control the rights thereto or have received all necessary consents to do the same. For example, “Disneyland” is not an appropriate name.

(2) The Planet Name will represent your team and FIRST, and it must be designed in the spirit of FIRST Core Values.

(3) The Planet Name should be written using characters in the modern Latin alphabet not exceeding 50 characters (including spaces).

(4) It is important that we know the correct pronunciation of your planet name. Although the pronunciation of many names is obvious, some require special attention. The pronunciation guide is a way to help us pronounce your planet name correctly. The pronunciation guide should be written for English language speakers. For example, “Raul Gonzalez” would have a pronunciation guide similar to “rah-OOL gon-SAH-les”. It’s recommended to use a pronunciation resource such as the following document in creating your pronunciation guide:

By submitting your entry into this survey, you irrevocably grant to FIRST and its assigns, licensees, and successors the right to use your submitted Planet Name in all forms and media including composite or modified representations for all purposes, including advertising, trade, or any commercial purpose throughout the universe and in perpetuity. You also waive the right to inspect or approve the use of the Planet Name for publication or other written copy used in connection with the Planet Name.

Please note, we are collecting the name and email address of the Lead Coach/Mentor 1 or 2 who fills out the contest entry in order to ensure only ONE contest entry per team is received, to follow up with your team if needed, and to notify you if your entry is selected.
Robot Software / dev laptop holder inside cabinet
« Last post by Louis L on June 24, 2018, 08:59:18 PM »
I made a "holder" for the dev laptops in the tall cabinet. We'll use this Fall (2018).

Up until now, the dev laptops were either stored vertically (where they can fall down) or stacked one atop another. Stacking is not a good idea since each weighs 6 to 7 pounds so the bottom on gets crushed (good thing these have a strong magnesium chassis but the LCD is still a weak point). So I made a box with slats. Each laptop gets its own place to sit vertically without leaning on another laptop or falling over. Each slot is labeled 1, 3, 4, 5, 6, 7. There is no "2" since that laptop has been retired and used for parts. Everyone using a laptop is expected to put it back in the correct slot.

Above this unit, there is space for the chargers so they no longer will clump up on the shelf.
Things we learned / Avoid initializing at power-time
« Last post by Louis L on May 21, 2018, 02:29:49 PM »
For 2018 (Panthera in PowerUp), the Pigeon IMU is initialized at power-up. This is when the orientation of the robot is established. Since we're using the IMU to provide field-centric driving compensation, it means the robot must be powered-up on the field, pointed in the correct direction.

At BattleCry, in the 2nd match of the elimination round, the officials requested that robots be powered on in the queue to speed up the connection process when setting up on the field. This meant our robot was no longer pointed in the right direction when the match started and both auto and the controls did not work as expected and the results weren't pretty.

  • Hardware power-up sequences that can affect game play should be done at the start of auto or the start of tele as needed.
  • If the above can't be avoided for performance reasons (for example, if the init sequence takes too long during auto), we need a hot key to do a re-init at game time. Better to waste a few seconds and forego auto than to ruin the entire match.
Program Management / Re: Post-RIDE discussion summary
« Last post by Louis L on May 09, 2018, 11:37:02 AM »
Made what is probably the last update to this thread.

We tested the climber last night and the camera the night before so all hardware mods are done. There is some minimal cleanup to do still - strap some wires down and grease the drivetrain. But aside from that the robot (hw and sw) are done. We have next week to practice before BC19.
General Topics / Re: Driver station - beyond the joystick and game controller
« Last post by Louis L on May 09, 2018, 11:32:16 AM »
I ordered a "kit" that consists of a small USB board with headers and a bunch wiring for connecting to arcade-style buttons and joysticks. Actually I got 2 different ones. They sent me the wrong one the first time; then sent the right one but told me to keep the first one. The first one has half the number of connections as the second one.

I need to poke around and see what this all means in terms of how the various supported buttons and joysticks map to a "real" controller like an xbox unit.
Robot Software / Re: User Interface
« Last post by Louis L on April 27, 2018, 11:07:27 AM »
Minor cleanup to OP wording for clarification.
General Topics / New Robot Cart - do we need one?
« Last post by Louis L on April 24, 2018, 05:02:05 PM »
Some have expressed a desire to build a new robot cart to replace the existing one. If we are to do this, we need to justify doing so and also make sure the changes are an improvement and address the deficiencies of the current cart.


The current cart is our second gen cart. The first gen was a piece of plywood drapped over the 4 ft dolly that was custom made for each robot. Standoffs on the plywood supported the robot. Since the robot was different every year, the standoffs were rebuilt each year to fit the robot. The standoffs allowed the robot to be "driven" while on the cart without going anywhere. They were also not very secure and didn't last very long.

The current cart has been in service for at least 4 years (that I can remember). Some of the goals addressed by this version of the cart included:
  • no pneumatic wheels (on old cart) to lose air
  • a place to carry batteries
  • folding design so it can be more easily transported if necessary
  • Securely hold robot
If you think a new cart is needed, please post why, what features are necessary, and any specifics about the build.

General Topics / Driver station - beyond the joystick and game controller
« Last post by Louis L on April 12, 2018, 05:05:04 PM »
I'm putting this here for lack of a better place on the Forum.

For next year, I want to try and experiment. I want to extend the control interface beyond just the (driver) joysticks and (operator) game controller. I want to build a custom input device (CID).

Why? Adding another device probably isn't the smartest thing to do, and on the surface, it's also not the most necessary. But I'm looking at this not from a pure Drive Team perspective but past that. For a given game the Drive Team knows the ins and outs of the controls - be they on the joysticks or the game controller. That's not an issue. They have put in the time needed to be good at the controls in order to use them in competitions. The software developers are also sometimes good with some/all of the controls. They have to use them during software development. The problems comes in when the rest of the world needs to use the robot and none of the people who know how it works are available. We try to keep the Forum UI topic up to date as a reference for this reason but it's not handy to have to refer to this document all the time.  What we need is something more intuitive and flexible.

What? The standard Driver Station consists of a Windows laptop and some controllers. Usually this consists of 2 joysticks for robot motion control by the Driver and one or more additional controls for the Operator. The joysticks are USB joystick devices and the controls are USB game controllers.

Some teams make an entire custom Driver Station where the Operator controls are embedded into a single panel.  The problem with this setup is that it the array of buttons and controls are fixed. I would like to have controls that are more intuitive. Here's what I have in mind.
  • The main Driver Station remains unchanged. This is a laptop with 2 joysticks and is for the Driver
  • The CID is a separate unit that is cheap to build; so cheap that we can build a new one every year. We can recycle old ones for parts as the robots are disassembled. Each one has a button layout that "makes sense" relative to the challenge. For added clarity we place a plastic overlay with diagrams, words, symbols, icons, or whatever else is needed to make it crystal clear what each button does.
  • The CID is just buttons and digital joystick(s) connected to a USB board that, when plugged into a Windows laptop, looks like a generic USB controller device. Boards like this are popular in the DIY arcade community. In fact AndyMark sells a kit that pretty much covers what I would like to do. As I write this, it is out of stock. Related arcade parts can easily be found on the internet. [A "digital joystick" just means it returns 0 and 1 when the stick is moved in a particular direction. There is no analog signal that corresponds to the magnitude of the movement. Digital joysticks usually have 4 or 8 directions of movement.]
  • The CID is not intended to replace the game controller. Depending on the game, it may end up doing so but that's not necessarily so. A device like the Microsoft USB Game Controller contains analog joysticks that are very useful and (depending on the implementation) may not be replicated by the CID. Also a true game controller provides portability and ease of use that can't be overlooked. Naturally, if the challenge is such that the CID does replace the game controller entirely, it will be one less item for the Drive Team to have to deal with that year.
  • There is also the possibility of adding custom input devices that are not the traditional buttons and joysticks. This is an exercise for the reader!
  • Cost is projected to be about $50 for the controller board and array of buttons. The actual cost will depend on the number of physical controls. Implementation is pretty simple - just a box of the appropriate size and shape.
There are of course pitfalls to doing something like this.
  • It's one more thing for the Drive Team to have to deal with. If the Operator is also using a game controller using 2 hands it can be cumbersome to have to reach for the CID to press a button.
  • If a game controller is still used, that partially defeats the goal of having everything neatly labeled. Someone not familiar with the UI will not know the controls on the game controller.
  • Having to build a custom device each year is actually a feature. But it's still something to build and that's not always a good thing.
That's all I have for now. I'll probably get some parts to test with over the summer. I've used similar devices before for Arcadia and don't expect any issues.
Program Management / Re: Post-RIDE discussion summary
« Last post by Louis L on April 11, 2018, 09:58:57 PM »
We gave the pincher a good workout tonight and the new faster motor doesn't grab as tightly as the old one; it can drop Cubes. So we put the old motor back. It's back to the slower speed but it holds great. Updated OP.
Program Management / Re: Post-RIDE discussion summary
« Last post by Louis L on April 09, 2018, 08:46:59 PM »
updated intake, pot, max speed, and reach behind status
Pages: [1] 2 3 ... 10