Hi, Thanks for taking a look at my code!
The software I've written is not meant to be a comprehensive software package. There is a folder each for the CM-5 controller and the CM-530 controller. When these are compiled and uploaded to the respective controller, then when the controller boots up, it awaits a command over the serial port or for a button press on the controller, and then performs one of the motion pages (that have already been loaded into the controller memory with the Robotis software). There is also a folder for the Android project. This project is meant to be installed on an Android device (I'm using an old Motorola Blur) with Bluetooth capability, and when one of the buttons is pressed on the interface, it sends a command to the Bluetooth on the CM-5 or CM-530 and the controller executes a motion page. The CM5/CM530 controller software only implements serial communication with the controller, serial communication to the servos, reading and writing motion pages in memory, and updating the servo position information in memory 128 times a second and sending it to the servos. I agree that it is difficult to find anything that really walks you through the hardware and software from start to finish, and can't really easily tell you where to start. It may help if you give us an idea of what you had in mind for your project. I've decided to go in the direction of BeagleBone because it seems like the hardware is well documented and the processor manufacturer does a good job of providing documentation (though not for beginners) and examples. I had considered Raspberry Pi, but from what I've read, the manufacturer of the processor for that (Broadcomm) is very tight-lipped with their documentation. The Arduino and AVR communities also appear to have a lot of documentation, examples, support, and people willing to provide advice, as well as free software to get you started. TI (the maker of the BeagleBone processor) also have some free software available. Hope this helps. On Friday, May 1, 2015 at 10:22:55 AM UTC-4, o1bigtenor wrote: > 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] <javascript:>> 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] <javascript:>. >> 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.
