Coldwilson

I wanted to double check everything so tried things over again. First test: Swapped Master bricks: moved the remote Master Brick (connected to the slave Chibi) over to the pc and connected up to the master chibi and the pc Master Brick over to the slave Chibi. Didn't need to reconfigure the Chibi's as they were the same positions. Result: Connected up slave to power and master to usb on the pc. Brick viewer only shows the master brick. Second test: Swap Chibi's: moved the slave Chibi onto the Master brick connected to the pc and the Chibi on the pc over to the slave. Then reconfigured the Chibi's to master for the pc connected one and slave for the remote one. Result: it all works fine again. So here's the sequence of events from when you asked me to swap over Chibi's. to see the swap around I have marked M1 as Master Brick 1, M2 as Master Brick 2, C1 as Chibi brick 1, C2 as Chibi Brick 2. Where C1 above M1 is Chibi brick 1 on top of Master brick 1 connected. The left column represents bricks connected to the pc and the right being the remote powered stack. Step 1 is as it was before you asked me to swap chibi and step 2 is after I swapped them over. 1. C1 C2 original = Not working M1 M2 2. C2 C1 swap chibi's = Working M1 M2 3. C2 C1 leave top Chibis, swap master brick = not working M2 M1 4. C1 C2 swap Chibi's back, leave masters = working M2 M1 Conclusion from above is that it needs to be C1 with M2 and C2 with M1 to work. This config works when connected to either the pc or the remote. So both of the chibi's work in both master or slave positions (after reconfig) but it seems they must only be connected to their partner master bricks. If they have the other master brick then they stop working. It's weird but hopefully this gives some insight into the issue.

