Migration to F4

Since I’m a lazy sort I took the easy way out and bought a unit that had enough memory to actually support an image of at least QCIF resolution. I found an easy to use board on ebay that came with all kinds of modules I could just plug into the F4 discovery and get going, even camera. So, I think this was a good choice since my main downfall is lack of time for development.

All of the code has been migrated over and is working as it worked on the F3. I only have one ADC though. I have actually made a few improvements to the code and protocol. So now I have more speed and 192Kb to work with.

On another note I do plan on getting this working then possibly migrating a version to the stm32 F3. I could still use the F3 with dma based off gpio to control the camera. I realize now working with the F4 yeah its great and will get me where I want faster, but its also 3 times as much, and the F3 could do everything I need given the right amount of memory.

Easy to use Java API

Somewhere along the line I decided to write code with full comments and extract everything that was OS based. I segregated and divided all objects into a format that only makes accessible to the user what they need. At one point I was convinced the bluetooth module was not working so I switched away from the android platform and in doing so confirmed the API works well in a windows environment also.

Basically this is how the API works.

1. Create a new “zBot” passing it an input and output stream. This makes it transmission medium agnostic.

   zBot = new ZBot( inS, outS );

2.  Then you simply wait for the bots state to be 2 or above meaning its ready. I will make this a enum soon.
3.  Then you can simply pull the values provided in the enum of “readValues”. For example this prints out all available vars, like adc, gpio, time etc.

   for ( EzReadVars rv : EzReadVars.values())
   {
   this.logI(“Var: ” + rv + ” Value: ” + zBot.getValue(rv));
   }

4. For the image you can either read out the bytes of the image or you can subscribe and get a callback when a new image gets pulled from the bot.

   while(zBot.getImageState() != EzImageState.Ready){}
   int width = zBot.getValue(EzReadVars.VideoWidth);
   int height = zBot.getValue(EzReadVars.VideoHeight);
   //int bpp = zBot.getValue(EzReadVars.v);
   byte[] pic = zBot.getRawFrame();

This is cross platform and pretty easy to use, but by far not done. I really want to tie down everything into enums and document everything. Then I’ll make an example for android, windows and linux and release those. This will give people everything they need to get started with the API.

Video in progress

I’m so tired of saying this. The video is by far the hardest part for me. I finally have good data coming out at 251×100 resolution at rgb 565. I dont know why the camera is set at this resolution, but through painstakingly slow testing I have found it’s at this resolution. This resolution is something I can work with at least for now. It might actually be higher than 100 but I stopped the dcmi transfer at 100 lines.

So now I’m seeing beyond that to the fact that dma spitting my image out usart while dcmi is spitting my image into the same memory does not seem to work. I think they are conflicting when they hit the bus. So I’m going to implement double buffering. To do this I have to add some code to the zbot hw code and add some code to the java side also. Basically it will take a pic on one side and when we send it an update it will fill the picture in the “other side” so this way we can pull image A then hit “update” then pull image B then hit update and so on. This way the unit is always taking a snapshot and writing it to the picture buffer we just received. This should not be too hard.

Here is a picture of color bars at 251×100 resolution that I pulled. At least now I can crank up the speed and start to get my actual fps.

Releasing this application so anyone who wants to control the robot as is from their phone can. Will post video once I can make a decent one.

This app only works with basic functionality to move and turn on lights.

ZbotWars

After thinking and thinking about what I’m actually developing and what I plan on attracting the market with I realize they don’t match up at all. Adding features that allow users to build a script of i2c commands that can be forwarded across the network to a chip on the other side of the zbot may be useful to some people, but not the majority.

I realize that I need to work only on the features necessary to meet my initial goals. Then I can add in all the neat features and sdk that will be used by others. So what are my initial goals ?

Initial Goals

• Fun game with zbots, like fps
• video
• easy to use, cheap

Things I have done that are not related to those goals

• I2C forward
• Java Service, subscription
• basically the whole client was for experimenting not games
• library in c#

I started to realize this when I was thinking about the usb “dongle” and how it would be better as a ethernet “dongle”. Then I started to think about how it would need to support multiple devices, etc. The cost of the “dongle” would be similar to that of the zbot, doubling the cost, not good. Then I thought about how the dongle could be the service and allow for the user to not tie up a “server” computer to host connecting to zbots. These aren’t the days of people configuring hard to use servers so their friends can play quake anymore. Just by having a dongle and server I’ve excluded a large number of potential users.

