Oh don’t be! My point was just that I’m sorry for not always posting the same information on both Lynxmotion.net and the Trossen forum. So I found it useful to post more details on my blog.
I just added your blog to my RSS feed… 
Great 
Hi,
I’ve been trying to add a serial IMU sensor to MorpHex. The code is pretty simple and its working fine on an ARC-32 with this code:
[code];*** ARC-32 + Razor 9DOF IMU AHRS code test program ***
;This program simply grab the serial stream from the IMU using Hardware serial, hserin.
sRoll var sword
sPitch var sword
sethserial1 h57600
pause 100
hserout 1,"*** ARC-32 + Razor 9DOF IMU AHRS code test program ***",13]
pause 10
main:
hserin 1,TimeOut,200000,[WAIT("!ANG:"), sdec sRoll, sDec sPitch]
pause 1
hserout 1,“Roll:”, sdec sRoll, " Pitch:", sdec sPitch,13]
pause 50 ;pause simulate phoenix code in process
goto main
TimeOut:
hserout 1,“Timeout”,13]
pause 5
goto main[/code]
As you can see I’m using hserin 1 (TX from IMU to pin2 on JP5/UART, BAP RXD), simply because UART 2 is occupied with XBee communication. I’m using SSC-32, so I’m not controlling the servos using HSERVO.
In my MorpHex code I’m using the same code within the controlinput sub. Using this line of code:
hserin 1,IMUTimeOut,200000,[WAIT("!ANG:"), sdec swXimu, sDec swYimu]But when connecting the IMU to the ARC-32 on MorpHex the servos go crazy and I can hear from the vibrating sound on the speaker (when it beeps) that the pins probably get corrupted somehow. The code seem to run more or less ok, since I’m able to monitor the IMU data through UART1. It’s funny, even when the IMU is turned off, the bug occur when connecting the TXD from IMU to BAP RXD.
I’ve also tried software serial. Of course that does not affect the SSC-32 communication, and the robot and code work fine. But for some reason the IMU readings get corrupted. So I can’t trust software serial either. Using this line of code to read IMU:
serin RxIMUpin,i57600,[WAIT("!ANG:"), sdec swXimu, sdec swYimu]I’ve no idea where this come from. The big ARC-32 mystery LOL.
I’m hoping someone like Kurt have an idea whats causing this?
Hi Kåre,
My first guess is yes, the hardware interrupts to read on the serial data from the IMU is corrupting the data being sent out from the Arc32 to the SSC-32. (Was one reason my Phoenix just had the Arc32 and not the SSC-32 with it… ) But not anymore .
If you remember with the Bap28/Arc32 Phoenix code when we are using the XBee, I have code to disable the XBee sending data, while we output the SSC-32 data. Not sure how to do the same thing with this device. I don’t see any IO pins or the like that allow you to tell the IMU that you don’t wish to receive any data. The external connector shows DTR and CTS, but looking at the schematic, I don’t see it actually connecting up to anything. Not sure what the best way would be to keep it from corrupting the SSC-32 data.
As for Software Serial, it will only receive characters while it is actually in the serin…
One approach may be to update the firmware on the IMU, to have some form of simple control. Like maybe use one of the SPI pins that are part of the ISP connector and use it to control when data is sent…
Sorry I am not seeing anything easy or obvious.
Is this the IMU you are using? sparkfun.com/products/10736
Thanks for your fast reply Kurt!
Ah, I see. I’m using this IMU from sparkfun, an older version of the one you posted. Looking at the schematics, like you suggested the only option would be MOSI (PB3) or MISO (PB4). I hope they can be access in the code, maybe just check PB4 before sending serial?
If not I could simply use an external OR gate or a NAND gate (use a 2. NAND for inverting the output of the first NAND). I think I’ve some old TTL and CMOS chips somewhere… I’m currently using a level converter, but I’m not sure if its needed since it worked fine without while running the test code on another ARC-32. I started using the level converter when I noticed the bug started when RXD-BAP went low without sending any data from the IMU, and to make sure the bug didn’t occur due to 5v vs 3,3v issue.
Thanks!
I’ve done searches on the web to find out if I can use the MISO on the IMU SPI (atmega 328 ). Hopefully I can use it as an ordinary digital input. But I’m wondering what pin number the MISO is referred to in the code. I found this pinout docs, so I assume the MISO(PB4) is pin 12 in the code then?
Hopefully I’ll get some time this evening to try it.
Typically on Arduino 328 systems, the SPI pins (MISO, MOSI, SCLK) are on arduino pins 11-13, so the typically can be used…
Alternatively, could use the Serial input, where it only sends you data, when you ask (like simply send an ! to it…
I forgot to ask, but was sure you probably already tried the serin command on a different IO pin (not associated with the hardware serial port…)
Thanks for your help Kurt!
Yes I did try software serial on a port not associated with hardware serial.
Anyway, I updated the IMU code and the output from the IMU went just garbage. After some google I found that you’ve to choose “Arduino Pro or Pro Mini(3.3 V, 8Mhz) with AtMega328” board and not the “[highlight=#ffffff]Arduino Duemilanove w/ATmega 328” as told in the instructions… sigh.[/highlight]:roll: Actually I had this problem some years ago too, but I had completely forgot it…
The IMU code work just perfect, now the IMU only sends out serial data when p12 (IMSO, pin 2 on the ISP plug) is high. Using IMSO was very convenient since the pin 1 on the ISP plug is 3,3v. Simply add a jumper if you want the IMU to act normal.
But best of all, the MorpHex code on the ARC-32 work just fine and no SSC-32 com corrupted.
Now the fun part begin…
I’ve some ideas of having MorpHex in sphere/ball mode and if a child interact with it, it start re-acting. lol
Maybe add some LED lights for indicating the IMU readings.
Thanks Kurt!
I’m planning to use the TXD-BAP on UART1 for sending data to the serial controlled RGB LEDs, I hope…
Glad you got it working! Will be fun to see what you come up with!
Thanks Kurt,
I’ve reprogrammed the IMU and mounted it as close as it gets to the center of MorpHex. I’ll soon post more details on my blog. I’ve also got the StarLite RGB Led’s working using software serial, I just need to give 24 of them a new individual address and find a good way to mount them on the sphere sections.
The IMU works very fine in rolling mode. Using a very simple code MorpHex started rolling by itself only controlled by the IMU data .
Having fun!
Hi,
Its been a while since my last post. But I’ve done a lot of code work almost every evenings during the last month. I’ve also mounted 24 Starlite RGB LED’s. Currently I have MorpHex working very well. When I get time I’ll post much more information about my latest work. To be honest, the two latest upgrades (IMU and RGB Leds) made a huge improvement to the project, so I’m tempted to call it Morphex MKIII.
When I get time I’ll shoot some new videos too.
Here are some pictures I took a couple of weeks ago when I finished mounting the LED’s. In a dimmed lighted room the light effect from the LED’s is pretty awesome!
http://zentasrobots.com/wp-content/blogs.dir/3/files/2014/07/MorpHex_Colors.jpg
That looks so cool! Can’t wait to see video.
Kurt
Thanks Kurt!
The light effect look even better in real life. Its kinda hard to take a good photo of the leds.
I’m currently working on some extra light effect, just for fun. Any ideas are highly appreciated,
I’m a fan of LED’s… that’s very nice.
Hope to see it in full darkness rolling around and scare peoples… lol
[font=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif][highlight=#ffffff]Hi,[/highlight][/font]
[font=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif][highlight=#ffffff]Some weeks ago I got time for shooting some videos for demonstrating the LED’s and the IMU. I’ll soon update my blog for more info and pics. I’m also planning to post a long (7-8 min) video too.[/highlight][/font]
Oh…
What one can say after seeing that …
WOW!!!
Oh yes… that would have cover everything.