FIRST Robotics - 3 weeks to go

Sorry I missed last week, I was OBRE (Overcome By Robotic Events).



FIRST (For Inspiration and Recognition of Science and Technology) The build should be in full swing! If the robot building team hasn't started implementing the design, you need to get to it.

The software team, should have a prioritized list of what they need to implement and be trying to get it going. If you're doing the software, remember that the robot design, how things are going to work are changing. As the robot's being built, they ARE going to change things. Some parts of the design just won't work and so it will change. You need to be flexible and be prepared to throw away code.

The individual functions should be implemented in Sub-Vi's for LabVIEW and subroutines for Java or C++. For instance, the "kick" Functions should be implemented so that the SubVi/Subroutine only does what the robot needs to do to kick the ball.I.e Pull back kicker, release kicker. In the Teleoperated portion of the code, you should detect the button push and call the kick routine. This way, they change the way the kicker works, you only need to go to that function to change it.

This also helps when different groups are working on the code. One group can be incharge of kicking, one incharge of movement, one in charge of the sensors, etc.

One other import fact, and I've said it before, save off your code! when you have something working, save it somewhere so that if mess something up, you can go back to something that works.

Don't be afraid to try stuff in the code, just make sure you can get back to where you were.

Have Fun!

FIRST Robotics - 5 Weeks to Software

FIRST (For Inspiration and Recognition of Science and Technology) design is in full swing! The first week should have been full of brain storming and starting the design. By this time (the second week) the robot team should be prototyping, figuring out what works and what doesn't. Also all the sensors that need to be on the robot and where they go. The software team should be figuring out how the sensor's, actuators, and motors work. One hint, put all the sensor's you can on the robot, whether your know if you're going to use them or not. It's better that they're on the robot rather than trying to get them on later.

This week the software team needs to make a list of the tasks the robot needs to do. Brainstorm the software requirements. Then they need to be prioritized the list based on what's most important for the robot to do. The list may consist of things like acquiring the target and moving the robot square for a shot at the goal as the top priority.

You need to make sure the software tasks that are highest priority are done first. Things needed for the teleop mode need to be done first since most of the robots time is in teleop mode. Also see what can be used in both autonomous and teleop mode. But don't forget about the software for autonomous.

Before you modify the basic code, make a copy of whatever code is working. Always keep a backup of the latest, working software so that when something gets screwed up, which it always does when you're trying new things, you have code to go back to. When you make a backup, put a date in the backup name so that you know what code was developed when.

Do not be surprised when you have to scrape what you're trying and go back to the last working code. But don't be afraid to try stuff, that how you learn.

After this week you should have a list of prioritized software tasks, and some experiments with sensors, the camera, actuators, and motors going. Basically a plan what your going to do.

Good luck with your project.

FIRST Robotics - 6 weeks to software

I'm putting off talking about Testing a while and talk about software and robotics.



FIRST (For Inspiration and Recognition of Science and Technology) just announced the competition game for the 2010 FRC (FIRST Robotics Competition). I talked with several Rookie teams at the kick-off and practice build and a lot of them need help, especially with software. I was thinking there needed to be a "FIRST's Beginners guide to a Robotics software in 6 weeks". The reality is the software is usually worked on after the robot has shipped and even during competition.

I have worked with Team 704 (Go Warriors!) for a year and I've been in software since I started learning about software in High School, before FIRST, before PC's. I have my own robots at home (NXT and basic stamp controlled) and have played with them for years.

So on to the important stuff, how to get started with your software for your Robot. After the game is announced (or was announced as of when this was posted), the first thing your team should be doing is brainstorming about what you want the robot to do and the design of the robot. At this stage, the kids/mentors doing the software should be working with everyone else to come up with a design.

However, if you're going to be doing software you should also be looking at the motors, controllers, and sensors. Especially look at how to use the software to retrieve information and control the sensors. How to control the motors and pneumatics. The more you know about them the better you'll be able to use them. You can also speak up during design about what can be used for control and operation.

One of your main resources on the web should be the National Instruments web site. It's full of tutorials, information, help, and has a good technical discussion board. Also, contact the NI sales representative for your area and see how accepting they are to the idea of helping you. They might not be able to help much, but then again, if they can help at a crucial time when you're stuck, it could be key.

You need to work with the kids to figure out which programming language to use. With kids with little or no experience in programming I would suggest using the LabVIEW graphical language, it's drag and drop programming. If you have kids who are experienced in programming, find out what languages they know. If you have a couple kids who have been through a C++ or Java class, you might think about doing your project in one of those languages.

The main thing is to play with the sensors. Get the camera out, make a pattern on a wall of the target and see if you can detect it, lock on it, move it out of focus and back in. Walk between the camera and image and re-acquire.

See how the gyro works, how the accelerometer works, how the limit switches work with, all with your cRio controller. This first week should be learning what the kids know, how the languages are used, and about the sensors and controllers and how they work.

But also be in on the design and thinking of where you need sensor's, what sensor's and controllers you need, and the general build of the Robot.

More Software Architecture and Test Engineering

Last time I wrote about some challenges doing software architectures in a primarily hardware group of test engineering. First, we need a definition, so here's one that I had laying around in IEEE 1471:

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolution"

The software developed in Test Engineering, at least where I work, isn't so formal as to have a definition. However, we still need guidelines of what an architecture is.

Basically, a software architecture defines the structure of the system, the relationship between the major components, the behaviour of the components. It focuses on the significant elements, extending out to the needs of the UUT (Unit Under Test), and takes into account the needs of the systems users.

Since a lot of testing is sequential, the structure is usually fairly simple. For that simple structure just about anything can be used to document it. However, any threading or other processes or interaction with other processors should be included which can cause some complexity in the architecture.

The relationship between the various resources and how they need to be used to test the UUT needs to be diagramed. Sometimes this is straight forward, sometimes there's some complex interactions. Any communications between componants need to be noted.

Also the significant attributes of how user is involved (user interface). Anything that has user interactions.

That's it in a nutshell. The main thing is to let the team know what is being developed on a higher level. Also, to try to let the managers know you've thought about what you're doing.