Advice for New Students

From tiberious.org

Contents 1 Tips for 2006/7 MEng Robot Rally Students 1.1 Preface 2 Introduction 3 General Project Tips 3.1 Meetings 3.2 Communication 3.3 Working to Deadlines 3.3.1 Project Managers Role 3.3.2 Group Members Role 3.4 Positions in the Group 3.4.1 Setup 1 3.4.2 Setup 2 3.4.3 Setup 3 4 Project Plan 4.1 Milestones 5 General Tips on Software 5.1 Efficiency 5.2 C# or not C# 5.3 Code Revisioning 6 Improvements on my software 6.1 Interfaces 6.2 Kalman Filter 6.3 Obstacle Avoidance 6.4 Follow Way Points 6.5 Ladar 6.6 General Control System 6.7 Graphical User Interface (GUI) 7 Conclusion 8 Appendix 8.1 Example Project Plan 8.1.1 Term 0: (Summer ’06) and Holiday 8.1.2 Term 1: (Autumn ’06) 8.1.3 Term 2: (Spring ’07)

Tips for 2006/7 MEng Robot Rally Students

Preface

This is written to help people doing the MEng Robot Rally challenge and to explain something’s that perhaps have not been explained before. This report if you like is very software centralised, this is due to being in charge of the software for our group, and believing that whatever construction decisions, the basics are always going to be the same. All the opinions expressed herein are my own and should be taken as opinions only. I apologise before hand for any remarks I make that may be directed at any one in particular.

Harry Bragg (siu03hfb) © 2006. MEng Computer Science & Cybernetics

Introduction

Keep it Simple

This project at its base level is not actually that complicated, the reason it has not been completed successfully to this date is due to bad planning by the teams. It can get complicated if more is done than is necessary, and work is done that is not beneficial to the project. A complex design does not necessary mean a bad design however, if you plan on certain aspects that extend the current model (like some of the improvements listed below) then the project will be even more successful. When splitting the project down into its simplest form, this is what I got.

Note: The dotted line signifies that the Ladar can be used to help determine the position of the robot.

This diagram is all the robot really needs to do, in fact if programmed correctly; the follow waypoint and obstacle avoidance part can be merged, so create a nice linear data flow model.

From, a most likely, unreliable source the tasks the robot will have to perform will be different form previous years, where once it was all about time to get from A to B, it is likely to change to accuracy, of the final position with a more complex and longer course, but with no reliance on the time it takes to get from A to B.

General Project Tips

Meetings

• Keep meetings short and concise there is no point explaining things in detail that everybody does not need to know.
• Have the meetings at the same time and in the same place every week, this way no one has an excuse not knowing it was on, or for not preparing anything etc. I would suggest 4/5pm on Thursday.
• Ensure that there is a chair person that regulates the meetings, to prevent individual conversations and ramblings.
• Let everyone speak their piece, and then say what you have to say, interrupting will disrupt meetings. Unless of course they are rambling etc.

Communication

Communication is key for any project, and especially one with so many people in a group that are in-experienced in large team based projects. Generally it seemed to me that very few of the actual important information required was transferred during meetings, what we did was setup a wiki, which was underused and not really what was required for the project. Instead or as well as I would suggest either a mailing list or a forum (not both), these should provide a better structure for conversations.

Working to Deadlines

Project Managers Role

The project manager needs to ensure that everyone has at least 1 task each week or if they have an ongoing project, for them to split up the work and state what they will accomplish this week. The actual deadlines need to be engraved into people’s minds. Generally when someone gives a deadline, the actual finish date is likely to be closer to twice or three times the stated deadline.

Group Members Role

You need to attempt to discover all the parts of what you need to accomplish to complete the current task given, with this information produce a deadline date that is realistic. At the beginning this will likely to be slightly off, but hopefully towards the end of the project everyone will have a better idea of how long things actually take to complete.

Positions in the Group

The positions in the group depend greatly on the actual skill of the members of the group. In my opinion the following areas can be split up between people.

• Programming – All the programming on the robot
• Wiring – Physical wiring up of the power and connections etc
• Construction – Making the shell of the robot out of aluminium or whatever
• GPS – Find out what messages are produced and need to be sent (possible extend to use differential GPS)
• Ladar – Produce a list of the messages returned and that need to be sent to control the Ladar correctly.
• CAN/Motor – List of messages again
• Compass – Very short list of messages here
• Other – This could be any extension to the robot that is not software based, for example implementing bump sensors, or sonar sensors. Or some other project enhancement such as a recharging dock that can provide enough volts and amps to power the entire robot and charge the batteries at the same time.

