Steve_ has quit [Read error: Connection reset by peer]
vagrantc has joined #beagle
SJFriedl has joined #beagle
PhotoJim has joined #beagle
rob_w has joined #beagle
otisolsen70 has joined #beagle
vagrantc has quit [Quit: leaving]
akaWolf has quit [Ping timeout: 258 seconds]
akaWolf has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 255 seconds]
florian has joined #beagle
Posterdati has quit [Read error: Connection reset by peer]
Posterdati has joined #beagle
Shadyman has quit [Quit: Leaving.]
Posterdati has quit [Read error: Connection reset by peer]
Posterdati has joined #beagle
Posterdati has quit [Read error: Connection reset by peer]
Posterdati has joined #beagle
buckket has quit [Quit: buckket]
ikarso has joined #beagle
demirok has joined #beagle
buckket has joined #beagle
nparafe has quit [Ping timeout: 244 seconds]
nparafe has joined #beagle
rob_w has quit [Quit: Leaving]
nparafe has quit [Ping timeout: 255 seconds]
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #beagle
demirok has quit [Quit: Leaving.]
ikarso has quit [Quit: Connection closed for inactivity]
otisolsen70 has quit [Quit: Leaving]
buzzmarshall has joined #beagle
vagrantc has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
ikarso has joined #beagle
sicelo has quit [Quit: Bye!]
sicelo has joined #beagle
sicelo has quit [Changing host]
sicelo has joined #beagle
florian has quit [Quit: Ex-Chat]
sicelo has quit [Quit: Bye!]
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Quit: Bye!]
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Changing host]
akaWolf has quit [Ping timeout: 246 seconds]
Pete90 has joined #beagle
<Pete90>
Hey guys, I'm trying to install some packages on my BB Blue, however the limited RAM causes the make process to break at 91%. I'm trying to install cmake but I don't know how the swap process would work. Trying to install on Debian 10
<Pete90>
Okay so I don't have to be concerned actually about too low memory?
<Pete90>
It runs make, then disconnects at 91%, like the terminal freezes
<zmatt>
debian 10 (buster) packages cmake 3.13.4 .. if that's too old for your needs then you can add the buster-backports package repository which has cmake 3.18.4 (same as debian bullseye (11))
<zmatt>
that doesn't sound like running out of memory
<zmatt>
https://pastebin.com/RTqQD1ss does look like it might be running out of memory, you'd need to check the kernel log to confirm this
<Pete90>
I'm not sure if its too old, I'm installing cmake because my build of ROS noetic keeps failing and I think that may cause it
<Pete90>
How to check kernel log?
<zmatt>
journalctl -k -n 20 shows the last 20 lines of kernel log
<zmatt>
if you want the newer cmake from buster-backports, you can add that repository by adding these lines to your /etc/apt/sources.list -> https://pastebin.com/raw/P0h0vhkX
<zmatt>
and then sudo apt update && sudo apt install cmake
<Pete90>
I'm not too worried about the version, just want to be able to build ROS
<Pete90>
How do I clear memory though?
<zmatt>
"clear memory" ?
<Pete90>
Like its incredibly congested to the point where that instruction took about a minute to give output
<Pete90>
I had to switch to serial because the SSH didn't work anymore
<zmatt>
please don't tell me you enabled swap
<Pete90>
Not yet actually
<Pete90>
But good to know I shouldn't
jfsimon1981 has joined #beagle
<zmatt>
then I have no idea what could be going on on your system... if the build has been stopped then the ram used by it is already released, and being low on memory on a swapless system shouldn't cause any slowdown anyway
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
<Pete90>
Okay nevermind seems to have reset itself, SSH is working again so I'll use that terminal
<zmatt>
there's no reason for an out of memory condition to cause an SSH connection to hang
<zmatt>
the kernel will just kill whatever process is using excessive memory (ld in this case) and that's it
<Pete90>
I dunno man, cloud 9 just disconnects
<Pete90>
Those line to add to sources.list, are they just appended?
<zmatt>
oh you're using cloud9, lol, maybe the kernel killed that too, nodejs tends to be a resource hog
<zmatt>
the order of lines in sources.list doesn't matter
<Pete90>
I'm only using it because of the convenient file tree
<Pete90>
Okay I'll add and follow the next instruction
<zmatt>
are there no binary packages available for ros?
<Pete90>
I have no clue, I've realised armhf is a bit of a pain so I tend to go from source on most ROS things, most are a struggle that's why I'm trying ROS1
<Pete90>
Can I just leave the progress made in the previous cmake or is it better to delete its directory?
<zmatt>
(ubuntu 20 is apparently based on debian bullseye, so there's a decent chance packages for ubuntu 20 will also work on debian bullseye)
<zmatt>
I mean, if it ran out of ram while building I'd imagine it's also using a lot of disk space
<zmatt>
and it seems unlikely there's a good reason to build cmake from source
<zmatt>
and even if you do, then apparently you'll need to cross-compile it from another machine anyway since evidently it's unable to link it in half a gig of ram ;)
<zmatt>
looks like ros has a package repo for buster armhf
<Pete90>
Personally what would you recommend? I have a project needing ROS for SLAM, I need to use OpenCV for a webcam and I'd like to use the PRUs for motor control
vagrantc has quit [Quit: leaving]
<Pete90>
Also to fully remove the previous cmake, can I just rm the directory or is there more to it?
<zmatt>
machine vision on an AM335x .. I'm sure that'll perform great :D
<zmatt>
yeah just remove the dir
<Pete90>
Doesn't have to be good, just has to relay the visual data, hopefully
<Pete90>
Okay previous removed, new installed, thanks for the help
vagrantc has joined #beagle
<Pete90>
zmatt: Would you recommend switching to Ubuntu 20, I haven't done any implementation there I there'll be a few adjustments to make so it can use the drivers
<zmatt>
ehh, ros-base appears installable just fine
<Pete90>
I'm running off an SD card so I'm gonna be saving these images as I make progress, already came pretty far with ROS noetic so I'm gonna try to finish that
<zmatt>
dunno what version of ros is in buster, probably not a very recent one
<zmatt>
using a debian bullseye image instead of debian buster would get you a newer version
<Pete90>
I'm not too fussy about the version tbh as long as I don't have to jump through a lot more hoops to get things working :') , if it can do SLAM, object avoidance and visual relay I'm happy
<zmatt>
like I said, bullseye is also what ubuntu 20 is based on so there's a decent chance that binary packages for ubuntu 20 will work on bullseye
<Pete90>
I'll definitely check it out, saw a guy on the forums posting about Ubuntu 20 and ROS
<zmatt>
as for what you'll be able to do in terms of machine vision on a BBB, I don't know... getting webcam images may already be a struggle, especially if usb dma is still disabled to work around a driver bug (dunno if that's still the case)
<Pete90>
Oh no, on which images is this? If I use a compatible logitech webcam?
<zmatt>
the AM335x was not really designed for video or heavy computation
<Pete90>
Eesh, I may need to make adjustments to my project then...
<zmatt>
that doesn't mean it won't work of course, but I wouldn't set my expectations too high
<Pete90>
Like initially a few failed, probs because of cmake not being there, but just this one failed
<Pete90>
I mean it isn't a primary requirement but it would be nice to have
<zmatt>
I have no idea what I'm looking at, and if it was untarring something then this read timeout sounds to me like it was just too impatient
<Pete90>
What I also thought, hopefully nothing important
<zmatt>
also, this looks like you're installing desktop GUI packages? oof
<zmatt>
I mean, I wouldn't say "nothing important", it obviously failed
<zmatt>
hence whatever you're trying to do here overall also failed
<Pete90>
Ohhh yeah I think I am... I went for full installation to ensure I have the tools I need
<zmatt>
it looks to me like this is a huge project to compile on a beaglebone, I'd personally be inclined to not go down this route unless I've totally given up on getting binary packages to work
<zmatt>
like, the most obvious thing first thing to try is just using debian's native ros packages
<Pete90>
I get what you mean, I'll see if the build works, and if it does I'll just save the progress image, and if it doesn't I still have time so I can definitely look at Debian 11 and the ROS binaries (if there are for armhf)
<zmatt>
well ros-base and ros-robot are installable on buster armhf
<zmatt>
on bullseye armhf as well
<zmatt>
afaik main debian packages (i.e. those packages by debian themselves) should be available on all architectures officially supported by debian (which includes armhf) unless the package is inherently architecture-specific
<zmatt>
*packaged by debian themselves
<Pete90>
Okay I'll try bullseye tomorrow, main concern is the PRU and motor use but it seems like thats solved in the forum link you sent,
<zmatt>
"solved" ? I'm not aware there was an issue to be solved
<Pete90>
Or maybe it was ubuntu, but the drivers had to be ported etc
demirok has joined #beagle
<zmatt>
you'd need an appropriate kernel, but obviously beagleboard.org images ship with kernels that have the necessary drivers
<Pete90>
DO I get the Debian image from that snapshot or should I use the most recent on https://rcn-ee.com/rootfs/debian-armhf/2022-06-10/ I suppose it would be bone-debian-11.3-iot-armhf-2022-06-10-4gb.img.xz?
<zmatt>
I'd stick with whatever is linked in the forum post
<zmatt>
probably
<Pete90>
Okay thanks
<zmatt>
note that both remoteproc-pru and uio-pruss drivers are supported in all major kernel series currently in use on the beaglebone (up to and including the 5.10-ti series), you can switch between them using a setting in /boot/uEnv.txt
<zmatt>
(which one is needed depends on the tools you're using to work with pru)
<Pete90>
Ohhh is that what that section means, which is preferred?
<Pete90>
Okay fair, guess I'll have to read up on it
<zmatt>
remoteproc-pru can't load binaries produced by pasm (the original assembler for pru), only ELF executables produced by clpru (the compiler toolchain)
<zmatt>
uio-pruss with the old libprussdrv C library only supported raw binaries produced by pasm, not ELF executables
<zmatt>
uio-pruss with my py-uio library supports both types of executables
<Pete90>
Ohh good to know, I was considering assembly
<zmatt>
yeah, pru was designed to be programmed in assembly
<zmatt>
the C compiler was an afterthought. it produces terrible code (partially because the instruction set was never designed to be targeted by a C compiler, although that doesn't excuse all of the braindead things I've seen it output)
<Pete90>
Eesh good to know, I'll need to sharpen my assembly but it should be better than risking it
<zmatt>
the rpmsg system for communicating with pru that's preferred by the same people who think remoteproc-pru is a good idea is also horrible and will destroy performance and deterministic timing
<zmatt>
the key difference btw is that with remoteproc-pru the kernel is responsible for managing pru and gives userspace very limited access (basically just asking it to load ELF binaries, run/stop, and exchanging messages via rpmsg)
<Pete90>
Giving me all the tips at the moment, thanks, I need to head out now, but thanks for the help today!
Pete90 has quit [Quit: Client closed]
<zmatt>
while uio-pruss allows pruss to be directly mapped into userspace, making it responsible to loading code and controlling pru
<zmatt>
and use shared memory for interaction
<zmatt>
ok
<zmatt>
ah he left
indigaz has quit [Ping timeout: 246 seconds]
indigaz has joined #beagle
dKaiser has joined #beagle
zjason`` has joined #beagle
zjason` has quit [Ping timeout: 248 seconds]
set_ has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
ikarso has quit [Quit: Connection closed for inactivity]