PDA

View Full Version : BeagleBone Black - starting to play...



KurtEck
04-28-2013, 09:51 AM
Yesterday my BeagleBone Black arrived :veryhappy:

Now I need to figure out how to use it:wink:

I currently have it connected to my PC through a USB port, updated to the latest Angstrom release, am now able to connect to it using Putty and WinSCP...

Now I am trying to decide where to go next. That is, I am still pretty green with Linux. My main experience (that less than a few decades old) is with the Raspberry Pi, that has a complete different distribution of Linux. So far this does not have the things that I have used building the Phoenix code and starting with Rover code. Things like: sudo, apt-get, ...

So would others suggest tough it out using Angstrom? Or should I try to convert to a different distribution like Debian?
It appears that others have been able to do this, but it looks like it might be a bit complicated?
http://elinux.org/BeagleBoardDebian#Help

Suggestions?
Kurt

KurtEck
04-28-2013, 12:11 PM
Also side question:
If I need to build images for the Beagle Bone, would that be done on it or should it be done on another machine? If so, should I install some form of linux on my Dev PC to do something like this. If so do you recommend dual boot, Virtual Machine, or Virtual Box? Debian? Ubuntu?

Thanks again

jwatte
04-28-2013, 06:30 PM
Building images is usually faster from a fast pc; should be the same for the bbb.
My preferred distribution is Arch, as it lets me put in only exactly what I want. Arch exists for raspberry pi, so should be possible to get for bbb.
For Linux on regular pc, I use vmware workstation. If you can find a machine image somewhere, vmware player is free.

KurtEck
04-28-2013, 10:51 PM
Thanks,

I will take a look at this, playing around some. I had my raspberry pi version of Phoenix code compiling minus sound stuff. Then tried to updat packages by,

Opkg update
Opkg upgrade
Got wierd errors and failed to boot.

So used microsd which reinstalled to latest build, did the Opkg stuff again, same results... Reinstalling again.

Did search others have had issues before...

So may try different install.

Edit: Found some posts about having some success after adding some stuff to /etc/hosts
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/260496.aspx (http://e2e.ti.com/support/arm/sitara_arm/f791/t/260496.aspx)

Actual link above fails?
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=17&ved=0CGIQFjAGOAo&url=http%3A%2F%2Fe2e.ti.com%2Fsupport%2Farm%2Fsita ra_arm%2Ff%2F791%2Ft%2F260496.aspx&ei=OZ1-Ub2RJIyxigKtyIDoAQ&usg=AFQjCNFulz1r39VLVD_V9ASvIvcc9441Cw&sig2=1py7mN4UQTps7shfgfq-Og&bvm=bv.45836354,bs.1,d.cGE&cad=rja


I tried with what they had and got a ways, but still lots of failures added 2nd entry and reran opkg upgrade and fixed many, still did not boot after, so may try one last time with both entries and see if that helps


188.40.83.200 www.angstrom-distribution.org
140.211.169.179 feeds.angstrom-distribution.org


Kurt

KurtEck
04-30-2013, 12:11 PM
Note: I moved this thread to probably the correct forum...

First an update:
The above did not help the update/upgrade and the 3rd attempt also failed, so after having the SD Card automatically transfer the valid setup back to the onboard EEMC, I decided to hold off trying that again :genmad:

Since then, I have copied over my Raspberry Pi Phoenix sources (as well as the other directories) and after I disabled having the ESpeak and PCMSound code enabled, was able to build the Phoenix that runs on my T-Hex. Was also able to set up to automatically create symbolic links for an XBee and SSC-32 that currently connected by USB to Serial adapters... Code runs. Don't have any servos hooked up so did not actually see that part running, but did respond to commander.

I also moved over the mjpeg-streamer code that I has on the PI and compiled it and hooked up camera and it's working :veryhappy:

Next up: Try connecting up XBee and either SSC-32 or Roboclaw through the IO pins in the expansion header. Also need to setup a WIFI connector for it... Then will probably try it out to control my Orion Robotics 4wd rover...

One obvious question is Why am I trying this versus continuing with the RPI? The simple answer is because I am curious.

Things that the BBB specs that caught my eye included:
1) runs at 1mhz without overclocking. Also built in EEMC... Will be interesting to compare speeds.
2) I like the form factor. Don't have things hanging off in every direction... Also have good mounting holes so should be easier to mount on some of my robots.
3) Like the idea of more IO pins available. This includes 6 USARTS (Maybe only 4 are fully accessible), Analog input - I want my robots to know they are running out of power before the battery goes dead.
4) The Capes concept looks interesting, in that they look like they are trying to find valid ways for the system to detect them and configure to use multiple ones... Not sure if in practice it works, but...

Some of the things that concern me include: Currently I am not sure if there are very many people out there that can help out when I run into issues. Like what is going on with OPKG...

Maybe not as easy to get sound of it it...

Not sure yet if I will continue with the Angstrom version of linux... But one thing I do like is it does boot very quickly.

That is all for now.

Kurt

Grumpybeard
04-30-2013, 12:21 PM
Great update and progress there Kurt, thanks for sharing. Still awaiting delivery of mine - and next week start my rover build with the choice of rPi or BBB to make. Soooo tempted to start with the BBB for the hell of it, being all fresh, shiny and new, and perhaps more capable USB webcam streaming, so also great to know your cam is fully functional. Any info regarding FPS and noticeable lag? RPI really does have an amazingly huge user base on which to call, I hope the BBB proves a big hit to grow the community.

I hope I can contribute soon rather than passively read. Enjoy your new toy :)

KevinO
04-30-2013, 12:58 PM
Things that the BBB specs that caught my eye included:
1) runs at 1mhz without overclocking. Also built in EEMC... Will be interesting to compare speeds.
2) I like the form factor. Don't have things hanging off in every direction... Also have good mounting holes so should be easier to mount on some of my robots.
3) Like the idea of more IO pins available. This includes 6 USARTS (Maybe only 4 are fully accessible), Analog input - I want my robots to know they are running out of power before the battery goes dead.

Kurt

