Greetings I am looking at robotic control systems for something I wish to fabricate. Downloaded the files listed earlier and I can see that they are programs.
Being a non programmer I may be missing something but I'm not seeing anything about the hardware used for control and the software looks a little compact to be a complete control system. Am I wrong in this assessment? If so - - - what am I missing? Are there other blogs or websites where I can find information on robotic control systems (hardware AND software)? I haven't been able to find too much information that isn't proprietary for hardware and precious little on software. Thanking you for listen and any pointers and/or information that you may have! Dee On Thu, Apr 30, 2015 at 4:06 PM, <[email protected]> wrote: > If you download the above project you'll find: > README.md - general notes on the OV7670 example > ov7670-cam/pru-ov7670-cape/kicad/ - KiCad schematic and PCB design > ov7670-cam/pru-ov7670-cape/releases/ - PDF schematic and gerbers > > I did not put buffers because straight connection works fine for me. But > for any semi-serous use you should put buffers between the OV7670 (2.7V) > and Beaglebone (3.3V). That said, the connection is straightforward: > > lcd_data0.pr1_pru1_pru_r30_0 <-> do not connect > lcd_data1.pr1_pru1_pru_r30_1 <-> XCLK > lcd_data2.pr1_pru1_pru_r31_2 <-> D0 > lcd_data2.pr1_pru1_pru_r31_3 <-> D1 > lcd_data3.pr1_pru1_pru_r31_4 <-> D2 > lcd_data4.pr1_pru1_pru_r31_5 <-> D3 > lcd_data5.pr1_pru1_pru_r31_6 <-> D4 > lcd_data6.pr1_pru1_pru_r31_7 <-> D5 > lcd_vsync.pr1_pru1_pru_r31_8 <-> D6 > lcd_hsync.pr1_pru1_pru_r31_9 <-> D7 > lcd_pclk.pr1_pru1_pru_r31_10 <-> HREF > lcd_ac_bias_en.pr1_pru1_pru_r31_11 <-> VSYNC > uart1_rxd.pr1_pru1_pru_r31_16 <-> PCLK > gpmc_advn_ale.gpio2_2 <-> CAM_RESET > > Regards, > Dimitar > > сряда, 29 април 2015 г., 19:36:33 UTC+3, Bill M написа: >> >> Greetings Dimitar, >> >> I can't thank you enough for the direction (I was afraid no one would >> want to slog through all that). I'm also interested in the hardware part of >> it. Are there any schematics for interfacing the camera to the board (will >> I need caps, resistors, voltage translations)? The few I have found online >> aren't completely clear. I may still go the OS route if the learning curve >> isn't too steep. I would still love to learn how to handle the PRU stuff in >> bare metal, though, so I need to get busier with the Starterware. Again, >> thanks for the help! >> >> On Tuesday, April 28, 2015 at 4:13:59 PM UTC-4, [email protected] wrote: >> >>> Hi,ov7670-cam/pru-ov7670-cape/releases/ >>> >>> The servo control sounds like a job for the PRU. PRU I/O is also >>> suitable for interfacing OV7670. Here is a rough but working example for >>> Beaglebone White: >>> https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru >>> . Note that the example loader uses Linux and uio_pruss driver instead of >>> Starterware. >>> >>> Regards, >>> Dimitar >>> >>> >>> понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа: >>>> >>>> Greetings all, >>>> >>>> >>>> I'll apologize for the big lead up, I just want everyone to know where >>>> I'm coming from. I also apologize if I posted this to the wrong place or >>>> reposted it. I'm new here and still finding my way around. >>>> >>>> >>>> I am considering getting a BBB to use with my Robotis robot kit to >>>> replace the CM-5 and CM-530 I've been using, and was hoping people here >>>> could give me help/advice/guidance, or direct me to those who can, as I >>>> have a million questions. I will start to list them here. Any help greatly >>>> appreciated in advance. >>>> >>>> >>>> I've already written firmware for both the CM-5 (which is Atmega128 >>>> powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You >>>> can see the source for these here: >>>> http://sourceforge.net/projects/bioloidfirmware/ Obviously these are >>>> bare metal firmware given that the extremely limited platform in both cases >>>> couldn't practically support an OS. I would like to port my code to the >>>> BBB. I want to stick with the bare metal approach, so I can go real time >>>> without having to use a patch for the OS or Xenomai, and since I won't be >>>> interested in a good part of the functionality of the board initially (also >>>> I'm kind of a big Linux noob). I have already downloaded StarterWare and >>>> started poking around. The big draw for me to BBB is the processor clock >>>> speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the huge >>>> memory (for the controllers I'm using now, we're measuring in Kb), and the >>>> huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So >>>> here are some of my initial questions: >>>> >>>> >>>> •Is anything special required to use the full 512MB memory? In other >>>> words, can I directly address all the available memory without having to go >>>> through any special procedures? Could I theoretically declare a really big >>>> structure (iike a MB or 2) or array and be able to handle it in code like I >>>> always have? >>>> •With the code I've written thus far, the servos are updated 128 times >>>> a second. I have everything for doing that interrupt driven. I have a timer >>>> fire an interrupt every 8ms that calculates the next servo target positions >>>> and creates a packet to put in a buffer that feeds the shift register of >>>> the serial bus. The serial bus is also interrupt driven. When the buffer is >>>> loaded, an interrupt is enabled that fires whenever the shift register is >>>> empty. Every time it fires, it loads the next byte from the buffer. If the >>>> buffer is empty, it disables the interrupt. Receiving bytes is handled >>>> similarly, firing an interrupt every time a byte is received to put it in a >>>> buffer and empty the shift register. This allows the packets to be consumed >>>> as quickly as the 1Mb serial bus can consume them. Could I do something >>>> comparable on the BBB? >>>> •My third, and heaviest question, is one of the main motivators for >>>> considering the BBB (and moving away from the above mention controllers). I >>>> would like to get into vision processing, so I would like to hook a camera >>>> (maybe two) to the BBB. I don't want to use the camera cape (since I want >>>> to be able to position the camera somewhere else on the robot). Could I use >>>> something like the OV7670 hooked up to some GPIO pins? I was thinking >>>> something along the lines of having one pin output a clock to the camera >>>> (along with a pin for power and ground), and then have an input pin for the >>>> HREF, VSYNC, and pixel clock, and have the pixel clock pin set to fire an >>>> interrupt that would read the input pins that D0-D7 from the OV7670 are >>>> connected to and push them into a big buffer in memory. I figure for a 640 >>>> x 480 RGB565 image at 15 FPS, it would be about 9MB a second, and even if >>>> every byte was taking 20 to 30 clock cycles to handle (I think each >>>> interrupt could be handled much more quickly than this), it would only eat >>>> up at most 200Mhz a second (I've seen some posts talking about using the >>>> PRU for doing this). Does this sound totally off the wall? What would I >>>> need to interface the pins from the camera to the BBB GPIO pins? >>>> >>>> I apologize for the long windedness of this. Like I said, I'm not >>>> really sure even where to start, or how applicable what little experience >>>> with ARM I already have is to this. Again, any help appreciated! >>>> >>> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
