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.
ok you guys are better at this then i am
1-cam the motors be reprogramed for front 2 motors to go forward/back when arrow presed(no moto endcoding)and stop when arrow released
2-rear moto only turn when arrow pressed (no front motor)
Here is an initial attempt at a makefile
For entertainment value one of the problems was
../../../../../Host/libeCos/include/stddef.h:64:20: error: #include nested too deeply
In file included from ../../../../../Host/libeCos/include/stddef.h:64,
The include search path had some problems.
Right now I am stuck at
../../../../../Host/libeCos/include/cyg/infra/cyg_type.h:433: error: stray '$' in program
extern unsigned int Image$$RAM_T$$Base,Image$$RAM_T$$Limit;
extern unsigned int Image$$RAM_D$$Base,Image$$RAM_D$$Limit;
extern unsigned int Image$$RAM_B$$Base,Image$$RAM_B$$Limit;
It looks like this is for some sort of search and replace.
scatter gather file?! This looks specific to ADS
The toolchain was built using http://hermann-uwe.de/files/build-arm-toolchain
Sadly, it seems RobosapienPet is correct. The juicy bits are statically linked elfs. Specifically, Host/libNS/lib/libNS.a
All the CGI and MCU stuff is in there (do a hex edit and you'll see what I mean).
Looks like we need the Host/libNS/Src hierarchy.
Edit: Upon further review, I may be completely mistaken about the CGI and MCU. Lol
I tried a binary hack based on the finding from the source code.
Note: this is to improve the brigtness of camera and it really works!
Maybe I posted it in a wrong place so no feedback so far. Please go here and have a try and let me know your idea:
RovioBrighter - brighter your Rovio!
I was poking around some more. Not sure if this has been mentioned, but the *.a files are archives that can be opened with a program called IZArc 4.1.
libNS.a has 4 elf binaries in it (mcu_cmds, ns_cgi, ns_cmds, ns_nav). The rest of the structure is a bit weird though.
EDIT: this is actually a compressed static library. It can be properly decompressed under linux with the command 'ar x libNS.a', which results in 12 .o files.
EDIT2: There is mention of a debug port, which could be interesting, I also found that the Rovio shows up as a virtual COMM port under windows that you can send commands to in HyperTerminal).
I've also gleamed a bit from the MCU, for example:
For turning on and off LEDs:
Changing the 3F portion of the parameters line:
^ Front of Rovio ^
20 100000 Right Front
10 010000 Right Middle
08 001000 Right Rear
04 000100 Left Rear
02 000010 Left Middle
01 000001 Left Front
00 000000 All Off
The MCU takes commands in the following format:
l length (not including self)
E Endian (II intel, MM motorola)
C command (io command)
P Packet (always 0x0001 in shrt)
D drive (always 0x0001 in shrt)
d direction (0x01 forward 0x02 backward)
l E E V V V C C C C P P D D d S p p
M M S H R T 1 1
This command is in motorola endian mode, version 100h, SHRT code mode.
Not sure why LEDs have a direction (1a), might be a command packet. the speed is the leds you want on. Found this in Host/LibCamera/Inc/MCU.h.
MCU report: 114D4D0001FF53485254000100010B000000
Battery report: 114D4D00010053485254000100010D000000
EDIT3: Looks like the board doesn't make pre tags monospaced.
You'll have to copy this post into notepad.
ARM is being kind enough to send me a 4 month student evaluation CD and licence for ADS 1.2. I had to jump through a few hoops over the last few days (For one they don't sell ADS 1.2 anymore. I also had to dust off my university alumni email address) but it was worth the trouble if it works. I should be able to do any exports that are needed to make it compatable with the GNU tools.
Yes the .a files are standard linux library archives (extract with 'ar')
It appears to be a multi-step build process.
For example "Host/libUSB/src/lubUSB.mcp" is a project that builds the "libUSB.a" library from source (vp_usb.c, a simple project in this case). The final build (CameraTest.mcp) links in this prebuilt library.
As mentioned, IMHO the most interesting robot control part is missing source.
I count 12 .o modules as well in libNS.a (extract with 'ar', dump with 'nm' to see symbols)
As mentioned we *could* reverse engineer these modules or make work-alike ones, but we shouldn't have to (libNS is statically linked to GPL code, so WowWee must provide source to that under the GPL)
re: eval version of ADS 1.2
If interested, please open all .mcp files you can find and export them as .XML (there are over 60 but you can skip the ones in the Samples subdirectories except for CameraTest).
Then try building the final CameraTest (using the prebuilt .a files). If that works, then try to build all the dependent .a files (open the dependent .mcp file, and clean build). If all is fine you should be able to rebuild the CameraTest.bin again (this time with recompiled sources, except the missing ones like libNS.a)
As for libNS, I don't understand why it should have anything to do with the MCU or advanced functionality of the Rovio. Seems like an odd place to put it. The Northstar stuff isn't even on the same port as the MCU. Plus the URL related stuff would make more sense being in LibCamera. Woowee might not even have the libNS source. Maybe we need to put some pressure on Evolution Robotics next?
I'll upload any exports I can once I get the package from ARM. I hope I can get everything to build. *Crosses fingers*
Once it is made GNU code compliant and the fans can build the bland-new image, can we set up an open source project and a group of fans to give new and exciting function to Rovio? If this will happen, I will defintly join to contribute.
RovioBrighter - brighter your Rovio!
I dumped libNS.a using command:
arm-none-eabi-objdump -t libNS.a
And it seems some Rovio specific stuff is linked in libNS.a for ex:
er_mcu_cmds.o, compiled from Host\libNS\Src\er_mcu_cmds.c contains functions like:
Quite confusing, but it seems some Rovio sources are missing.
So a GNU port will block on libNS.a.
I'm interested by a dump (makefile/xml or whatever) using ADS for some mcp files. I'm curious about options/calling convention etc... to see how far from gnu eabi it is and if cross linking is doable.