The solution ? Bluetooth and android, yes what I already knew a long time ago. I had abandoned this idea a while back because bluetooth was too short range and not fast enough at long range, plus it was a little pricey. But given the cost of a “dongle” I could basically have wifi, so if I want to keep the cost down a “dongle” is not the way to go, yet. Since I started this project (I think) there have been other bluetooth solutions created. These other solutions will give me about 1Mbps and about 30 ft of range. Not the best numbers but a good start. Aside from that they support usart so I would not have to change any of my current code.

So, I’m scrapping any goals not related to the immediate goals. There is just a Zbot and a app that runs on android phones. The Zbot will be a toy that you can use with your phone to fight with your friends, capture the flag or do missions in the real world. My development time should be about 1/10th what it was and we should see the goal much faster. Then after the initial goal, we add in the sdk, the features and the server / client model.

I’ve finally flushed out a protocol and got it working well. I rejected the crc because in most cases I wont be using it; however, I did leave all the code and the space in there to use it in case we need it later.

Now that we can read and write to the device across any medium (spi, usart, etc) I need to start adding the functionality to use what we read and write with the protocol.

I have also been researching wireless solutions and found several. I really like Nordic’s RF line but found another more complete (and cheep) solution on ebay from hoperf. The hoperf board comes with an antenna built in and all of the required components so all you need to connect is an spi interface. The ic is very similar in functionality to the Nordic chips. The cost per hoperf board is about $3 each. I ordered 6 of them. The speed I can get is 1Mbps and the range is about 60-90meters which is at least 200 feet.

Pushing my protocol to higher speeds I was able to get a throughput of about 150kbs. With 128x96px image @ 25k bytes I could get possibly 6 fps raw. I’m aiming for raw first once that whole system is working then I will work on compression. The idea is that later when the whole thing is working I will have 1Mbps so that will allow me a larger raw image, then when we still need more I can enable compression, but at that point I will already have a usable fun system. This is opposed to me working on compression for months like I did before and having no working system.

So
Motors, I2C, Wireless, Camera (raw 128×96), Circuit
is the priorities for now. And they are attainable within a short amount of time, I have already had all of these things working separate from each other already.

On to sprint2 !

I dont know why but revisiting it all of the usarts work just fine now so I’m steaming ahead with the stm link debugger. Finished most of the protocol. I can do read and writes to all global variables used within the stm32 program. The only things I have left are CRC and I need to make the java server poll the zBot as fast as possible and maintain a snapshot of its variables for sharing with a client. This is granted there is a client connected.

On another note I really like the nordic chips for a wireless solution. They have an “on air” data rate of up to 2Mbps. I’m still not sure of the range but if its the same as comparable ic’s its about 1000 feet which is sufficient for now. The cost is a measly $7, much less than a wifi solution. The only downside is I have to create a dongle to plug into the computer, but I think the cost and development offset makes it worthwhile.

http://www.mouser.com/ProductDetail/Nordic-Semiconductor/nRF24L01P-T/?qs=sGAEpiMZZMt%252bz66QWnul0XZ9nqKlGruUzD33zj574R0%3d

Few more days and I’ll be done with the protocol and then I think I’ll be on the camera again. I’m aiming for 128×96 raw at 10fps, I can rough that over a 250Kbps line. After that the skys the limit but that’s a quickly achievable goal.

Tried to switch over into the stm32 discovery that I bought a while back. I was looking for the added benifits of the built in st link debugger.

Turns out a few things are different between the two boards. I had to wrap several things in  #ifdef STM32F10X_LD_VL
// dont use more than 8k ram, change leds , gpio etc.
#endif

After getting all that to work I could debug but the usarts did not work at all, I even enabled usart3 and tried to use that. Tried hooking everything up to a scope and still nothing, it does not even output any data what so ever on the usarts.

Then after that somehow my source re visioning wiped everything back so all the stuff I did to make my code compile and run on the discovery was lost. Thats ok though I’m just going to have one project and add the needed changes when switching between boards. The hardest part will be setting the define and changing to the other startup.s.