Yes, I meant the power supply brick to connect the other stack. As it happens I was also using the DC brick (motor driver) to test the stack alongside the IMU (to demonstrate it wasn't just an issue with the IMU). I used a standard transformer connected into the step down power brick.

Yes, got the short antennas on both chibi's. Wow, that final suggestion worked - how strange!! I swapped over the Master bricks and made current master the slave and current slave the master. It now works perfectly. Tried it with IMU and DC brick. Can see both in Brick viewer. I'm very pleased to see it working now but why did that make a difference?

I meant that I did the same thing you asked me in your last post. I have two chibi and two master with a master at the bottom and a chibi on top for each. So two stacks of master and chibi on top. I connected each one in turn to the pc to check their settings were as your example and they were. At the time I was getting 0db which was the first issue I had. There was never a data connection between the chibi though. Yes, I did take a look at that box and try to change things. It's not mentioned in the help guide - that must have been the cause. They're all set correctly now though.

ok, followed that precisely and only see one Master brick (the master) in the brick viewer. Signal strength at 71db.

I wasn't getting any chibi comms but now I am getting around 57db appearing. After retrying all connecting to the pc I found that I'd lost the slave settings somehow. What action commits the settings to the chibi memory? Perhaps I removed power before clicking disconnect - would that explain it? Anyway, now got the 57db signal showing and tried with the IMU and a DC brick both on latest firmware. Neither are showing up on the pc brickv viewer despite seeing the 57db. Python code still fails as well. I've tried moving the imu and dc brick above an below the chibi on the stack. The only thing I can't see at the moment in whether the chibi/master are getting signal as well as the one on the main pc. The remote one is just connected via the power brick to 5v so it's invisible. I'll connect it up to a separate pc later so I can see brick viewer in that module separately at the same time.

Tried the IMU stacked with both master bricks (chibi removed) and it works fine with both of them. It also works fine with both of chibi attached as well so long as it's connected via usb to the machine. It looks like the chibi aren't talking to each other - I'm guessing it should not read 0db?

Hi guys, I've installed latest version on BrickV and flashed two master bricks from 1.0.0 to latest version 1.1.3. I've connected up a chibi to each master brick with one connected to the PC and another to a dc brick for power. I set one chibi as master and the other as slave exactly as you've shown in your guide. I can confirm that each chibi is set right as if I plug each master into my main pc the chibi settings details show as I've configured them (and as you've provided in your example). So far, so good. I then connect the IMU up to the remote chibi/master stack, this IMU has been flashed to the latest 1.0.3 as well. When I have them both powered I take a look at the master brick on my Brickv on the main machine. I don't see the IMU appearing in Brickv but there's nothing in your guides to say whether we'd still see the bricks on the remote stack showing in brickv. However, I also only see 0db on the chibi and would have expected this to show something else when both are setup and powered on? I try to run a python demo for the IMU on the pc connected to the master brick but it fails to connect to the IMU device. Any suggestions? Thanks

Yep, that works now on both my VM and the standalone PC on windows 7 for both opengl versions. Thanks

Borg - you are an absolute genius, I modified your example code for IMU to run this above formula and set quaternion update frequency to 2ms for fun as well. just needed to add the line import math and change atan2 to math.atan2 and the PI to math.pi and it worked brilliantly. Now it gives me perfect accurate results. There's no gimble lock issue and it goes around from 0 to -180 degree clockwise and then +180 back to 0 as I continue around clockwise to the start again. I was delighted to see that it also gave the exact same result despite whatever orientation I had the device set at so it would show accurate yaw position even on very rough terrain. Your last note has blown my mind somewhat at the moment but I'll try to figure it out. It's not a big issue, there's lots of ways to tackle what I need to do. Those quaternions are very advanced maths. One day after I get my maze robot finished I'd like to have a go at a quadrocopter robot using the IMU. Perhaps it's time for 3D flying maze competitions?

Wow, that's great. Thanks Borg I'll give that code a try. Great idea on the sampling approach as well - I should have thought of that. So I checked out the brick viewer on my windows 7 PC and also on windows 7 via VMWare virtual machine on my mac. On the PC the opengl version was 4.2. I updated the Nvidia driver to the latest 295.73 but it made no difference (and didn't update the opengl version). If I press save orientation it makes no difference. The image very occasionally appears for a fraction of a second. On the virtual machine version of windows 7 it's running opengl 2.1 and it's working perfectly on that. While you're in a great problem solving frame of mind can you think of an easy way to do the save orientation (just on yaw) in python? I'd like the orientation to be set when I turn on the robot as the zero point. I can do it by basically using the get orientation and subtracting or adding it from the current reading to zero. I wondered whether there was a more system based way to do it so it thinks it's now calibrated to the new yaw position correctly? But don't see a function that does this specifically.

Hi guys, I've got my order in for the Raspberry Pi and now also got it all working great on the Beagleboard having moved to Ubuntu. The Beaglebone was too much of a technical challenge tying to get it working on Angstrom for me. So I see that Raspberry Pi will have Fedora and probably others over time and I know you're looking to get one as well. When you get your hands on one can you confirm that the packages needed for your bricks (things like like Python-gudev, Python-twisted, and your brickd packages) all work with the base build? Thanks

Love the IMU concept but have a couple of problems I hope you can help with. 1. I've downloaded the latest brick viewer but when connected to the IMU the image of it appears for a fraction of a second and then vanishes. The background is just black most of the time. Occasionally it flickers back for a micro-second. I'm using Windows 7 - any suggestions? 2. I'm most interested in the yaw value at present (robotics purpose) but not getting expected results. The results are as follows: a - yaw ranges from 0 - 85 or 86 not 0 - 90 as expected. b - I thought it might give me 0 - 360 degrees but if align to the zero position and then spin it anti-clockwise it goes from the zero up to 85 (at -90degrees) and then back to 0 at 180 degrees and then to -85 at -270 degrees and then back down to zero at the starting position. 3. If I keep it perfectly still the yaw value will vary by 1-2 degree at times. I've tried playing with the convergence values and it's not improved the situation - temperature is pretty stable. I haven't tried calibrating as yet but I'd have thought that as it's stationery then the values would be a lot more stable.

Great, I'll give that a go.

That's great news, thanks. Any clues on where's best to solder to on the current board in the meantime? Thanks

Hi chaps, I have the DC power supply module and I know this can be used for powering the other boards. I have a stack with the DC board, the Master, two stepper. I also have most of your other boards. Powering this and the Stepper motors are 4 x 3.7v LiPo batteries so I use this in the Stepper boards and in the DC brick to feed the onboard power that converts to 5v. Is there a way I can get a 5v supply from any of this to power a beagleboard or Raspberry Pi? It needs to be no greater than 5v to prevent voltage overload. Given that the DC board has done the conversion I'm guessing it's accessible from somewhere. I think these controllers only use 1-2 watts. Thanks

Here's what I got: root@beaglebone:~/Tinkerforge-brickd-5afa1c2/src/brickd# python brickd_linux.py nodaemon Traceback (most recent call last): File "brickd_linux.py", line 30, in <module> from usb_notifier import USBNotifier File "/home/root/Tinkerforge-brickd-5afa1c2/src/brickd/usb_notifier.py", line 25, in <module> from libusb import usb1 File "/home/root/Tinkerforge-brickd-5afa1c2/src/brickd/libusb/usb1.py", line 52, in <module> import libusb1 File "/home/root/Tinkerforge-brickd-5afa1c2/src/brickd/libusb/libusb1.py", line 32, in <module> from ctypes import Structure, \ ImportError: No module named ctypes root@beaglebone:~/Tinkerforge-brickd-5afa1c2/src/brickd#

Ah, I can't install the Brickd software on the Beaglebone as your build are for Debian (.deb). I don't know how to make that work for Angstrom. Would it be easier if I just used C instead of Python (ignoring the harder coding). Would that avoid the need for Python-Twisted and Python-Gudev?

I found Gudev but not Python-Gudev for Angstrom. No idea what the difference is but all I was trying to install was Python-Gudev as I want to program in Python. Thanks for the link, I did stumble on that but I've absolutely no idea what to do with the files as it all looks like C to me. Can you clarify what the hot plug functionality is please? I would like to plug my Beaglebone's usb port into the usb of your Master Brick and have it run a python program (for a micro mouse) just as if it were a pc connected over a usb cable. When does the hot plug functionality get used? Cheers

Over at the following site there's an interview with the founder of Raspberry Pi. http://www.bit-tech.net/hardware/pcs/2012/01/26/raspberry-pi-modders-dream-machine/3 An interesting section to note is the bit about support on Ubuntu and Debian as quoted below: I guess people will find a way to have Ubuntu or Debian running on it but this is the first time I've seen an issue about it.

Wow, thanks for the detailed reply Borg. I'm at work at the moment so will look into this in more detail and reply on my findings. I am new to Linux so I can follow help scripts provided such as these http://elinux.org/BeagleBoardUbuntu#Demo_Image. I've done the installs (using the scripts) for both Ubuntu and Debian using these guides but I am unable to connect to the boards by USB or Ethernet after doing the setup. The guy who's written these (Peter Nelson) has mentioned that the Beaglebone images/kernal are still alpha so that might be the reason. If I had a Beagleboard I might have got further. So in answer to your question I haven't managed to get a command line up for Debian or Ubuntu to get far enough to do the package installs for the Daemon yet. It was easy, I got them all, when I did it using Ubuntu on the PC using Aptitude and a hunt around for Python-Gudev which isn't listed in Aptitude. As mentioned, I got further with Angstrom. It uses OPKG instead of Aptitude (same concept of course). It's library is far smaller. It had Libusb but not Python-Twisted or Python-Gudev. I did a lot of searches and never found a set of files for Twisted, some were version Arm6 and wouldn't install. I am not familiar with C and some sites don't make it easy for the newcomer to understand their files so maybe, as you suggest, there are files I could have grabbed that weren't so obvious to get it working. Still, your comments have inspired me to try again so I'll revisit my attempts with Angstrom. I can't make any further progress with Ubuntu or Debian on the Beaglebone as there seem to be too many bugs (at least for someone like me to resolve without better knowledge).

The issue I had with some of the installs was that they failed on not being compatible with the hardware (rather than Angstrom). They were Arm based just not right for Arm7a I guess. It seems that RPi is Arm6 so it has a better chance of success. Fingers crossed. If we have issues with it then maybe Tinkerforge will jump in to investigate. I can see the RPi being huge so it would make sense for them as it increases the chances of Tinkerforge adoption. Something I'm keen to see. If I get it hooked up together I'll post my discoveries.

Apologies if this is slightly off topic but it does relate to the questions around processor control for the Tinkerforge devices. I am having a nightmare with Beaglebone. It's got Angstrom installed but won't accept all the necessary drivers needed for the Tinkerforge Daemon right now. I can install Libusb, I can install 75% of python-twisted packages but python-gudev doesn't install at all. It seems that getting the packages for Angstrom are very difficult - they are easy to find for Debian and Ubuntu but whether they would currently work for the very new Beaglebone I'm not sure. I tested the installs for Ubuntu on my pc and it was very simple. As it was so easy I therefore tried to move to Ubuntu and Debian on the Beaglebone, however both attempts result in no ability to connect to the device via usb or ethernet. From some responses it seems that the builds for the bone are alpha so this might be the reason. I've been working on this constantly for over a week. My conclusion is that the Beaglebone is so new that support is no where near the level the Beagleboards have. I guess it's a case of waiting for some time to have the bugs ironed out by those who have the expertise to build the kernels, packages etc for the Beaglebone. I'll turn my attention to the Raspberry Pi when it arrives but I suspect it's going to have exactly the same issues with getting these three packages installed. I wonder whether I should give up on the Python interface and have a look at learning C instead and trying to figure out how to programme the onboard devices. I suspect this would be a learning curve well beyond me though. Any simple guidance on how to start low level coding the devices would be a help. A small example for instance.

I'm looking at getting a Beaglebone or Beagleboard to act as the micro-controller. It looks like you can then use it (if you know linux) to run the code via a usb connection to the master brick. Once I have it, learned some linux, figured out Angstrom on the board and tested out a connection I'll let you know how it goes. There are probably better ways to connect but this looks the simplest as a starter. Not sure whether there will be issues with timing though - only trial and error will tell.

Thanks for the clarification - that's useful to know.