Obviously some things will take more effort and time than others and such they will need to be separated as such.

Personally I feel that this project is actually suited to a group of 4 competent people, or 5 possible 6 less competent people.

Setup 1

If, for example you have 1 very good programmer in your group, and the rest are a bit unsure of their skill or abilities then I would recommend that that one person takes on all of the programming, this is effectively what happened for 2 of the groups in the year I did. In this situation the other members of the group need to make the programmers life as easy as possible, meaning creating clear and concise technical documentation regarding their particular part of the robot.

For the other members of the group I would recommend thus.

1. All Wiring + other
2. All construction + other
3. GPS + Ladar + other
4. CAN/Motor + Compass + other

Setup 2

If however you are in a better situation where you have 2 to 3 good competent programmers of roughly similar skill then the following list can be used.

1. The main programmer, generally the most skilled who takes charge of the programming, giving small chunks to give to the other members of the group who can program.
2. Help with the programming
3. More programming or other
4. All wiring and construction
5. GPS + Ladar + CAN + Compass (interfaces)

These are perhaps not the best solutions to the problem of dividing up the tasks between different members of the group, if however you do have 7 members of the group, and 2 people cant do and ‘other’ task, I suggest dividing up the group as such.

Setup 3

1. Main programmer
2. Secondary programmer
3. All wiring + other
4. All construction + other
5. GPS + Ladar + other
6. CAN/Motor + Compass + other
7. Other

Unfortunately this method also encompasses many other tasks; if there was a third programmer then it is possible to get away with not adding anything extra.

Project Plan

Milestones

The following list of milestones that are the basics needed to complete the project.

1. CAN board communications with PC, i.e. Motor.
2. Odometery from the motors correctly interpreted (in m/s, etc)
3. Position based on state estimation using odometery.
4. GPS + Compass communicated with.
5. Simple Follow waypoint code written.
6. Kalman Filter Implemented.
7. Ladar communicated with.
8. Object avoidance written.
9. Object avoidance and follow waypoint combined into final program.

Appendix 1 shows an example complete plan that could be followed.

General Tips on Software

Be Lazy!

Do not do more than is necessary, for example if someone has already written a piece of code that you need to do, then use it and save yourself writing it out again, and hunting for bugs again. Unless you think you can improve on it by starting from scratch.

Write the least amount of code possible, if you are faced with a situation where you could write 5 lines or 20 lines to do the same thing, even if the 5 lined section of code is less efficient, the first method will be better in the long run. This is because the more complicated something is, the more likely it is to go wrong, also as you are against the clock, in a sense, this method is better as it should be; quicker to write, easier to understand and a lot easier to debug, saving you a lot of time.

Once a basic system is setup and working correctly, then is the time to think about improving sections of code in either efficiency or features.

Efficiency

Writing processor and memory efficient code can be hard, all I did was to write the code in the shortest amount of lines as possible and keep it simple, using strong types instead of generic arrays and trying to avoid large recursions. All these should help ensure the processor has as little to do as possible when running the code.

One of the methods I found to help keep the system responsive and using little processor power was to synchronise everything (using A-Syncronous calls), using the inputs of information as starting points. For example:

Motor odometery -> serial -> can -> Kalman -> fwp -> motors

This is all one continuous stream of information, the next function or part of the robot is called directly from the previous part ensuring that there is no lag in the system, and nothing is kept waiting longer than needs be, and thus the information is parsed immediately after it arrives.

I managed to get just the server program running with Ladar and everything communicating normally at 40% in debug mode, and 20% in release compiled code.

C# or not C#

This is really a personal choice, however I currently think that C# is very good, it removes a lot of the pointless headers and having to deal with pointers that C++ has, and has a better general structure that is simple to understand, and very powerful, and in my opinion better than VB or Pascal. Another advantage is that you have 3 Teams worth of code to look through.

If however you are very comfortable with C++, then I would recommend C++.NET, or if you want to be different, a Linux solution. This approach also has at least 1 team's worth of code to look through and will be familiar to your year more than ours, due to starting with C++ rather than Delphi.

There is also the possibility with .Net to use multiple languages of code in the same program, for example if one person if very competent with C++, but C# is decided to be the language of choice for the project, that that person can use C++ and communication normally with the C# code using the complete Visual Studio .NET package (Personally I prefer C# express as it is lighter and seems cleaner than the full blown VS.Net program).

Code Revisioning