The three things you mentioned Kurt is what I was/am struggling with using the raspberry pi.

1) The Raspberry Pi cpu is hitting 90% - 98% when I'm doing any processing with the prime sense. I'm worried I might be capping the CPU soon. I might have to offload some of the post-processing to a desktop if this trend continues...

2) It took me a while to find good placement inside the PhantomX that allowed me to get to all the ports if need be.

3) I almost drained a lipo to low due to the fact I only poll the servos when they are walking to find out my voltage. It would be nice to have another check on the board itself via a analog input. Late at night lipo warning sensors are to loud and wake up my wife and son.

Thanks for the great update!

KurtEck
05-01-2013, 08:35 AM
Thanks guys,

Still trying to figure stuff out. Each of the IO pins are muxed to several different things (up to 8). All of the documentation shows ways to do the mappings of the pins. BUT the latest kernels decided to change how the pin mappings are done and none of the old stuff exists anymore. So far I have not found any good documentation on how to do it now. There are others up on the beagleboards trying to figure this stuff out too.

It is always fun to be on the bleeding edge ;)

Totally agree with Low battery and external sensor when I am playing at 5:30am... With the RPI on my T-Hex I am using LifePo4 batteries with 6.6v norm up to 7.2v. What has sort-of saved my butt so far is that the external ESC converting to 5 (or 5.1v) appears to not output a high enough voltage to keep the Pi running (or maybe the wifi) when the battery is down to maybe 6.4v or the like... So everything stops working. On the BBB I will be hooking this up probably to 3s Lipo so will want some way to keep from screwing them up.

Now back to trying to figure this stuff out.

Kurt

KurtEck
05-01-2013, 10:24 AM
Another quick update. I did another attempt at
opkg update
opkg upgrade

Also did the fixed IP addresses (not sure if that was needed)

Then after this did as much as it was going to, I did:


opkg --force-overwrite install kernel-image-3.8.8

(Found up on BeagleBoard.org forums)

It now boots. If you try to boot without doing this it won't, but looks like you can fix if you have a FTDI 3.3v cable...
http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%2520Support

Now back to figuring out IO pin mapping.

Kurt

bloftin
05-02-2013, 01:40 PM
Cool stuff - yeah I just got my BeagleBone Black in last night and got it up and running and controlling AX-12 dynamixel motors see

