[Noisebridge-discuss] Shouldn't we all hack something ?
h.zeller at acm.org
Wed Apr 2 18:38:06 UTC 2014
On 2 April 2014 10:14, Casey Callendrello <c1 at caseyc.net> wrote:
> On 3/27/14, 10:13 PM, Henner Zeller wrote:
> > <hacking>
> > Back to hacking. This is part of what defines NB and we should all do.
> > So after this way to long preamble, I am telling you what I am hacking
> > right now.
> > Over New Years' eve, I was playing with the Beaglebone PRU to generate
> > nice, realtime-clean stepmotor steps
> > https://plus.google.com/u/0/+HennerZeller/posts/HyDMSHRBBDH
> > Was easier than thought, and works quite well
> > https://www.youtube.com/watch?v=hIEY9077D64
> > Since that worked well, I designed a board together with Jake that we
> > call 'Bumps'
> > https://plus.google.com/u/0/+HennerZeller/posts/CS9fhJx9bpX
> > They arrived in the meantime (OSH-Park is has a nice quality!)
> > https://plus.google.com/u/0/+HennerZeller/posts/UVa9mFV6z1k
> > ... so hopefully on the upcoming weekend we'll find some time to
> > solder them together. For that, there is the plan to use Jakes 3D
> > printer/dispenser (he did a 5MoF on it) and dispense solder paste on
> > the board. For that I wrote a quick program to convert some KiCAD
> > output to GCode for doing the dispensing action. Here is the code for
> > that:
> > https://github.com/hzeller/rpt2paste
> > </hacking>
> > -h
> Oh, yeah, I saw your PRU code and got super excited! A friend and I are
> trying to build an autonomous RC car. We are using the raspi but I'd
> really like to switch to the beaglebone.
> A critical part of the project is the speed control. The input is a
> fixed multiple of pulses per rpm, and the output is a servo-style
> signal. I'd like to write a PID controller that handles this. Thoughts?
> Is it going to be a big pain? Pulses are at about 100 Hz. My idea was to
> put this in the PRU for more precise timing.
Yeah, that should be no problem at all. The PRU runs at 200Mhz so you have
a lot of time doing complicated things between pulses.
You can output stuff at ~20Mhz at least and read similarly fast.
In my case, I communicate with the PRU just with a little ring-buffer of
commands sent from the 'host' CPU, other than that, it operates entirely
independent and does not have any issues waiting for things on the host-CPU
(including pontential DRAM stalls, as it has its own SRAM); thus it can
create very precise outputs.
(it sounds like you more want to write a PLL not PID ?)
> That way, the Beagle CPU
> could handle the the vision side of things.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Noisebridge-discuss