The one thing during this project that was invaluable was using an SVN server. Perhaps it was more useful because it made transferring code to the robot and back home, insanely easy. However some of the more advanced features of the server can be used to create branches to test code out, and ensure that it is separate from the working copy. I setup an SVN server of my own, and I believe the other teams created sourceforge.net projects for their groups.

If you are in the situation, where more than one person is programming the system, then revisioning is essential, enabling multiple edits from multiple locations, and alerting any possible conflicts.

As I said, we used an SVN server and Tortoise SVN on the computers, both are nice and free and easy to setup and use. There is a quick tutorial for Tortoise SVN on my wiki.

Improvements on my software

Unfortunately the software I created was not perfect, and there are many different parts that can be improved upon to create a more stable and better performing robot.

Interfaces

There are a couple of things that I would had of liked to have of done with the interfaces, and a few things I should had of done. One of the things I should had of done was to include a checksum on the CAN and Ladar software buffer, the reason for the Ladar was that it was rewritten 2 days before the final test and it did not work off the bat, so I left it. The reason for the CAN was that I was just being lazy. This is possibly one of the reasons the Ladar was acting temperamental in its operation.

What I would had of liked to had of done with the software interfaces, which was my original plan, was create a basic interface class that all the others inherit their properties from. This class would also include status flags and checking to ensure that the interface in question is working correctly. This would enable the robot (which currently can not see) which interfaces are actually working. This would also ensure that more information can be obtained about the robot, by itself, help diagnosing of problems and increased stability.

Kalman Filter

The Extended Kalman Filter (EKF) is generally considered relatively bad at predicting the position of a robot. This is due to its reliance on assuming the system in question can be approximated into a linear single order system. Also the latency of the GPS increases the positional error (gives a position of roughly were it was 1 second ago). One suggested fix of this problem is to use an extension on the EKF that predicts where the position is based on a time constant; however information about this on the internet is sparse.

What I would had of really liked to do is to implement one of the Sigma-Point Kalman Filters (SPKF), these use a second or third order non-linear system and produces positional information more accurately that the EKF. The real reason I looked into SPKF’s however, is that by using a particular type of SPKF, it is possible to compensate for latency in an input, in particular GPS latency.

Obstacle Avoidance

To get proper obstacle avoidance, a 3D, or even 2D map is needed to be created, which represents the areas it can see that are ok to traverse, and the area’s which are not. The current system just tries to avoid any obstacles it can see that the current time (which is not too bad, but it will not avoid the blocks of concrete on the side of the roads); however creation of the map can be tricky due to the positional information.

A possible way to solve this problem is to use the odometery information from the motors to adjust the position of the robot in the map, and the GPS/Compass data to adjust the position of the map around the robot, this will ensure that the information previously received from the robot will have the smallest difference error between the predicted and actual location of obstacles.

Follow Way Points

The actual code for the follow way points turning is fine, it is the part that works out that the robot needs to go to the next way point, and also avoid the obstacles in its path. In a perfect world this code would be inside the obstacle avoidance code, and to get just the ‘Follow Way Point’ procedure running the Ladar data would all be infinite (i.e. no obstacles).

Ladar

The Ladar is a very powerful tool, and really should be used for more than just obstacle avoidance. If a detailed map is created of the environment and it can be successfully interpreted to produce a different in position form the last measurement, this information can be added to the Kalman Filter, to greatly increase the accuracy of the positional information. Another method would be to use it to recognise landmarks and triangulate the robots actual position using the landmarks in the environment, for example a approaching a cross roads, will leave a particular pattern on the map created.

General Control System

The current state of the robots ‘brain’ is very dumb, it assumes everything is working, and uses simple procedures to follow orders given almost implicitly by a human (i.e. go to A, then B then C). There are many things that can be done to improve this state of affairs, the first thing I would had of liked to do was add some form of checking of the sensor interfaces, to ensure that they are working correctly and if not respond in a sensible method, and possibly, if there is a problem attempt to fix it (by reconnecting a port of other properties).

Using some form of AI inside the system would be very good, if a little too much overhead and uncertainty added to the system. However it could remove a lot of the pre-planning required by the humans for the robot to navigate its way around the campus, and possibly be used to interpret situations the robot is currently in using the Ladar (something to be looked at after the robot has been completed).

Graphical User Interface (GUI)

The GUI I built to monitor the current position of the robot may seem quite good, but it lacks some usability I would had of liked to add if there was more time. Due to not having Ladar code working early enough, displaying a simple representation of the Ladar on the map was not possible. Simple additions like this would remove some of the need, I found, of switching tabs to find out information I required. Also displaying a simplified version of the obstacle map (i.e. where the robot can and can not go) on the map would had of been beneficial, for debugging of the robots actions.

