AWESOME AWESOME AWESOME.... Getting it now!
Categories: Rovio Development
Great news: the whole Rovio code is available for download now. Get it here:
Check out my blog: The WowWee Insider.
Very cool, thanks for this,
I will definitely take a look.
Michelle C, thank you very much! This all looks really good, it's like Christmas for many Rovio owners. There will be a lot of great new projects using the Rovio in the next few months!
Thanks again to Michelle C.
A big step forward. There are a few missing source code files, most notably the North Star system (libNS, done by Evolution Robotics). I will post a detailed list later.
Fortunately there are pre-compiled libraries (.a files) for the missing pieces so if someone can find an open source / free compiler that is call-level compatible with the "ADS 1.2" expensive tool, then we can work around this.
This is a big step forward, but not to let you off the hook: the Rovio is still not complying to the GPL even with this release.
IMHO: Having had some experience with Evolution Robotics, unless you have it in your original contract, I predict you will never get source code to that part (ie. Rovio will remain running illegal software until the end of time). I hope to be proven wrong.
To summarize: thanks for the big step forward. Great for people binary hacking the existing firmware. Still a few steps to go for GPL compliance so people can build a firmware image from scratch.
And for anyone interested, don't miss the file:
It gives a static call graph of the firmware image. Even without full source it gives you a pretty good idea of the parts of the system.
Thanks Michelle C.
I have one minor request, I am working on locating ADS 1.2, but it might be easier if you or anyone who has ADS 1.2 could export the project files as .mcp.xml or as makefiles.
"CodeWarrior project files are stored in an undocumented binary
format which cannot be parsed directly by an external utility.
However, CodeWarrior does allow the export of a project file as a
separate XML text file, which is suitable for parsing by an
external utility. mcp2make is such a utility."
Michelle, thanks, this is great stuff!
Looking through the code, I see there are API functions 'read_i2c' and 'write_i2c', which are called the same way as 'write_mem' and 'read_mem', used for the 'disable blue light hack'.
Anyone have a high resolution image of the MCU board?
My hope is that an additional MCU, ie, Arduino, can be hooked up to the Rovio and polled without any firmware changes required. One could add additional lights and sensors and call these through the standard web API.
Here are HUGE scans of the main boards
Looking at the schematics, it looks like the I2C lines are connected to the camera board, and chip select is tied to ground, so it might be difficult to patch in there.
It looks like the easiest way (overall) to connect the Arduino is probably going to be either pulling out the NorthStar board and patching into the serial interface there, or using a multiplexer and a GPIO pin to toggle the serial port between the Arduino and the NS.
If you are interested there is more Rovio hacking stuff here.
what do i need to download so i can look at code
You need to get :
Then unzip using the 7-zip utility you can find on sourceforge.
lockburn said: My hope is that an additional MCU, ie, Arduino, can be hooked up to the Rovio and polled without any firmware changes required. One could add additional lights and sensors and call these through the standard web API.
It certainly can be done... I already did it. I think there is a post or two about it in a thread around here somewhere. Basically, I used the ring lights (which can be controlled individually) as a data bus to communicate with an external ATMega128, which in turn controlled a several additional headlights. I did it as a proof of concept, and never got around to hooking anything more useful up to it.
RobosapienPet said: A big step forward. There are a few missing source code files, most notably the North Star system (libNS, done by Evolution Robotics).
We may not need it, assuming it handles communicating with the sensor, and determining paths (haven't actually looked at the released code yet). The serial communications between the sensor and the Rovio are not that hard to setup and decode or mimic, I've also figured out the math to turn the data back into a position (which matches with the one that you can poll the Rovio for). That just leaves paths. I'll dig into my files and see if I can pull out those details (milw should also have most of it).
If you can find the thread, I'd love to read some of the posts. I did some searches and came up empty...
I'm interested to see how the ring lights were controlled individually. Interesting idea using those as a data bus.
I seem to recall that no-one was particularly interested at the time, so I didn't go into detail (I did start writing an article, but never finished). this thread contain the details on controlling the individual LEDs.
Unfortunately it's only one way communication, and I can't recall exactly what I did to deal with docked behaviour (I think I may have used the headlight as a clock line, coupled with a special case for all lights on or off for docked behaviour). I did have a few idea's for reading data out but never got around to trying them out (and its been so long I've pretty much forgotten them all). This is one of the photos showing everthing hooked up.
This is all pretty much off topic though, so if you have any other questions feel free to pm me.
Wow it is great that the source codes are finally there!
Is the source code quite complete that a new complete bin image can be built on top of that?
RovioBrighter - brighter your Rovio!
> Is the source code quite complete that a new complete bin image can be built on top of that?
Not quite. See comments above. More details will come out as people try finding compatible tools and rebuilding it.
I consider there are 3 levels of conformance:
Stage #1) most source code, good enough to understand the inner workings and apply binary patches to the pre-built bin image. Not enough to rebuild from scratch. Examples: the I2C hacks mentioned above. Features can be added but as binary hacks (which we've been doing for some time now, but easier now we have the source code)
Stage #2) most source code, but some work arounds to get around missing pieces, and buildable with free tools. A new firmware image can be built, but not 100% from scratch. You should get a work-alike firmware image that should run more-or-less the same. Then you can add new features in the source code !
Stage #3) full source code and GPL compliance. Can rebuild from scratch. Since the original build relies on a non-free tool (ADS 1.2) the final firmware will not be the same, but it should run more-or-less the same.
I think we are currently at stage #1.
With some work and adapting the build process to free tools, and working around the missing source code pieces we may get to stage #2. I doubt we will ever get to stage #3.
Apparently ADS 1.2.x is based on Codewarrior 4.x so if anybody has a CW IDE may be exporting .mcp project files to Makefile is a first step (if it can open them).
Agree on stage #3 being probably out of reach. Rebuilding a patched one with extra thread would already be great.