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.

Software Architecture and Test Engineering

After a hiatus, I'm back. I broke up with my girl friend which gives me much more time to do the things I enjoy doing and a lot less stress. Robotics, Artificial Intelligence, and my blog. Good nerdy engineering enjoyment.

The Test Engineering group I'm in is made up of mainly hardware people. A lot of them write software, some of them think they can write software, a couple of them really can write software. A software architecture is something required by the process but foreign to them. The bosses, who are mainly hardware types, want to make sure we've thought about the software before we start. Mainly because the hardware guys typically start writing software get to a point where it's a big mess and then patch as well as they can.

In the software past, the software architecture was called the preliminary design. Somewhere along the line someone came up with a paradigm shifting idea to rename it to software architecture. No matter what it's called, it's still just a high level view of the software job at hand.

Almost all of our tests are sequential, simple stimulate and check the UUT. TestStand is our standard test sequencer and we use it very simply, sequential testing with some very minor looping.

It can be a simple functional flow or a simple high level flowchart. We do set of similar tests followed by another set of tests, etc. The architecture is simple, non-complex by real software standards, and straight forward. Almost any thing should be acceptable as an architecture.

Occasionally the architecture will be more complex. Once this happens, then more advanced techniques are needed. More advanced flowcharts or especially UML would be a good candidate. Something to show interactions between different processors and different threads (although, where I work, threads are magic and unknown)

Any of this can prove to the bosses that we have thought about it, the flowchart is what they can understand. The people who are suppose to provide this are agonizing over what to provide and how to do it, taking a lot of time. The good software people are saying to let us know what format you want and we'll give it to you.

This is why we need people who can do software and not just hardware guys who code C. We know how to plan the software.

TestStudio vs. TestStand

I've been trying to learn about the Teradyne test sequencing product TestStudio. I wanted to compare it with NI's TestStand.

I'm going to say now that there is no comparison, it's not ready. TestStudio locks up so often that it's hard to focus on anything except the problems.

The main problem we're having is when we try to connect DLLs compiled by LabWindows CVI. About every third node (Test Step) that was set up to attach to a DLL would hangup TestStudio. The easier hangups only required TestStudio to be kill (via task manager) and restarted. Occasionally the PC would have to be reboot to continue working in TestStudio.

The Teradyne eknowledge site (the on-line help) was almost non-existent. I'm told by Teradyne that issues submitted by a company can only be see by people from that company. That means people can't see any product problems, issues, fixes, or comments . However, when we entered a problem in there on-line case tracking system, I did very quickly get a call to talk about it. Unfortunately I typically got excuses and that fixes we going to be in up coming versions.

My overall impression on TestStudio is that it's not ready. It's as if its an immature product only tested in on very specific uses. Quality control on the product seems to be left up to the user. The problem is that it's been around since about 2001 and a lot of these kinks should have been worked out.

Bottom line is that if you have a choice, go with TestStand. In my opinon TestStudio is not ready.

Sadness

I just want to let everyone know my Mother passed away last week from Pancreatic Cancer at the age of 86. She will be missed.

I'll continue my blog next week.