Those that have been around a while know I originally knocked up an iPhoneSRV proof of concept after which it has gone quiet.. mainly due to my current job workload.
 
Now with certain developments such as the iPad and iPhoneOS4 I've kick started development on re-engineering the previous code. It's made simpler by advances in the iPhoneSDK which will allow the existing complex threading to separate the UI and tcp/ip interface to be replaced by a much simpler system.
Due to added experience in terms of iPhone/OSX coding it'll get a revamp in terms of structure too..
The downside is that you will require iPhoneOS4/Snow Leopard and I can't release the source until that is released.
 
Obviously this will be uploaded to the GoogleCode site once in a functioning state although annoyingly the iPad isn't on sale here until summer according to a recent apple announcement..

The new technique works well..
 
Just as a teaser - the OSX application. Not that impressive but it uses the new smaller code base. If you look at the project window at the side you'll see just how small the new code base is (about 5 source files compared to the mass before).
 
large screenie here
 
With the SRV running on it's own WiFi network with a base station connected to the computer I get 8-10 frames/sec with 4% CPU on the laptop so I'd expect the 3GS to pull the same frame rate with the limit being the blackfin unfortunately. Lastly there's no memory leak caused by the inter-communication/state transitions.

Two more photos.. *mental note - update SRV firmware!*
 


 
I've also been updating the googlecode.. here
 
In terms of functionality it's currently beyond the previous iPhoneSRV version!
 
Next up currently is the joypad and motor control operations. Then it'll be a tidy up of the UI (as you can see there's a gap under the single, begging to be used.
 

It's May and I'm guessing that Apple may present iPhoneOS4.0 over summer. If that's right then I'd better get on and finish it
 
A tough week at last week (and a water leak at home) has meant little has got done. Now all that's resolved it's time to set a few goals - this week will be connection management week.

Quote from yvesB on 05/10/10 at 6:26am:

 
I'm going to tiptoe around the iPhoneOS 4.0 NDA here.. so please excuse the lack of specifics..
 
1. Multiple versions = lots of effort
The problem is that there's currently a wedge between the iPhone and iPad in terms of development - iPhones sit on 3.1.2, the iPad sits on 3.2. They are different and it would require device testing to detect them. I would love for them to rejoin and so I wouldn't have to worry about the variations between versions - I don't honestly know if this will happen in 4.x or not but that is my personal gamble for keeping up with the latest/greatest so that one code base could support both.
 
The open source nature of the project allows any developer to contribute to make the code work on both post 4.0 and pre-4.0 devices. Unfortunately I only have time/resources/effort to focus on the devices I have.
 
2. Simulator != device
The SDK simulator is well known to allow applications to use non-device supported functions because it links against the OS frameworks (it doesn't run the phone firmware for example). This means to actually get the code working properly requires the devices at the right iPhoneOS level. I found this out when coding the first iPhoneSRV. So even if I did code up for the iPad under a simulator, it's impossible for me to verify if the application would work on the device.  
I don't have plans to purchase an iPad for personal use - I have an iPhone 3Gs, a MacBook Pro3,1 and a MacMini. The MBP is faster than an iPad and is more useful thanks to the SSD. I don't have a 3.x device to test on, it's either 4.0 or 10.6.3.
 
Have I tried it on the iPad SDK 3.2 simulator? It does not work. The additional screen real estate would make a great SRV control device..
 
3. The ball and chain to functionality.
I understand that 3.1.2 would allow jailbroken phones and older iPhones to be used as controllers etc. I've not heard of a jailbroken iPad, nor do I assume that the current focus on Apple making their own hardware CPU bodes well for the jailbreak community. This would mean that (a) those users would remain on 3.1.2 or earlier, (b) limit the functionality that can be added on those platforms.
iPhoneOS has some new stuff that does underpin the R3 and R4 functionality I had planned. It's easy enough to make the code only available on compatible versions of the OS by making the different versions have different build targets. The incompatible code can then be tagged according to the build target.
 
 
So for the initial release of the new version, I'll continue to run with iPhoneOS 4.0 as it's what I'm geared up todo. After, that release is up and running, perhaps someone can create a 3.1.2 version of that release as we press ahead with R3 features on the roadmap.

Quote from yvesB on 05/11/10 at 7:02am:

 
No worries - if you code for 3.1.2 it's more likely to work than not but not having an iPad would cause issues. The sooner Apple resolve the split in iPhoneOS the better for both users and developers in my own opinon.
 
Quote from yvesB on 05/11/10 at 7:02am:

 
Yes.
 
The current code base is composed of:
* Common - classes that will work on both iPhoneOS and OSX. So the I/O and blackfin interfacing classes (rewritten/simplified). These are implemented using the basic set of CF/NS libraries that work on both.
* Snow Leopard - classes specific to OSX (ie NS... classes and Quartz Composer, rewritten/simplified)
* iPhoneOS - classes specific to iPhoneOS (ie UI... classes, rewritten/simplified)
 
It's worth noting that the GUI classes are conceptually slightly different between OSX and iPhoneOS although the classes may appear the similar (ie NSView/NSViewController vs UIView/UIViewController). I've tried to write joint OSX/iPhoneOS classes but the differences just don't allow for enough common ground for some reason or other.
It should also be noted that the map classes don't exist in OSX.. so that will have to be retrofitted at some point using web-classes.
 
So for OSX you have two options:
* Use the classes as you want in your own applications - reuse the common, or OSX bits as you want.
* User the plugin for Quartz Composer and then either use the library of pre-written components to make up your composition 'patch' or write your own plugins (which is very easy). The benefit here is that you don't need to write code other than the processing code.. as it's there for you already.
 
The good thing is that because the code is written for a low powered device it means it's efficient - even in OSX Additionally if you have an OpenCL compliant GPU you could use the GPU to process data using OpenCL within your application or as part of a Quartz Composer plugin.
 
I could release the Common/OSX side of things but I want to get a couple of known bugs ironed out.

Ok, for those that haven't been following the WWDC'10 today..
 
1. iPhoneOS is now called iOS.
2. iOS4 is released 21 June for iPhone 3G, 3GS and iPod touch. Free.
3. iPhone 4 is released July.. with a gyroscope in addition to 4x the pixel count along with a 5MP camera and video..
 
So iOS will be coming to the iPad too..
 
So I better get my skates on and get the bits and bobs sorted! I think I'll re-arrange the roadmap - focusing on the basics for R2 then moving onto the additional stuff as it goes.
 
Hmm the SRV has a rival! A programmable platform with camera, GPS, gyroscope, accelerometer and WiFi. Far too valuable and heavy to stick in a UAV though!

Nick, I noticed there is still no source on the Google code site for this.  iPhone 4 SDK has now been officially released, any ETA on releasing your latest project for SRV?
 
yvesB