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/
I got an email from ARM saying that they had reconsidered and that they would not be sending me the student version. I have reconsidered my position of thinking the people at ARM are not tools. I did more poking around in the builder scripts, I think that just the ADS kit wouldn't be enough. I think that it also requires Codewarrior's toolkit to be installed as it references CW activex components.
Re: the multiple serial ports. I was planning on using the i/o ports on the arduino, not the rs232 programming interface. I don't believe the SPI or MCU lines are rs232 level. Correct me if I am wrong.
re: ADS 1.2 not available
Bummer. It would be better if someone (*ANYONE*) could build the project from the WowWee 'source' release. It makes the 'source' release even more of a joke IMHO.
BTW: I do have CodeWarrior (Palm edition) and it can export projects, but it gives little more than a source file list. We are missing the actual compiler, linker and libraries used. Once again this is because core source is missing, which prevents a complete source rebuild (and makes the release tied to the ADS 1.2 system)
The Arduino signals are all 0->5V or 0->3.3V level (depending on the Arduino board). When I say "RS-232" I mean that protocol, not the voltage levels, aka "USART". There should be no need for level shifters for this or the SPI signals. I think/recall? the Rovio uses 3.3V levels (but check that to be sure), so use a 3.3V Arduino to make it easier to deal with (but slower clock rate)
According to my scope it seems to be 0 - 3.3V Levels with idle RX/TX level = 3.3V.
I see cyclic transmits From Rovio at 9600 bauds, packet sent for 23ms with immediate response from MCU same length, all is repeated every 200ms.
Bus looks idle for 150ms/200ms.
So may be 1 Serial port + 1 IO to mux TX/RX is enough, muxing would avoid new packets to reach MCU and cause pb.
Hi I sorry my bad english
I want to ask if you can change the main program Rovio through the eCos code, to have different functions
I hope you can help me greetings
Short of direct I/O via URLs, no. The eCos code is too nerfed to get it to compile.
haya, what would be cool is if you could controll rovio wit a 3 axis joy stic e.g thrust master. where you could controll the left right turn/spin with the twist axis and fwd back side to side with the oter 2 axis. is there any way you could upgrade rovio comander II to do this?
Has there really not been any further progress on this since June?
Really no. I can?t programming rovio trought eCos, I use the API for programming but is limited
Sorry, my bad englist
Short answer is probably 'dead end', The code is not sufficient to recompile the firmware as it requires a special compiler to be able to link to some libraries (available as binaries only).
This compiler is not available anymore.
Reverse engineering would take long time.
Easiest way to do onboard stuff IMHO, may be to patch firmware live and intercept some APIs.
Apparently between 0.5M to 1Meg is available for extra code.
If like Chris said, to patch the firmware and intercept APIs work, then it is also great.
Anybody try to write some new functions, patch it to firmware?
finally got some time to do a proof of concept, i'm compiling c code to ARM and poking rovio RAM to make it blink blue LEDs left to right on periodic timer.
Quite fun to see the Rovio do things on its own, currently not much and only when off the dock as LEDs are forced to solid state when docked.
I've pushed my stuff to github so others may surely do more usefull things:https://github.com/chris75/rovio-hack
I had ADS 1.2 installed. I ran the IPCam_Builder.hta, it opened up ADS, did lots of compiling and finally, showed a message build complete. It also automatically ran and pre-populated FirmwareMaker.exe.
Now, I have bin file. But I am not courageous enough to flash my Rovio. I live in Bangladesh. I faced lots of hassles to get a Rovio inside our country. I just unboxed it last night. It seems too risky to me to flash the Rovio with the bin I built, as there is no clear instruction or confirmation from WowWee.
In this scenario, I am asking for some information from the Guru's here. In case I flash my Rovio with my bin and the Rovio gets corrupted or becomes a brick, is there any way I can restore it? Note, if Rovio is not running, I cannot connect to it via wifi to reflash it with bin from WowWee.
Any suggestion will be highly appreciated.
how did you get ADS 1.2? I searched the WEB and could not find were to
Guys from ARM Inc have discontinued it.
As of flashing a new firmware, from what I know everything relies on the Windond USB / flash chip.
If you plug PC USB on Rovio and power it up, Windond chip will enter a mode where Flash memory appears as a typical USB storage (2Meg).
So any block can be written using Rovio setup or Linux/Windows tools.
(Look at forums: Rovio technical - USB and firmware )
!!! BUT!!!! This is theory never did it myself as I've no other firwmare to flash, also not seen some reporting doing it.
If i were to test, I would use linux do a "dd if=.." and save initial image then use Rovio setup to flash a alternate firmware.
Then cross fingers and trust my solder gun and JTAG programmer.
I had an old PC with ADS1.2 installed, I was once involved in device programming, though not very much seriously. (Also, I found few links where people are selling *pirated* ADS1.2)
By the way, for the sake of proof of concept, anyone can send me modified firmware code, then I can build in my PC and send back the firmware. Then, you can try flashing your Rovio.
Is there anyone working in WowWee in this forum? Can he not confirm that firmware built (using ADS1.2) from the provided source code will not kill the Rovio? At least will not leave Rovio in an non-recoverable state?
ErfanOnline: I'm willing to try out your binary image on my Rovio... as long as it is the unmodified original build. I assume the image was created without throwing any errors. :-)
Chris75: there was some discussion last year on this thread about using the I2C port on the Rovio to talk to an external MCU. I2C really seems like a perfect way to extend the Rovio sensors and communicate results back to a PC. I say this because I2C is addressable, and any slave can listen on the bus, so API calls could in-theory address any slave that's listening.
Since most of the people wanting to modify the rovios are likely to have PC programming backgrounds, this would allow many non-embedded programmers to create extensions to Rovio like Sharp IR distance measurement modules and compass and whatnot.
Find the image built from source code here
*NOTHING changed in source code.
* Built without errors (hey, if there were an error, the build would not complete!)
However, I have made following configuration changes in the hta (just to confirm):
1. Changed default ad-hoc network SSID from ROVIO_WOWWEE to CINEMIN_SWIVEL
If anyone tried this, please please let me know the results...
I'll give it (firmware) a try if i can.
As for i2c, i've investigated a bit the software part to send write_i2c / read_i2c
commands to control cam brightness (using values found by Gandalf).
I don't know where the i2c signals can be accessed in the rovio.
I probably need to open it again.
I started using the MCU serial lines doing a serial port breakout with a PIC.
But i2c is a good way too.
your firmware Works !
I booted up my Rovio then connected via browser and used Sesttings/System/Choose File to upload your Firmware.
Rovio rebooted just fine and even kept my Wifi/IP settings.
/GetVersion.cgi gave: Version = Oct 14 2011 11:32:01 $Revision: 5.3705$
I then uploaded original 5.03 Firmware and it worked just fine again.
Note: I initially tried to 'save' flash image under Linux using dd, I plugged Rovio USB on my Linux box then turned Rovio on. Rovio appears as a Winbond 2MB Flash disk. I saved the disk using: dd if=/dev/hdd of=rovio.img.
This worked fine. I did firmware update (with yours) and tried to restore using the rovio.img i just saved. This failed as USB disk appears to be readonly ....
SO! If a bad firmware is pushed, Rovio won't boot and upload fw would be unavailable.
Wowwee has a firmware updater, i guess it could be used to revive a bricked Rovio but I haven't tested it so be carefull flashing experimental stuff !
Paranosh, Thanks for the ADS1.2 link.