Techfest 2019, held on Saturday June 1st at Millennium Point, Birmingham is the UKMARS main event of the year and includes the UK micromouse contest as well as a host of other contests.
Registrations now open at: http://registration.ukmars.org
At the 2019 Minos conference in April, the UK Micromouse and Robotics Society (UKMARS) agreed revisions to the rules governing its contests. Many of these changes were minor, to reflect the common practice that has been observed for several years. Some were more significant and are intended to bring the event up to date.
The most significant changes are for the UK Micromouse contest. This affects both the full size (classic) contest and the half-size contest. For these, UKMARS have decided to adopt a translation of the current Japanese rules for these events. There are minor changes to some details but, for practical purposes, the scoring for both contests is the same. There will no longer be a search penalty and the scoring is based only on the fastest run of each robot.
You can see all the current rule sets here:
All MicroMouse builders & fans are welcome to come and visit Easton & Otley College (Otley Suffolk) where we will have our test 11×11 maze available to demonstrate MicroMouse to the visitors of the College’s “Big Day Out”. There is no competition as such, just an opportunity to test mice within a larger maze, and let members of the public see what MicroMousing is all about.
Date: 15th June 2019
Location: Easton & Otley College (Otley Campus, Suffolk). IP6 9EY.
Maze: 11×11 test maze (full size), example of half-size modular maze and walls
Contact: David Churchyard (firstname.lastname@example.org)
The 1st Micromouse Symposium 27 April 2019, Gondomar, Portugal Micromouse Symposium 2019, the 1st International Symposium on Micromouse, will be held in Gondomar, Portugal, 27th April 2019. Industry experts, researchers and academics are expected to gather together to share ideas and experiences surrounding frontier technologies, breakthroughs, innovative solutions, research results, as well as initiatives related to the Micromouse Robotic Contest. Micromouse Symposium 2019 offers you a conference with wonderful experience in Gondomar – Porto.
Submission of Papers
The working language of the conference is English. Prospective authors are requested to submit full papers (6 pages max) following the guidelines available on the conference website. Accepted papers will be included in Symposium open archive. Each accepted paper should be presented at the conference by one of the authors.
Submission of Full Papers: Feb. 15, 2019, Mar. 15, 2019 (extended)
Acceptance notifications: Mar. 15, 2019, Mar. 29, 2019 (extended)
Submission of Paper Final Version: Apr. 15, 2019
Early Bird Registration: Apr.15, 2019
Micromouse Symposium 2019: 27 April 2019
The 19th conference takes place on 6th and 7th April 2019 at the Quality Hotel in Coventry, U.K.
Papers are requested on all aspects of Micromouse and small autonomous robot design and use. Maze solving, wall following, line following and drag racing are the main contexts in both full-size and half-size formats. There will be an opportunity to demonstrate robots in a 16 by 16 maze in both full- and half-sizes as well as a line following course.
Keynote speakers include Peter Harrison, UK solver champion, with his international contest roundup and Duncan Louttit, chairman of UKMARS on the effect of rule changes on mouse design.
We are looking for speakers on any subject related to small robot and robot contests.
If you have suggestions for content or papers to offer, please contact : email@example.com
Keep your eye on the UKMARS web site for additional information
For many people, the task of solving the maze is central to the micromouse robot problem. After a while they come to realise that it is secondary to actually making the robot move quickly and reliably through the maze. Even so, the maze has to be solved. My micromouse software expects to be able to test the maze for a complete solution every time it enters a cell while exploring. Not everyone does this but, if they do, how long does it take? I benchmarked my software to find out. Continue reading
The UKMARS Autumn Micromouse competition took place on October 13th at Hazlemere near High Wycombe in Buckinghamshire.
This was the first occasion that UKMARS was able to hold a micromouse competition using its own mazes and tracks and included for the first time an 18×18 cell half-size maze. The full-size maze was built by Duncan Louttit with assistance of Bernard Grabowski. The half-size maze bases were also provided by Duncan with the walls and posts churned out by Bernard using his 3D printer. The timing gear was provided by David Hannaford and Ian Butterworth for the full-size maze events and Duncan Louttit for the line follower and drag events.
Source management is essential to software development. Even if you only use it to undo mistakes, there are great benefits. Of the available systems, git is probably the most popular. It is directly supported inside many editors and IDEs as well as the incredible resource that is github. Here is a simple workflow method that you can use to manage projects.
To get started with github, please have a look at their help pages: https://help.github.com/
Assume that the local repository is correctly set up to point to an upstream copy (origin) and has a local branch called master that tracks the remote master.
local and remote branches
- The upstream repository normally contains a single branch – ‘master’
- Content in master is always good-to-go. It is a ready to publish working version of the product.
- The history of the master branch should be clean and linear. When features are added or changes made, the commits shown in master should follow a clean, linear pattern with a logical progression. Clean up development commits before they are merged into the master branch. Use ‘git rebase -i’ for this
- Where possible, local feature branches are deleted when a feature is complete.
- Exceptionally, a feature branch may be pushed upstream temporarily. For example, if development is handed over to another person.
- Pull requests will generate temporary feature branches upstream
adding a feature
In the simplest case the developer will just want to modify the latest version in master. Thus the first step is to prepare the local environment
- Make the local environment up to date with upstream origin
git checkout master
git pull master
- Create a local development branch and get ready to work
git checkout -b feature
- Tag the start of your work so you can find it easily later
git tag start-feature
Note that the tag should be unique. If you work on several features at the same time, then use a tag name that is related to the actual feature being worked on. Perhaps you could use start-. You are now in a feature branch. Commits are made here as and when needed. Commit often. Keep changes granular. For example, if you rename some variables, you might want a commit after each variable is renamed so that you can unpick one from another later if it all goes wrong. After a while, you might consider your feature complete and tested. The local commit history may be untidy and confusing and may not tell the story well. You can tidy it up. Git interactive rebase is the tool to do this. You will get a file containing a list of commits which can be re-ordered, joined and have their messages edited.
IF and ONLY IF you have not modified your master branch, you can modify the entire feature branch history by doing an interactive rebase on master since that is the place the feature started. If master has changed locally, that will not do what you want. Instead, you have to find the start of the feature branch. If you followed the advice above, it will be tagged. This is a safer approach
- Tidy the feature branch history
git rebase -i start-feature
Quite possibly, you did not tag the start of the feature branch or have some other difficulty locating the place in master where the feature branch starts. Git lets you find this with a slightly arcane command:
- Tag the commmon ancestor of the feature and master branches
git tag start-feature $(git merge-base feature master)
After the interactive rebase, you should have a local feature branch history that can be added to the end of the master branch and will form the next published version.
Now you need to make sure that the new feature will work with the current state of master. If you are the only developer and only work on one feature at a time, this will be easy – you already know it works. But, if the master branch has changed for any reason, you need to test your changes. the master branch may have been changed by other developers or you may have changed it in some other operation – perhaps a bugfix, or another feature.
After making sure there are no uncommited changes in the feature branch, you need to switch back to master and bring it up to date. Everything should work without problems because we have a rule that says master is always good and we are just bringing master up to date.
At this point, the feature branch could be repased onto master and any issues dealt with there but that would leave your local master in an uncertain state. It is better to switch back to the feature branch and rebase master onto that and then sort out any issues. This way, only the feature branch is potentially broken.
- Bring master up to date
git checkout master
- Return to the feature and incorporate the new master
git checkout feature
git rebase master
Now you have an up to date copy of master with your changes in your feature branch. If master has not changed, this will cause no problems and nothing will be committed so you can just carry on.
If master has changed while you were working on the feature then your changes may have caused conflicts. These will need to be resolved and changes made until everything is working again.
It is possible that this is an involved process and master changes some more in which case you might have to go around a couple of times. Whoever is in charge of maintaining the upstream repository should use a mechanism to make sure that this is unlikely.
Finally, you have a working feature in an up to date copy of master but it is all in your feature branch. You should also have an up to date master. This is a good time to do an interactive rebase and tidy up all the commit history so that it looks good when pushed up stream. Now you need to get your changes into the local master and push them upstream. (Note that managed repositories will use a pull request to incorporate changes. That is not dealt with here).
If it is important to track this version/revision/build, you can add a tag to the master branch and push that upstream so that specific versions can be pulled as needed at a future date.
- Incorporate the feature into master and push it up.
git checkout master
git rebase feature
git merge feature
git tag V18.09.15.a
git push origin master
git push origin V18.09.15.a
The git merge command will do a fast-forward and just bring the head of master up to the most recent commit.
When you are sure all is done, remember to tidy up. You can delete the local feature branch and temporary tags to save clutter. The tags and branches can be listed out so that you can find them easily.
- Tidy up
git tag -d start-feature
git branch -d feature
And you are done. The feature is complete and master is up to date.