• Welcome to Redshift Project Depot.
Main Menu

Recent posts

Robot Software / dev laptop holder inside cabin...
Last post by Louis L - 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.
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 summa...
Last post by Louis L - 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 th...
Last post by Louis L - 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 - April 27, 2018, 11:07:27 AM
Minor cleanup to OP wording for clarification.
General Topics / New Robot Cart - do we need on...
Last post by Louis L - 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 jo...
Last post by Louis L - 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 summa...
Last post by Louis L - 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 summa...
Last post by Louis L - April 09, 2018, 08:46:59 PM
updated intake, pot, max speed, and reach behind status
General Topics / Reflections on the season
Last post by Louis L - April 06, 2018, 11:56:33 AM
The season isn't over yet (we still have BattleCry) but I want to write some thoughts down while I still remember them! These are not in any order.

  • Let's not forget the KISS principle. Keeping things simple doesn't mean it can't work well. Simplicity should not be confused with lacking in functionality; things can be simple and effective. Simplicity also does not mean that we're not aiming high. Aiming high is about achievement, not implementation or complexity. A simple design that achieves a lot is aiming high. A complex design that achieves little is just a poor design.
  • We can learn a lot from failure. How we bounce back and recover is also a good lesson. Looking back I like the idea of making a major change post-first-event more and more. Rather than wait until the following year to say "here's what we learned last year" we shorten the cycle and say "here's what we learned at the last Event". And a more immediate turn-around means a more quicker feedback. Of course, this is only good if the team is willing to absorb the results and learn from it.
  • Also important is to make sure that whatever went wrong in the first design is not carried over in the remake. We don't want to double-down and repeat a mistake, that would defeat the goal of learning from them! This statement may seem obvious but I can tell you that habits are hard to break, and convincing people not to repeat what they feel is "right" is even harder.
  • It's not personal. Whether a design works as intended or not is just that. If it fails to deliver, so be it. Lots of designs have been tossed by the wayside in the annals of history. It's not personal.
  • We all have bad days. No big deal. Everyone has them. The key is not to make them over and over again. That's the difference between between having a bad day (and realizing it) and always having bad days (because things are never changed for the better).
  • We need to finish in 5 weeks. So let's PLAN for 4 weeks. We know there will be issues which will stretch it to 5 weeks. Then we integrate, test, optimize in week 6. Our best years have been when we accomplished the 5 week schedule. We can not afford to ignore the time it takes to integrate and test. If you think of the time it took to get rid of the bugs at an Event, what if that time had been spent in the workroom instead? Naturally this has a tremendous impact on the design, the schedule, the availability of students due to midterms, etc. We need to learn to work within these parameters.
  • We're still afraid to think outside the box. Each year we talk of unique mechanisms for specific tasks and each year we bail out. When will this change? Ex: climbing this year.
  • Everything has weight. And it's not our friend. We need to design with weight in mind. Weight cutting at the last minute is what they do in boxing and MMA; it's not something we want to do with robotics!