|Surveyor Robotics Journal|
Fri, 31 Aug 2007
Blackfin Linux now running on the camera board ...
So far, no major issues with the port. We are interfacing to the camera via the video4linux drivers, which in theory should allow us to support a variety of v4l-enabled applications. All of this has to be tested, but we continue to make good progress. We will be working on WLAN integration next week.
Now I wish we had a big stack of boards to send out, but that is in the works ...
Sat, 25 Aug 2007
live JPEG color capture now working ...
All of the core functions required by the SRV-1 have been tested and seem to be running properly on the BF537. We now need to lay out a modified version of the SRV-1 controller that interfaces the BF537 in place of the ARM7 to the motor controls, radio (Zigbee or WLAN) and other sensors, and then we need to complete the port of the complete set of SRV_protocol functions. However, there have thus far been no "show stoppers", so we have moved forward with a production run of BF537 boards and cameras.
Our best guess is that the new version of the SRV-1 will be available in early October. We haven't finalized pricing, but there will likely only be a slight price increase for the Zigbee version of the SRV-1, and the WLAN version with Lantronix Matchport should cost the same or slightly less than the current SRV-1 + WiPort expansion module. As mentioned before, we likewise don't yet know the cost for upgrade from ARM7 to BF537 for existing users, but we hope to make that very affordable. Just check back here occasionally, or subscribe to the RSS feed from the Surveyor Robotics Journal for automatic updates.
Tue, 21 Aug 2007
Got it !
The OV9655 camera is working. Once we got I2C access to the camera registers properly configured, it was just a matter of experimenting with register settings. There's still room for optimization, but we definitely now have a working interface to the camera. Color JPEG is next ...
Sun, 19 Aug 2007
In case you were wondering ...
We have moved Surveyor Robotics Journal content to the www.surveyor.com home page in hopes of keeping existing and potential users better informed on product development. In case you haven't visited here lately and are wondering about references to "Blackfin", take a look at some of the earlier news stories such as this to get some background.
In short, we are migrating from the Philips/NXP ARM7 processor to the Analog Devices Blackfin BF537 processor as the core of our robot controllers, and that transition is proceeding at an accelerating pace. There are some good reasons for this migration -
The transition schedule has not been finalized, but it looks likely that we will have production quantities of the new BF537 processor at the end of September or first weeks of October, and we are now working on the PCB that will interface the BF537 to the SRV-1 motors and other sensors as well as the Zigbee or WiFi radio module. As discussed previously, we will provide a migration path for existing SRV-1 users to the new BF537 controller in the same timeframe of offering new SRV-1's with the BF537.
The new BF537-based controllers will be software-compatible with the ARM7 controllers at the SRV_protocol level, so existing applications such as SRV1Console, Microsoft Robotics Studio, Pyro, Webots, Player, Roborealm, etc, should continue to work without modification. For those who are considering purchase of SRV-1's, we will continue to offer the existing ARM7-based controllers for a while longer, but will likely run out of inventory within 30 days. If you can wait, we would recommend holding out for the new version of the SRV-1. If you have any questions about this, email email@example.com.
Fri, 17 Aug 2007
Blackfin BF537 processor/camera ... another update
Port H GPIO is fine - some of our other initialization code was clobbering i/o port setup. Also, we have tested the processor card with a different camera (Omnivision OV9620), and it works perfectly, so we have verified that the camera interface on the processor board is good. As mentioned earlier, it looks like we have a timing configuration issue with the OV9655, so we'll try to track that down.
There are a few other i/o lines left to test (UART1, Timer 2 and Timer 3), but everything else on the processor card has checked out positive. This has been a good week ...
Blackfin BF537 processor/camera update
Some good news - u-boot is running, so we will get started on the uClinux port shortly. Also, I2C and SPI flash are working properly.
Remaining issues - we don't seem to be able to initialize the Port H GPIO signals, though we seem to be using the right commands. The BF537 uses Port H for GPIO or Ethernet, and our theory is that the Ethernet function isn't releasing the pins, but we are getting help from Analog Devices to track this down. Also, we still haven't figured out the timing issues on video capture. When the board first starts up, we get pictures like this:
but after a while, sync seems to get lost and the pictures look like this:
Now that we have I2C, we can access the camera controls. There are a lot of timing variables, so we're on it.
Mon, 13 Aug 2007
Managing technology transitions - the new Blackfin processor/camera
We continue to make progress in bringing up the new Blackfin processor/camera board. There is still some tweaking required on the memory timing, and we need to make certain the I2C and SPI interfaces are functioning properly, but we will hopefully work through those tasks in relatively short order. So far, we haven't found anything that requires changes to the design, but we won't commit to building a production batch of boards until those tests are complete.
Until we have signed off on the design and start building new boards, we won't be able to commit to delivery dates for the new hardware. In the mean time, we need to address a migration path for existing SRV-1 users who are interested in upgrading to the new processor and higher resolution camera, as well as potential new users who need to decide whether to acquire the existing version of the SRV-1 design, or wait for the new version without knowing exactly when it will be available.
One strategy might be to say nothing until we know exactly when new hardware will be available. This allows us to give more precise answers on availability, but runs the risk of creating unhappy users who are blind-sided by the technology transition. Another strategy is to share our uncertainty, which minimizes surprises, but also complicates the purchasing decision process.
Consistent with our tradition, we have opted for the "full disclosure" strategy. If our product testing doesn't hit any glitches and we don't have to go through another design cycle, that strategy will probably allow the smoothest transition. If we do run into problems, at least our users (existing and potential) are able to make informed decisions.
With regard to mechanics of transition for existing SRV-1 users, the mechanical base of the SRV-1 (treads, hubs, motors, Li-ion battery) will remain unchanged. There will be a new controller board that hosts the Blackfin processor / camera, voltage regulator, IR or laser pointer interface, back emf circuit, motor controller, and radio module. We had originally thought to just support WiFi 802.11 on the new controllers, but are finding that a number of users want to see continued support of Zigbee for mesh and sensor network experiments. So we are now looking at the possibility of providing sockets for both Zigbee and WiFi radios on the new controller. We will offer controller upgrades to existing customers, so if they want to use Zigbee, they would just unplug the Zigbee module from their existing robot controller and plug it into the new controller. Alternatively, they might order a replacement controller that includes the WiFi module.
At this point, the most likely WiFi module is Lantronix Matchport, though we still haven't ruled out the use of the Lantronix WiPort, which is physically smaller though somewhat more expensive. Longer term, we will be migrating to a lower-cost SPI-based WiFi module, but that could be 4-6 months out.
Anyhow, that is our current thinking. We welcome comments and suggestions via email to firstname.lastname@example.org
Thu, 09 Aug 2007
continued progress with Blackfin BF537 processor/camera ...
Most of our issues seem to be with memory configuration. It's still not quite right, but a lot closer than before ...
Fri, 03 Aug 2007
more progress with Blackfin BF537 processor/camera ...
Getting closer ... that's supposed to be a coffee mug with a Jaguar logo.
Thu, 02 Aug 2007
Blackfin BF537 processor/camera update ...
I know ... it doesn't look like much, but we're making progress. We have a working code development environment with JTAG (Section5's ICEbear). The processor's external memory seems to be working properly, and we have UART communications. It seems that we are pulling valid pixels from the OV9655 camera, though the sync is wrong and we need to get the I2C interface going in order to properly set the camera configuration.
I really like the BF537 processor - it's easy to program in C or ASM, and it has some very nice features, including the built-in camera interface.
To be continued ...