http://www.phys-x.org/rbots/index.php?option=com_content&view=article&id=102:beaglebone-black-getting-started&catid=41:kits&Itemid=70
(http://www.phys-x.org/rbots/index.php?option=com_content&view=article&id=102:beaglebone-black-getting-started&catid=41:kits&Itemid=70)

http://www.youtube.com/watch?v=O_EMc5umdDw&feature=youtu.be

I think I ran into a similar issue in trying to do the upgrade - it would fail to boot with the feed errors. I'll keep you posted if I learn anything.


Thanks,

I will take a look at this, playing around some. I had my raspberry pi version of Phoenix code compiling minus sound stuff. Then tried to updat packages by,

Opkg update
Opkg upgrade
Got wierd errors and failed to boot.

So used microsd which reinstalled to latest build, did the Opkg stuff again, same results... Reinstalling again.

Did search others have had issues before...

So may try different install.

Edit: Found some posts about having some success after adding some stuff to /etc/hosts
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/260496.aspx (http://e2e.ti.com/support/arm/sitara_arm/f791/t/260496.aspx)

Actual link above fails?
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=17&ved=0CGIQFjAGOAo&url=http%3A%2F%2Fe2e.ti.com%2Fsupport%2Farm%2Fsita ra_arm%2Ff%2F791%2Ft%2F260496.aspx&ei=OZ1-Ub2RJIyxigKtyIDoAQ&usg=AFQjCNFulz1r39VLVD_V9ASvIvcc9441Cw&sig2=1py7mN4UQTps7shfgfq-Og&bvm=bv.45836354,bs.1,d.cGE&cad=rja


I tried with what they had and got a ways, but still lots of failures added 2nd entry and reran opkg upgrade and fixed many, still did not boot after, so may try one last time with both entries and see if that helps


188.40.83.200 www.angstrom-distribution.org
140.211.169.179 feeds.angstrom-distribution.org


Kurt

bloftin
05-02-2013, 01:41 PM
I fixed it by reflashing via sdcard - took way to long will check into the ftdi fix too


Another quick update. I did another attempt at
opkg update
opkg upgrade

Also did the fixed IP addresses (not sure if that was needed)

Then after this did as much as it was going to, I did:


opkg --force-overwrite install kernel-image-3.8.8

(Found up on BeagleBoard.org forums)

It now boots. If you try to boot without doing this it won't, but looks like you can fix if you have a FTDI 3.3v cable...
http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%20Support

Now back to figuring out IO pin mapping.

Kurt

KevinO
05-02-2013, 02:41 PM
It is cool seeing more USB2AXs out there. I'm glad to see that went off without a hitch. It took me a bit of tinkering to get the Raspberry Pi to talk to the USB2AX properly. So for sound is it only HDMI out? Is there even a HDMI splitter that small enough for portability? I'd hate to loose the speech capability on my hex if I switched over from the Rpi.

bloftin
05-02-2013, 03:01 PM
Correct i only know of hdmi for sound output. there may be future capes - really who needs more than a piezo speaker with beeps and squeaks. If it is good enough for R2D2...


It is cool seeing more USB2AXs out there. I'm glad to see that went off without a hitch. It took me a bit of tinkering to get the Raspberry Pi to talk to the B2AX properly. So for sound is it only HDMI out? Is there even a HDMI splitter that small enough for portability? I'd hate to loose the speech capability on my hex if I switched over from the Rpi.

KevinO
05-02-2013, 03:20 PM
Well... :P Kurt and myself have speech on both of our robots. It is merely showboating I suppose. Mine says Good Morning, Good Afternoon or Good Evening depending on the time after power up. It also says a few diagnostic messages. For example when the servos start reporting lower voltage it announces that. After I am happy with the primesense vision stuff I was hoping to move on to using the mics built into the sensor for voice commands. So verbal acknowledgment there would be nice. I just wish the Raspberry Pi was a bit faster. :(

KurtEck
05-02-2013, 03:57 PM
Glad you got it! I have been playing around more with mine. Right now in the process of doing an eMMC-Flashing... Will then upgrade again.
Yesterday I received my FTDI 3.3v cable which is a good thing to plug into this and get the debug monitor. Allows you to recover some of the time.

As for sound I wonder if there will be a one of the IO pins we can tap into that feeds the HDMI plug.

May try building a microsd card with different OS on it, but still trying to figure out ways to talk to the IO pins. It looks like the main way now is through their scripting language ( bonescript). Most of their previous examples and the like don't work, but will continue to try. Did find a library that I think used mapped memory, which I will also try out.

Kurt

jwatte
05-02-2013, 04:00 PM
HDMI "splitting" requires HDCP handshaking nonsense, so that's not a good portability story.

The RPi has a headphone out jack which is driven by a low-pass-filtered PWM signal (as the SOC used doesn't have "real" analog in/outs) which you can use for computer speech.

KevinO
05-02-2013, 04:05 PM
Which is what we are already using on our Rpi robots. Kurt has a video somewhere of his hex talking.

KurtEck
05-02-2013, 04:13 PM
Yep as Kevin, mentioned on the RPI, I am using the headphone jack with small amplified speakers, which works fine for this. On the BBB, I get the impression the only sound output is part of the HDMI through an I2S chip...

As for the really poor video, it was on page 6 or 7 of the RPI thread.

http://www.youtube.com/watch?v=0GDh4SA9WQ4


Kurt

jwatte
05-02-2013, 09:31 PM
... so, on the BeagleBone Black, why couldn't you set up a PWM output with a RC filter, just like the RPi?
Does the BBB not have DMA or FIFOs for its PWM outputs?

KurtEck
05-03-2013, 10:23 AM
My guess is that should be possible. Hopefully someone soon will figure that out and come up with a sound driver that can be used by some of these packages like espeak...

Me, I am still just figuring out things like: how do I enable one (or more) of the Uarts that are on the P8/P9 connectors... Up on BeagleBOard.org Forums, the only clue I am seeing is that you may have to rebuild the kernel to enable them???

http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%2520Support

I am hoping that is not the only way! I would hope they would either have some configuration setting someplace and/or a set of APIs to update it on the fly..

Likewise still working on simple IO to other pins. I see a library someone did earlier that set up a memory mapped file to do some of the manipulations. Will try that out this morning. I have one of their prototype capes that have two LEDS that you can jumper in. So will try a simple blink program to see if what I think is correct is correct. That is all of the Pins are configured for Mux mode 7...

Kurt

jwatte
05-03-2013, 12:56 PM
I would think that building loadable kernel modules for each of the peripherals would be the way to go. That way you don't have to recompile the kernel. The kernel modules would need some way of negotiating usage of IO pins, so you don't load two modules that want to use the same pins.
I guess I had assumed that those basics were already taken care of by the fine folks as Texas, so it seems the system is in less ready state than I had hoped.

KurtEck
05-03-2013, 01:40 PM
What they have (at least defined), is a way for you to plug in up to 4 capes (shields). Each cape is supposed to have an EEPROM on it, which you use jumpers to say if this is your cape 0-3, which are used in the addressing of the EEPROM.

The eeprom is supposed to have some very specific data on it, which includes pin usage (2 bytes for each possible pin) and the like. Here is where they can define if they use the pin, R/W, PU/PD, RX Enable, Mux setting...

The question is, how do you do the same for prototyping? Maybe they have the same EEPROM data on the main board. So far I don't think it is, but worth taking a look

Kurt

jwatte
05-03-2013, 03:34 PM
I looked into that, and you can define "virtual capes" and just tell the system that those capes are loaded.
That causes the cape arbitration system to mark the pins as used/reserved.
That's a little bit less dynamic than I would have wanted, but it's not an entirely bad way to go.

So, there's multiple IIS interfaces on the BBB. IIS codecs are cheap and simple to interface. An audio cape cannot be too far off...

Tony
05-05-2013, 12:57 AM
Hoping you can help. I got my beaglebone black yesterday and decided to do a software update and now have the issue that it will not boot. Followed the instructions and created a an sd card with the image from 0413. When I power up the board with the boot switch pressed, nothing happens (none of the 4 led lights next to the Ethernet port turn on). Can't figure out what I am doing wrong. Any hints (sorry to bother you)? Thanks tons.

KurtEck
05-05-2013, 07:14 AM
No Problem,

I like probably many others are just limping along as well. As you can probably tell from this thread, I probably re-flashed the on board storage probably 5 times now. Several times I would be in the state you mentioned.

Hint 1: having a debug cable helps here as you can see what is going on and at times fix it. I believe you only need rx, tx, gnd, but must be 3.3v signals. I purchased the official FTDI cable from digikey...

Hint 2: More hints up on the Beagle forums:
http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%2520Support

Hint 3: I have not figured out the buttons in these cases. Some instructions say hold the one near the SD card when powering up... Others sayd it is the boot one... Other forum postings say if the SD card is bootable, it will always boot from it. So try a few different options and (hold one of the buttons power up). If still nothing, try the other button and power up. If nothing try with no buttons.

Good Luck.
Kurt

Tony
05-06-2013, 08:24 AM
Hi Kurt. Thanks for all the tips. I got it to boot from sd finally. The first problem was my img was wrong.

I found that by holding the switch down (closest to usb port) when I put on power caused the leds to start lighting up in about 8 seconds and I was good to go. It took a good 50 minutes to load the Angstrom image so patience is good. Thanks again!

KurtEck
05-06-2013, 08:43 AM
You are welcome. Glad you got it up and running. Most/All of the tips came from others up on the Beagle Board, I just kept trying the different versions and the like until I got it up and running.

Now working on Building a Virtual Cape to try to enable ttyO1 and maybe ttyO2... Then hopefully back to testing with maybe XBee and either RoboClaw or maybe a servo controller...

Kurt

KurtEck
05-08-2013, 08:38 AM
Another quick update. I now think I have my virtual capes sufficient for my use right now. I have enabled two serial ports on the expansion connectors. Again warning these are all 3.3v pins so may require level converters for many things. However I may be able to use them directly for XBee and RoboClaw. I am still thinking I will start off with a Rover here, but could also go to the PhantomX...

Note: I all of the hard work for figuring out how to do these virtual capes goes to others. Lots more details in the thread:
http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%2520Support

And especially in the blog: http://blog.pignology.net/2013/05/getting-uart2-devttyo1-working-on.html

I updated my version of it to follow the comments in the update to the blog and made the changes, such that the virtual capes are loaded at boot time so I don't have to add them later with the echo to $SLOTS... I have included a zip file here with the updated files. My shell script there makes all three pieces and echos out the commands that you will need to do, to copy the files into the correct places...

Kurt

KurtEck
05-14-2013, 01:31 PM
Still having fun trying to figure out how to do stuff on the BBB. I finally have a test program that allows me to control two leds that connect up to pins on the expansion connectors as well as get the input from a button. I put more details about this including the code up on the Beagle forum: http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%20Support
(http://beagleboard.org/Community/Forums?utm_expid=6702460-6&utm_referrer=http%3A%2F%2Fbeagleboard.org%2FSuppor t%2FHardware%20Support)
Under a thread I created named: BBB - pinMode, digitalRead, digitalWrite, analogRead...
There is also more information in other threads, like a color coded picture showing the two expansion connectors with some details about how the different IO pins are configured. This is in the thread: Need GPIO help for connecting a button.
And again good details up on the blog:
http://blog.pignology.net/2013/05/getting-uart2-devttyo1-working-on.html

Next up I will start putting all of these pieces together and maybe have a Rover running with one of these, with 2 of the Uarts used to control Roboclaw (motor controller with encoder support), XBee. Will also put camera on it, plus would like to put Pan/Tilt on it. Not sure what I will do this with yet. Could be with a bunch of standard servos or could use a couple AX12s...

That is all for now
Kurt

jwatte
05-14-2013, 01:43 PM
Thanks for forging ahead! The BBB certainly seems like a "raw" release, with not very much software support yet.

bloftin
05-14-2013, 04:10 PM
yeah there really is a dearth of BBB specific information atm, but we should be able to leverage other products like the pi, BB, etc. I'm putting up every example I go through here:

http://www.phys-x.org/rbots/index.php?option=com_content&view=category&id=46:beaglebone-black&layout=blog&Itemid=81&layout=default

r (http://www.phys-x.org/rbots/index.php?option=com_content&view=category&id=46:beaglebone-black&layout=blog&Itemid=81&layout=default)eally we just need a one stop reference spot... also for GPIO how about examples for the PI that people have done like this

http://hertaville.com/2012/11/18/introduction-to-accessing-the-raspberry-pis-gpio-in-c/

i (http://www.phys-x.org/rbots/index.php?option=com_content&view=category&id=46:beaglebone-black&layout=blog&Itemid=81&layout=default)t certainly seems simple for user-space pin access, but yeah tree mapping if you want to reconfigure or even writing your own kernel module for interrupts seems a little tricky atm in comparison to something like Arduino :)

KurtEck
05-24-2013, 04:44 PM
I am happy and kicking myself at the same time. It turns out that my main problem was that I had the eth0 object working (i.e. had the ethernet cable plugged in), so while I could use different query commands like: /usr/lib/connman/test/list-services
to see the different access points, it would not make a connection and assign an IP address. Only when I got frustrated, and unplugged everything, replugged it in without the hard wired ethernet cable did it actually make a connection. So far it appears to be makeing it up each time I plug the board in, so I think that part is at least working.

Now it is time to put the pieces together and see if I can make the rover work!

Kurt

KurtEck
05-26-2013, 07:48 PM
Making progress :D

I now have the BBBk mounted on my Orion Robotics rover and it is connect up to the Roboclaw and XBee through expansion headers (no USB). Have the Wifi Working (most of the time). Although it may cut out after an hour or so ???

I have some simple rover code that is using Commander as input and have it working with the sticks and the like. Still lots more to do. Also wiring needs to be completed. Currently still powering the BBBk through wires to AC adapter. Trying to decide if I will power it from the BEC off of the RoboClaw or through anthter BEC.

For the heck of it I put a WIP update up on my Github Raspberry Pi project, that added first cut of Rover. Tried to make the code compile for both BBBk and RPI. Did that by adding testing for OSTYPE in makefiles, which implies you have to export it...

Next up do some cleanup, try to connect up to some of the PWM IO pins to run 2 servos for Pan/Tilt.

Kurt

KurtEck
05-30-2013, 09:05 AM
Not sure how much of this information is useful to others, but I am still slowly making progress. On the BBBk the only sound capability on the board is over the HDMI cable, which I do not want to do. They do sell a sound cape, but thought instead I would buy a cheap USB sound adapter, which arrived yesterday (http://www.amazon.com/dp/B002R33VWW/ref=pe_175190_21431760_M3T1_ST1_dp_1). Next up was to figure out how to get ALSA sound setup so I could compile in my code to play notes... On RPI, I would just do:
sudo apt-get libasound2-dev

But on the BBBk, could not figure out any packages to download that would give me the header files. So ended doing something
like:
wget ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.25.tar.bz2
tar jxf alsa-lib-1.0.25.tar.bz2
cd alsa-lib-1.0.25
./configure
make install
This made it such that I could compile my testPCM program, but still no sound. Figured out the default sound device is still going to the HDMI sound device, but could get it to work by instead passing: "default:Device" to the open. Probably still need to figure out how to properly configure to have the desired default device. Anyway with this my program is now generating sounds :)
However as compared to the RPI with it's sound, the output of data to the device is taking maybe 4 times as long. I think it has more to do with how the stream underflow/overflow recovery is happening... The particular call that is taking a lot longer is:
frames = snd_pcm_writei(g_PCMhandle, pb, cb);

From my debug outputs, I am outputting the same size buffers... In my code I have a simple subroutine MSound that takes a variable number of parameters, with the first being the number of notes. For each note, I pass in two values, milliseconds and frequency. Example from test program: MSound(3, 100, 2500, 100, 2250, 100, 2000);
On RPI the three notes come out right after each other. On BBBk now there is a noticeable delay, but at least I am getting sounds. May play with the code that generates the tones that up to some buffer size, if I am outputting multiple notes, generate all of them in the buffer and output all at once.

Next up may be espeak. Again there are no packages that I have found so may take awhile. Also may delay worrying about this and get back to adding rover functionality.

Kurt

P.S - I am also writting about the Rover stuff up on the Orion Robotics Forum: http://forums.orionrobotics.com/topic70.html

KevinO
05-30-2013, 12:57 PM
I'm following! :)

KurtEck
05-30-2013, 07:49 PM
Thanks Kevin,

I have now also been able to download and build a version of espeak, which I downloaded from sourceforge.com. It relies on the portaudio library, which I downloaded sources from portaudio.com. The build of portaudio (make install), put the libraries into the directory:
/usr/local/lib

Which did not load. Needed to define and export the environment LD_LIBRARY_PATH. Not sure if this is best to do in my own .profile
file or if I should put this (which I did), in the /etc/profile folder.

So far I have not been able to make it speak out of my speaker. I think part of the problem is I need to configure ALSA to default to my card.
What is the best way to configure ALSA? Use the file /etc/asound.conf ?
When I run the speak or espeak command I get lots of information printed out, like:

[email protected] ~/Espeak/src # ./speak
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.front.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM front
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.surround40.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround40
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.surround51.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround41
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.surround51.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround50
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.surround51.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround51
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.surround71.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround71
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.iec958.0:CARD=0,AES0= 4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM iec958
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.iec958.0:CARD=0,AES0= 4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM spdif
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.TI_BeagleBone_B.pcm.iec958.0:CARD=0,AES0= 4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM spdif
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream

Note: when I run espeak on a RPI I also get tons of stuff like this (plus sound). Any suggestions on how to configure Alsa/Espeak to simply output to one place?

aplay -L gives me the following:

[email protected] ~ # aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=Black
TI BeagleBone Black,
Default Audio Device
sysdefault:CARD=Black
TI BeagleBone Black,
Default Audio Device
default:CARD=Device
Generic USB Audio Device, USB Audio
Default Audio Device
sysdefault:CARD=Device
Generic USB Audio Device, USB Audio
Default Audio Device
front:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
Front speakers
surround40:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Device,DEV=0
Generic USB Audio Device, USB Audio
IEC958 (S/PDIF) Digital Audio Output


Now back to pulling hair out.

Kurt

KurtEck
05-30-2013, 09:02 PM
It Speaks :D

I finally got the right configuration to set the default pcm device. In case anyone else wants to know or I need to get back to it.

[email protected] /home/kurt/Raspberry_Pi/testPCM # cat /etc/asound.conf
pcm.!default sysdefault:Device
Still get tons of messages with espeak but it works... Also was able to get back to simply passing default to the espeak device!

Kurt

KurtEck
06-03-2013, 12:07 PM
On my Rover I would like to control a couple of servos for Pan/Tilt, potentially a third for rotate...

There are several PWM capable pins on the BBBk that I will probably take advantage of for this. To do this with their stuff is sort-of a pain in the ... using the Device overlays and the like, as the interface to this is through the file system.
First you need to enable the amxx manager with something like:
echo am33xx_pwm > /sys/devices/bone_capemgr.9/slots
Then you can get one of the IO pins enabled for PWM with something like:
echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.9/slots
Note the capemanager.9 may change numbers in different versions...
But after these two commands done, you end up with a directory like:
/sys/devices/ocp.2/pwm_test_P8_13.14
That has several logical files under it including:
duty (value in nanoseconds)
period (value in nanoseconds)
polarity (1 or 0)

Note multiple PWM pins are on the same logical unit which must have the same period. Note: the .14 will change for each machine so need to read directory or like to know which one it is.

So for there is at least person who wrote up a C++ library to handle some of this. I believe it assumes the pins were setup externally from the program. It can be found up at: https://github.com/SaadAhmad/beaglebone-black-cpp-PWM

Question: This library uses more C++ stuff than I am used to. That is when I was working, we shied away from using things like strings for performance issues (lots of Garbage collection). What I am curious about, is on these small linux boards do most people still shy away from this and do their own string handling and the like or should I just bite the bullet and embrace this...

Thanks
Kurt

jwatte
06-03-2013, 01:57 PM
we shied away from using things like strings for performance issues (lots of Garbage collection)

C++ is not a garbage collected language, so I doubt that was actually the real reason. Perhaps you were worried about heap allocations?

In very small embedded systems (approximately less than 64 kB of RAM, say) it makes a lot of sense to allocate all RAM and all buffers statically. std::string or std::vector or whatever are bad in that environment, because they use the heap. Heap usage makes it hard to prove that your code won't at some point try to use more RAM than is available.

Once you have "ample" RAM, whatever that means, the programmer productivity gains outweigh the cost of a heap. Additionally, once your static allocations get too big, just verifying that everything is using the right set of RAM is going to be more error-prone than just using the heap judiciously.

The truth is that, on modern boards with 256 MB RAM or more, you're very unlikely to actually use even half of that for "real" things. std::string is also nice because it's exception safe and stack safe -- when the instance goes away, the memory is freed, so you're less likely to forget to free the buffer than with something like strdup() or malloc().

Regarding performance: If string performance is a performance bottleneck for your computer, you're doing something wrong! My suggestion is to know what your performance critical sections will be, and make sure that you develop those using appropriate performance affordances; outside those sections, use whatever lets you write and debug the most robust code in the least amount of time. In the end, the profiler will tell you where you need to spend your precious programmer hours optimizing.

KurtEck
06-04-2013, 08:10 AM
Thanks,

Yep, I misspoke :o I did not mean garbage collection, but instead I do know that it is heap allocated.

Actually back then it was for PCs... Back then when we migrated code from C to C++ we were simply being careful as to not introduce bloat and unneeded slugishness... As you mention this still is important when small processors like a standard Arduino and the like. However with the RPI/BBk I now have quite a bit of more memory, thinking maybe it is time to change, which is why I was curious what others are doing now.

You are totally correct if a few extra memory allocations/frees and string copies is the downfall, there is something else seriously wrong.
I am more concerned about the performance of doing file system operations to talk to the servos, especially if I am going to do my own timed moves. For example, the code to write out the servo duty in NS, (unwound) looks like:


void SetDutyNS(const long & dutyNS)
{
m_dutyNS = std::min(dutyNS, GetPeriodNS());
if (GetRunStatus() == Enabled)
WriteDutyNSToFile();
}
void WriteDutyNSToFile()
{
WriteToFile(GetDutyFilePath(), ToString(GetDutyNS()));
}
inline void WriteToFile(const std::string & filePath, const std::string & value)
{
#if DEBUG_VERBOSE_OUTPUT
std::cout << "Writing: " << value << " to: " << filePath << std::endl;
#endif
std::ofstream out;
out.open(filePath.c_str());
out.exceptions(std::ios::badbit);
out << value << std::endl;
out.close();
}


So for each of these servos, for each set of the duty, it will open a path name with several elements (example: /sys/devices/ocp.2/pwm_test_P8_13.14/duty), do a write and close it. But then again maybe this will be a non issue, as with the Arbotix we are doing this with un-cached serial outputs. And if it turns into a problem, could probably easily modify his code to keep the stream open...

I should just try it and find out!
Kurt

TXBDan
06-04-2013, 08:58 AM
I'm enjoying this insight into the BBB, too. It's REALLY appealing at only $45, but this is showing me that it may not be mature enough for me yet. I last ran linux about 12 yrs ago and i'm not super interesting in digging too deep into it at this point. I want to focus on making my robot move and interact with terrain.

jwatte
06-04-2013, 11:20 AM
I am more concerned about the performance of doing file system operations to talk to the servos

If that were an actual file, that would be concerning!

Reading the code, though, that's actually how you tell the hardware to update the duty cycle, so I don't know how you'd do it differently. Perhaps you can keep the file descriptor open and keep writing values? That would save some cycles, for sure, if you change the duty cycle often (like, to pose a PWM servo.) If you run at 120 Hz for 20 joints, that might actually show up in a profile.

If it is in fact the case that the only way to control a PWM servo is by opening a file, writing a text-mode value, and closing the file, then that interface is not designed by someone who cares about performance :-) You'd want an ioctl() to do the same using regular binary ints, and keeping the file descriptor open.

KurtEck
06-07-2013, 11:18 AM
Again you are probably correct.

There was an issue with their PWM test device, that did not properly allow you to set the frame rate of both channels on a logical device. So a member up on Beagle Boards created an updated version that allowed that to work. So I updated my main dev machine to have the Ubuntu 13.4 and built the kernel with this chance, such that I could get the updated device pwm_test.ko. Plus built his special copies of the Device overlays for these pins, which initialized them to a state that allowed you to update properly...

SO now have test program using his library code, that should properly pan two servos. I have not test it yet with actual servo, but looks good with LA ;)

Now on to actually patching up some wiring to two servos and see if it works... Or than again maybe look at one of those faster processors :lol:

Kurt

KurtEck
06-11-2013, 09:52 AM
Been playing around more lately getting better working version of the usb network adapter. I think this one is working pretty well now.

Also have updated my rover program to enable the Pan/Tilt code to use the PWM and it is working :) I took a Lynmotion Pan/Tilt off of my Tri-track and it is sitting loose on top of the Rover. Still need to work on making it fit and mounting camera on it.

Quick Linux question: Any recommended way to save/read configuration information? Example: I have code (not enabled yet) in the rover that allows me to adjust the zero points for the pan/tilt servos. Would like to store these values somewhere. On other platforms, I may stash the data into an EEPROM on the board. But not sure if that is a valid approach here. On a PC, would store the data in the registry. Not sure here. I do see a lot of configuration files littering the file system. Some in the user home directory (usually starting with a .) others stored in places like /etc/... Many of these are text files that have file names that end with .conf. Question is there a standard c/C++ library that you use to read/set these values. I see a few things bouncing around like a boost\property tree library.

Thanks
Kurt

tician
06-11-2013, 10:34 AM
For linux, there is pretty much no real standard format for configuration files. There are xml and yaml readers in opencv, the DARwIn-OP uses minIni for cfg files, and you could always just roll your own configuration file using plaintext or binary. IIRC, python also has an xml parsing module as one of its standard libraries.

The location varies as well, but most get placed either in a folder specifically for the program in /usr/share/ or /etc/, or in the home folder (or sub-folder) as a hidden file (usually just the program's name and 'rc' or 'config' preceded by a period).

KurtEck
06-11-2013, 11:30 AM
Thanks,

That was what I was guessing as well. So for now I will do the simple write a binary file, with probably some configuration data structure. Probably with a version number at the start... Maybe checksum...

Thanks again
Kurt

KurtEck
06-12-2013, 06:56 PM
So Today I hacked up a Pan/Tilt/Rotate hookup to the front of my Razor rover (by Orion Robotics). I used several parts that removed from my Lynxmotion Al5D arm, which wa not getting used. This included a heavy duty base rotate, as well as the heavy duty wrist rotate For a quick and dirty mounting of the camera, I mounted the camera base in between two plates of the gripper unit. This is obviously a real hacked up version, but at least I can play with it for now...

Still need to work on the power wiring as I currently have the main stuff all feeding to a 2.5 amp 5v wall wart (except for the motors/roboclaw which is properly wired up.

So the current version of my Rover code (which is a real hack) uses 3 pwm outputs directly from the expansion connectors, plus I am using 2 USARTS from the connector for communications to the XBee plus to the Roboclaw. I have a small 4 port USB Hub with sound card, Wifi and Camera. Will see if I can power all of this directly through the power coming out of board or if I need to add power to the hub (has small connector for power).

As I said right now it is a real mess ;)

4799

Code such as it is, is up on github (In my Raspberry Pi project)

Kurt

KevinO
06-12-2013, 07:26 PM
What kind of distance are you hoping for with this guy?

KurtEck
06-12-2013, 09:47 PM
As far as I can ;). But for this round it might be nice to go a few 100 feet. At some point later, with probably different hardware, it would be great to go a larger distance with more autonomous control. Like maybe several 100 yards. I also have mixed feelings about extending my main wifi to cover that range. But for now having fun.

Kurt

jwatte
06-12-2013, 11:38 PM
Based on my experience, if that hub setup works unpowered with all those peripherals at all, you will have all kinds of intermittent problems. Powering a hub is the way to go with the RPi! It needs all the juice itself.

KurtEck
06-13-2013, 08:38 AM
You are probably right about the power. For sure on the RPi you could power almost nothing through the USB.

With the BBBk I also found if I powered it through it's USB power input (even with a 2.1 amp USB power adapter), it would not power the servos and the like. That is when I switched to the 2.5 amp wall wart plugged in through the barrel plug. So far it has worked, but I have not tried running the camera with it in awhile. What I have not investigated yet, is how the power to the USB host adapter works. Does the system actually monitor/regulate it it or does it simply route the 5v power that comes in from the power plug to it. If the later, not sure if it will make any difference if I instead Tee off from the voltage regulator to power the USB hub or not.

What I am also courious about with powered USB hubs, is if I supply power to the input power plug for the hub, is it the same as simply running power to the +5v pin of the input usb connector or one of the usb outputs. Or do they normally do their own power routing. My impression is the device driver at least knows something about the power as dmesg does give some feedback including:

[ 0.971458] usb 1-1: configuration #1 chosen from 1 choice
[ 0.971783] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 0.971905] hub 1-1:1.0: usb_probe_interface
[ 0.971919] hub 1-1:1.0: usb_probe_interface - got id
[ 0.971937] hub 1-1:1.0: USB hub found
[ 0.972261] hub 1-1:1.0: 4 ports detected
[ 0.972275] hub 1-1:1.0: standalone hub
[ 0.972284] hub 1-1:1.0: ganged power switching
[ 0.972295] hub 1-1:1.0: global over-current protection
[ 0.972305] hub 1-1:1.0: Single TT
[ 0.972317] hub 1-1:1.0: TT requires at most 32 FS bit times (2664 ns)
[ 0.972328] hub 1-1:1.0: Port indicators are supported
[ 0.972338] hub 1-1:1.0: power on to power good time: 100ms
[ 0.972740] hub 1-1:1.0: local power source is good
[ 0.972753] hub 1-1:1.0: no over-current condition exists
[ 0.972937] hub 1-1:1.0: enabling power on all ports
...

Still learning :)

Kurt

jwatte
06-13-2013, 11:54 AM
If the power comes from a computer, it's typically limited to 500 mA per port. Providing more would make it possible to "smoke" parts with defective peripherals, which is not a good idea.

The USB bus knows about the declared power requirements from the USB device descriptor. This has a bit for "can be self powered" and another small field for amount of power draw, which allows at most 500 mA draw declared. If a device declares a bigger draw than available on a port, the computer will not "enable" that USB device.

For wall warts, the cheap ones are probably only using a voltage regulator which may have overheat shutdown but not much more. Although in California, linear regulators are pretty much out, as efficiency standards require > 90%, which means switching controllers, which in turn are more likely to have built-in current limiting. How much the internals of the hub actually turn power on/off to devices, versus just plumbs through, is something I don't have good insight into, but I'd expect most "conforming" devices to provide some kind of overcurrent protection at a minimum.

ezex
06-16-2013, 02:27 PM
im following, thanks for posting

KurtEck
06-16-2013, 04:44 PM
Thanks,

Yesterday I did some power setup and split the output from the 3s lipo battery to go into two different switches. One goes directly to the roboclaw, which drives the motors. The second goes to a 3 amp BEC that was made by Basic Micro, that I then split the output, with one connector going to the BBBk and the 2nd going into the USB hub. It appeared to work. Still needs to be cleaned up. While doing normal playing around with the code, I am unplug this and plug in the wall wart.

Today I am doing another diversion on this. That is I have it working that I can use the MPEG-Streamer code on the rover and see the camera output using a webpage on my PC. Currently can use the Commander to control the rover including pan/tilt the camera. But made me wonder. If I using my PC to talk to it over wireless, do I need/want at that point use XBEE to control it. So right now playing with Sockets.

Currently I have a VB app I hacked up on the PC using the current socket stuff (winsock no longer there). I plug in a Arbotix Commander into my PC and tell the VB app, which Comm port it is, plus the TCPIP address of robot and port number. Currently running on the BBBk I have a simple Socket Server test app, that when it gets a connection and sends a string with the Date/time and then waits for the 8 byte Arbotix Commander packets and detects if they change and prints them out, which appears to be working. Next up to hack up code to detect this in my Rover code PLUS also in my Phoenix code base and try it out for both the Rover here and T-Hex on RPI...

Kurt

KurtEck
06-17-2013, 09:01 PM
Another quick update.

I integrated the socket code into my CommanderEx code base. There is #ifdef code around the XBee support as well s the Socket support.

I then verified that I can run my Rover that has the BBBk on it using either controller. I then downloaded my current BBBk code over to my RPI on the T-Hex and compiled it. While I was at it I added a signal handler to the Phoenix code base that currently if you do something like hit CTRL+c to exit the program it will trap it and if appropriate release the servos. I also verified that I could run the T-Hex RPI robot using the commander that is connected up to my Development machine using sockets.

I uploaded the current stuff up to Github including the VB app. Maybe later will want to have a replacement for the VB app that run on Ubuntu...

KUrt

KurtEck
06-21-2013, 05:24 PM
Not much progress on the actual BBBk today, but have been playing around with the VB application, to see if I could imbed a web browser into it that could display the actual output from the camera. So I played around some more with the VB app and have it working (limping) around. Here is an image showing output from the camera imbedded in it.

4830
I used the Pan/Tilt on the robot that the camera is mounted on and controlled it using the Commander that is plugged into my PC (in my case Com41). Note I have a listbox at the bottom of this, which should display any messages I wish to send back from the robot. Will probably add some more of this soon. Things like showing me the current voltage and the like.

Having some fun.

Kurt

P.S. - Forgot to mention that I currently have the robot sending back 640x480 images at 20 frames per second and I am currently
simply displaying a webpage that the mjpeg-streamer generated

KevinO
06-21-2013, 06:25 PM
Beautiful dog!

KurtEck
06-21-2013, 08:36 PM
Thanks, that is Clare. She is the older about 9 of our two collies. Next I will have to put up one with Laik who is our other Collie who is now just about year old.

Kurt

saumyagandhi
06-25-2013, 10:53 PM
Kurt,

I am new to the BBB and really wanted to use Servo motors for my next project. I have tried to gather some of the information out there on controlling the PWM and setting it, I tried it but it seems really difficult. I would like to compile the kernel from https://github.com/SaadAhmad/beaglebone-black-cpp-PWM.

Seems like you were get it to work. Can you provide details or a step-by-step list of how you got these to work.

Thanks in advance for all the help.

KevinO
06-25-2013, 11:38 PM
I'm not Kurt nor do I play one on TV but I glanced on that github and he has a great readme on how to compile the kernel and get it all running. Did that not work?

KurtEck
06-26-2013, 08:23 AM
There are actually about 3 different ways to build the kernel. I think I have done part of each of them...

I put some comments in my readme up on github project: github/kurte/Raspberry_Pi

Which included:


I am now playing with trying to have Servos supported directly on the Beagle Bone Black. There are several threads
up about enabling PWM support up on the BeagleBoard.org forums. Also a member created a C++ library for it, which
I borrowed the code from as part of my library. More details up on the
(https://groups.google.com/forum/embed/?place=forum%2Fbeagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity %2FForums%3Futm_expid%3D6702460-6%26utm_referrer%3Dhttp%3A%2F%2Fbeagleboard.org%2F Support%2FHardware%20Support#!category-topic/beagleboard/C2tzvRYk1Wg)

I have an updated copy of his library code included in mine plus a simple PWM test case, which enables two PWM pins and has
them pulse from 500-2500us pulses.

There are issues with the default test-pwm driver that did not allow us to properly initialize two pwm devices on the same
logical device. You need to update the compiled driver for this (/lib/modules/3.8.13/kernel/drivers/pwm/pwm_test.ko).
Likewise he created duplicates of the device tree overlays, that initialized the values to a state that allowed both
channels period to be set before they are initialized. They have names like: sc_pwm_P8_13-00A0.dtbo
which must be coppied into: /lib/firmware.

May upload some precompiled ones here such that you don't have to build the kernel to get them.

Since I did that, I have used this in my Rover code to control 3 servos, which I have wired up to the breadboard Cape. The rover code using this is also checked into the same github project.

I probably should soon make a backup copy of the stuff on my emmc and then do an update/upgrade and hope things still work. Or I was thinking of trying to update to the new 6/20 image for Angstrom and then apply all of the changes necessary to make this work. I have been afraid to try this as it may take a day or two to figure out all of the stuff I forgot. But this also causes me to update my Readme files to make it easier the next time I need to do it.

Will consider doing this soon.

Kurt

saumyagandhi
06-27-2013, 07:20 AM
Kurt,

Thanks for your response. I have the latest image and I will try and implement the C++ library.

Just in case it does not work can you tell me what version you are on. I may just downgrade and try again.

KurtEck
06-27-2013, 08:11 AM
For better or for worse I am in the process of udating to 6/20 image of the BBBk Angstrom. so it may take me awhile to get everything working again.

So far I have some stuff up and going again including:
Two uarts are properly configured.
Sound (PCM and ESpeak are rebuilt but not tested with program yet)

I have rebuilt the Wifi adapter and wifi is working again. Now working on the PWM stuff. While I am doing all of this I am trying to add more notes into my Readme.md file that is part of my github\kurt\Raspberry_Pi project. Hopefully in the next couple of hours will have the rover working again!

Note: I am working off of SaadAhmads notes for this. To find the right posting under the BeagleBoard.org forums, do a search for
"c++ pwm"

Kurt

KurtEck
06-27-2013, 08:50 AM
I think I have it working again!

For the PWM I used the instructions and the like from SaadAhmad github project:
https://github.com/SaadAhmad/beaglebone-black-cpp-PWM

Since we are still on build 3.8.13 of the kernel, I used his pre-built files.

I have updated my comments in my Readme.md file for the RPI project and hopefully things are working again. I was able to build my rover code base and when I connect to it with the commander was able to control the pan/tilt/rotate servos :D

Kurt

saumyagandhi
06-28-2013, 12:26 AM
Kurt,

I am going to try and follow the instructions there tomorrow and see how it goes.

Thanks for all the information. Hoping it works without any issue :)

regards,
Saumya

DaveAppleton
09-02-2013, 11:22 AM
Flashing

I have been struggling to get the BBB up nicely but I have found a few things

to re flash a lot faster,

follow the debian instructions for creating an SD card but add an image for Angstrom and use xz to flash it to eMMC

Pretty much follow these instructions :
http://learn.adafruit.com/beaglebone-black-installing-operating-systems/flashing-the-beaglebone-black

but use the latest image. Problem is that the image comes with gnome. C'est la vie. Wanted Console really.

opkg upgrade failing

set a dns server - e.g.

echo "nameserver 208.67.222.222" >> /etc/resolv.conf
http://www.abelectronics.co.uk/adcpi-beaglebone-black/info.aspx

This post states that the ip above and 208.67.220.220 are public DNS

Otherwise I found that if I used the DHCP provided dns, it got lost halfway through.

Still not 100% upgraded properly. Had errors with bonescript but nearly there...