Great news: the whole Rovio code is available for download now. Get it here:
AWESOME AWESOME AWESOME.... Getting it now!
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:/Host/LibCamera/Samples/CameraTest/Bin/CameraTest.htm
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 boardshttp://picasaweb.google.com/IHeartRobotics/Rovio
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.http://www.iheartrobotics.com/search/label/Rovio%20Hacking
what do i need to download so i can look at code
You need to get :http://www.robocommunity.com/download/17502/Rovio-eCos-Code/
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.
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?
> 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 makefilehttp://github.com/IHeartRobotics/Rovio/blob/master/Host/LibCamera/Sample...
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:
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?http://www.evolution.com/products/northstar/software.masn
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.
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.
> I'm curious about options/calling convention etc... to see how far from gnu eabi it is and if cross linking is doable.
re: GNU EABI
(disclaimer: I've never used ADS before, but I have used CodeWarrior)
BUT according to this:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3633....
they added GNU binary calling convention compatibility *AFTER* the ADS 1.2 release.
Not wanting to be repetitive, but this problem would be easily fixed if WowWee followed the law. It took 18 months for them to come up with this incomplete release. It may take another 18 months for the source to the remaining parts.
I looked at decompiled Firmware code and indeed it's old arm calling convention ADS 1.2 codewarrior compiler looks quite old, won't be easy to hack.
This also means Woowee painted themselves in the corner having no more toolchain.
Won't be easy to GNU port things.
Probably easiest 1rst approach would be to allocate some RAM / poke new ARM code in it
and use some jump table / assembly to piggy back on some eCos code.
Interestingly I've found a few extra functions in LibIPCamera (function Config_MemDebug), accessible via URL, one is malloc you can try to allocate mem (and exhaust it :) using URL like:
Refresh until it fails and you'll get an idea of how much is avail on your Rovio. Mine fails after 900K
So idea would be to allocate via malloc , send arm code using write_mem API, poke some useless Web api to jump to new code, and invoke it to kick code.
New code would create eCos task and do things.
To get a very crude debugging output, i located the upper power led address / bits.
Its in GPIOB at 0x7ff00334:
Mask for green/red are 0x01000000/0x02000000
For ex you can shut off green/red with:
Change 3 (in 0x03) to 0/1/2/3, indeed led is refreshed by rovio so want stay in state you forced
(You should read_mem 1rst and do logical or with LED bits to get 'safe' value)
Ok so we have brigntness and power LED control now :)
I was thinking of placing an Arduino between the camera/wifi board and capturing the commands as they're sent. It might lead to some interesting mcu hacking.
We could possibly use this technique to send commands in the unused address space of the mcu to the Arduino and have them relayed after being processed for adding more i/o lines. This would be much more flexible than using the 'saucer' LEDs as improvised address lines. For instance, the LED binary enumerations for the saucer LEDs end at 0x3F, leaving 2 bits for addressing and 6 bits for data (or whatever). Maybe we could even do echo location off board?
don't know if Arduino has multiple serials, if so it
could be inserted between mcu/main board.
It could relay standard packets and capture traffic+process extended commands for extra IO.
Also I2C bus could be used, don't know if wires are easily accessible but this type of bus is easier to extend as one can only connect the 2 open drain lines + ground probably Arduino has example code to use open drain outputs+inputs to implement this.
I also found code to access MCU traffic, everything sent / received is apparently logged in a fifo buffer and can be read via:
It shows lost of WaWbWcRxRyRz to say abc was written and xyz was received.
re: Arduino as an addon device tapping the serial command port.
I agree, a great idea for extensibility.
> don't know if Arduino has multiple serials,
The standard Arduino chips/boards have only one hardware serial port (RS-232 compatible).
I don't recall the baud rate of the /dev/ser1 port, but assuming it is under 56Kbaud you can use a software solution for the second port. BTW: Don't use the SoftSerial library that comes in the standard Arduino package, look for newer versions that uses interrupts (goes much faster and works properly instead of busy wait; there are several versions floating around) eg: http://arduiniana.org/libraries/newsoftserial/