Conclusion

When looking at this project from a least amount of effort required to complete the project adeptly, the current software packages produced by my years MEng groups is the minimum that is really required. As a result one method that you may want to consider is taking one of the teams complete code base and improving upon it so that it actually works, and actually works well. Basing the software part on some of the ideas listed above in the improvements section, this would almost guarantee a working robot at the end of the year and hopefully a robot able to complete the course competently using all the systems. The only problem with this method is the requirement to engross yourself in the work of another programmer, and understand, almost explicitly, where and what everything does, this can make debugging code very difficult if you do not understand what it actually does. Also your supervisors may not like this idea (Ask them!).

If you want to start from scratch, as everyone has done so far then setting out everything that is required, almost from the very start will ensure that you have no surprises later on in the project and you can stay ahead of the deadlines.

Oh, and have fun.

Appendix

Example Project Plan

Term 0: (Summer ’06) and Holiday

• Make sure everyone has a position.
• Finalise the design of the physical part of the robot.
• Look through last year’s code and relevant technical documents for your part of the project so you know what is expected.

Term 1: (Autumn ’06)

• Week 1
  • Assemble the robots basic chassis.
  • Plug in the motors to the CAN board and talk to them using HyperTerminal or Serial Port Terminal.
  • Start construction of the robots power supply.
  • If there is more than 1 programmer, the second should start with another project (i.e. Kalman filter).

• Week 2
  • Play with the motors to determine the wheel circumference and a rough clicks per metre estimate.
  • Find out all the commands required to control the motors through the CAN board.
  • Set up the GPS device and start talking to it using raw commands.
  • Write a simple program to talk to the serial interface using your own class structure.
  • Finish power supply and start to work on the mountings for the computer, motor boards etc.

• Week 3
  • Write a simple software buffer for the CAN and GPS and talk to them using your own class structure (Milestone #1)
  • Construct computer and motor board mountings.
  • Work out what the values returned by the motor drivers to obtain what velocities are being returned.
  • Install XP on the robot PC.

• Week 4
  • Write a simple CAN parsing function to find out what the messages mean, and interpret them into velocities (Milestone #2)
  • Finish construction of secondary components.

• Week 5
  • Put the PC, CAN, Motor boards, GPS, etc onto the robot and run them off the power supply, or batteries if the power distribution is finished.
  • Otherwise, finish wiring the power distribution.
  • Write code to interpret GPS messages and some state estimation (Milestone #3)

• Week 6
  • Write code to interpret the compass messages (Milestone #4)
  • Finish the power distribution.

• Week 7
  • If there are 2 programmers then attempt to implement the Kalman filter.
  • Start implementing a pilot for the first test (suggestion: all teams so far have used pure odometery and turning on the spot when required). (Milestone #5.1)
  • If possible start construction of the Ladar Mount.

• Week 8
  • Test the robot outside extensively.
  • If the Kalman filter has been implemented, test that as well.

• Week 9
  • More testing.
  • [Note: By this stage we only just got odometery working and a basic GUI was built to show the movement of the robot].

• Week 10
  • Make sure everything works, relax a bit.

Term 2: (Spring ’07)

• Week 1
  • If the Kalman filter has not been implemented as of yet then it is time to start.
  • If the Ladar mount has not been started, start now.
  • Communicate with the Ladar (Milestone #7)
  • If a second programmer, write a simple obstacle avoidance based on a test environment. (Milestone #8)

• Week 2
  • Test the Kalman filter on the road.
  • Starting working on a simple (PID) based controller for turning smoothly around corners, this could be done for the first test if required, and incorporate into the existing follow waypoint code (Milestone #5.2).
  • More work on the Ladar Mount.

• Week 3
  • Mount Ladar.
  • More Kalman Filter/PID Testing.
  • Test the obstacle avoidance code with the Ladar.

• Week 4
  • Go outside with a simple but complete system and test the robots obstacle avoidance and follow waypoint code interaction (Milestone #9)

• Week 5
  • Find areas to improve the robot or find areas that need to be improved.
  • Start researching and implementing these areas.

• Week 6
  • If everything is working do some proper test runs of last years course (Cybernetics door to path near Physics), try to beat our record of 1.21 [Note: we were only running at 80% due to lack of competition (teehee), and general safety].
  • Otherwise determine what needs to be done and start working on it.

• Week 7
  • Start the routine of writing advances to the robot and testing outside.
  • Test with a tighter trickier course using more obstacles, and try to think of more methods to improve the accuracy of the position of the robot.
  • You have now finished (if you are lucky).