Jump to content

Coldwilson

Members
  • Gesamte Inhalte

    26
  • Benutzer seit

  • Letzter Besuch

Coldwilson's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. ok, followed that precisely and only see one Master brick (the master) in the brick viewer. Signal strength at 71db.
  6. 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.
  7. 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?
  8. 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
  9. Yep, that works now on both my VM and the standalone PC on windows 7 for both opengl versions. Thanks
  10. 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?
  11. 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.
  12. 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
  13. Coldwilson

    IMU Values

    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.
  14. That's great news, thanks. Any clues on where's best to solder to on the current board in the meantime? Thanks
×
×
  • Neu erstellen...