After various reports of Windows 7 machines hanging while copying files to the mbed Micrcontroller, we did some investigations to recreate the problem, and of course find a fix. Some of the support cases I'd handled suggested that the problem didn't appear on XP, and when it did appear on Window 7, replacing the cable fixed the problem. Could it really come down to the cable not being suitable for Window 7? Fact is often stranger than fiction.
The conclusion is that if you're experiencing this sort of issue, try using another cable. If you want to know why, read on...
The first thing I needed to do was recreate the issue. We'd seen it in the office once or twice before, but not consistently, so the search began for a robust test case. I eventually got my hands on a a Lenovo T410. A 32 bit machine running Windows 7 Enterprise edition, and it showed the problem reliably.
So with a reliably failing machine in hand, I took the plunge and used a different cable. I couldn't believe it - it worked! But the "failing cable" worked on machines with Windows XP, can cable be OS dependent?
I then tried an assortment of cables. Some shorter than the 1.8m cable we ship. Some fatter, suggesting heavier gauge conductors and thicker screening. Some with RF chokes fitted at each end. They all worked beautifully.
The interesting point was when I decided to install Windows XP on the Lenovo T410 machine which reliably failed with the standard cable. In this scenario, the cable still failed with that machine when Windows XP was installed.
After this testing I realised that the correlation with the version of Windows is really a correlation with the age of the machine, and the USB chip set it contains. Most Machines with XP were older, and worked fine. Most machines with Windows 7 were newer, had USB 3.0 support, so therefore a different chip set which is more reliant on the quality of the cable. This hypothesis fits with the fact that the newer machine still fails when running Windows XP.
The conclusion of all this is that USB chip sets in newer machines can be a little more dependent on the quality of the cable for correct operation. If you have a newer machine (if it was shipped with Windows 7 seems to be a good indicator!) and you have problems with the USB Flash drive of mbed, try using a different cable. Maybe a shorter or fatter one that came with a Digital Camera or MP3 player. In the mean time, we have qualified new cables which have started to ship with the mbed Microcontrollers.
If you're having any USB related issues, try using a different cable.
I am very happy to be able to report that the long awaited Collaboration update to mbed is now live. This update contains a huge number of changes to almost every part of the mbed experience. This is the first in a series of posts which will try and explain the new features and how you can make the most of them.
Publishing and sharing programs and libraries on mbed.org now uses version controlled repositories. This is similar to how github, bitbucket, etc work.
Why have we made this change? For details, see the Collaboration page, but in brief:
- It's easier to find libraries and example programs, and easier to see what recent development has been done on them. Getting updates of libraries you use is now more powerful - you can see exactly what changes have been made and you can easily switch between versions of libraries
- It's now a lot easier to contribute your fixes back to the original author. You would simply publish a fork of their library, and the author can pull your fixes directly into his compiler for review with a single click.
- Publishing your code gets a lot more powerful - with full diffs, commit logs, branches and more. You still have the same auto-generated documentation, but you now also have a complete wiki with unlimited pages for each published program or library.
- However, the single greatest area of improvement is in the area of more than one person working on a codebase. We now have two main ways to do this. You can choose to pull changes from forks or to give permission for someone else to commit to your public repository.
This is just the start!
Over the next few months we have planned many ongoing improvements, both in the area of collaboration as well as completely new areas.
Since this is such a big change, we have spent a lot of time ensuring that the transition is as smooth as possible.
The biggest changes relate to adding new functionality around collaboration. However, even if you never publish code, you might notice a few changes:
- Published projects now look different, with more features
- The URLs for published programs and libraries have changed, but the old ones will still work
- You will notice a conversion step happening when you open a program in the compiler for the first time
- You'll notice some different UI in the Compiler relating to publishing and importing code
If you need help
With a change as big as this there will need to be a period of adjustment and there might well be one or two bumps along the way for some of you.
We are here to help! If you encounter a problem which stops you doing your work, email us at email@example.com and we will personally investigate your case.
If you have a suggestion/comment/question, please post on the bugs and suggestions forum.
Over to you
We believe mbed is unique in the amazing number and quality of the contributed embedded programs and libraries. This is thanks to you, the mbed community! We really hope the new features will allow you to go and create even more quality code and projects.
You may recall that we gave away a few Seeed Studio Grove Modules a couple weeks back.
The mbed users that we gave the modules to, have kindly shared these libraries - so check them out if you are looking for sensors to use in your next project
, has written up a cookbook page for the Ultrasonic Range Finder.
, has written up a cookbook page for the Grove 3-axis Accelerometer.
has written up a cookbook page for the Grove Real Time Clock
has written up a cookbook page for the Grove Temperature and Humidity Sensor
Well done guys!
We are happy to announce that the collaboration features we've worked so hard on over these past months is now in open beta. This means anyone is welcome to try out the new features. Read on below for instructions on how to try it out. You can also check out the demonstration video below:
View larger (Hint: enable 720p HD from the cog menu once the video is playing)
More information about the upcoming features can be found here.
Trying out the beta
Before you try out the new features, please be aware that:
- You will be using a beta which contains major changes compared to the current live mbed.org
- Using programs with the beta is a one-way operation - programs need to be converted to the new format (more info)
- Programs you publish while in betamode will not be visible on the main live site
As a betatester, you are invited to:
- Find and report bugs or errors
- Let us know if anything is confusing or unclear
- Suggest improvements/changes
- Have fun!
To try out the beta, visit http://mbed.org/betamode/ and click 'Enable betamode'.
Please let us know what you think on http://mbed.org/forum/bugs-suggestions or drop us a line at firstname.lastname@example.org.
Electronics distributor SparkFun held their annual Autonomous Vehicle Competition (AVC) last weekend in Boulder, Colorado - and we would like to congratulate for his mbed-powered Rover Robot coming in third place!
Simply put, the objective of the competition is to build an autonomous vehicle that can circumnavigate SparkFun headquarters without any human interference. Whoever does it the fastest, wins! What should also be mentioned is that the course is complicated by traversing through a narrow parking lot of a large building, giant red barrels, a pond, ramps and potholes to name a few.
The 1st placed Team 0x27 managed to navigate the 270m course in just 22.08 sec (officially 2.08sec after a bonus time deduction), with Rover Robot from Team Databus coming in at 37.16sec with an estimated top speed of 20mph.
Michael describes how the autonomous vehicle navigation information is calculated using only three key sensors.
The Robot Rover control system, consisted of three main sensors -
The GPS is a 20Hz Venus638FLPX on Sparkfun breakout board mounted inside with a roof-mounted patch antenna and a ground plane cut from a square of tin that's good for 5-10db signal gain. Serial communication runs at 38400 bps on one of the mbed UARTs. GPS supplies heading information. The robot ignores GPS position information.
Additional heading information comes from an STM L3G4200D gyro on a Pololu minIMU-9, mounted on an aluminum bracket up front. Communication is via I2C at 400kHz. The gyro is sampled at 100Hz.
Wheel encoders on both rear wheels provides accurate distance measurement. Sparkfun QRE1113 sensor boards mounted to the bearing carriers sense the stripes and send signals to a tiny surface mount interface board designed using comparators in a Schmitt-trigger configuration.
Heading is incredibly important in the Sparkfun AVC. An error of only a couple of degrees is the difference between crashing and finishing. The solution on Data Bus feeds lag-compensated gyro and GPS heading data into a Kalman Filter, using the results to update current heading and position with that historical estimate.
Gyro data is the foundation of the heading estimate. It's corrected for bias using heading data from the GPS. Unfortunately the GPS does its own massive amount of filtering and the result is a reduced dynamic range and lag. By saving a second's worth of gyro data and feeding that into a Kalman Filter, a very good estimate is generated. From this, the gyro-based heading is updated. The end result is a heading estimate with high dynamic range and negligible bias.
Meanwhile distance travelled is given by the average distance of the wheel encoders. I calibrated the wheel encoders to Google Earth, my waypoint editor, and found the error falls below 1%. So the robot knows how far it's gone and in what direction, giving a position estimate. The position is estimated in cartesian coordinates which I did for one very good reason: updating the position based on the historical heading estimate.
If we know what direction we were pointing a second ago, we can not only update gyro heading calculations up to present, but, using a rotation matrix, we can update the last second's worth of position estimates up to present very quickly.
success comes after a less fortunate attempt in last years competition. However lessons learnt about the previous year's issues, months of simulations, testing, and analysis ensured a much better result in 2012 for Team Databus. Well done!