PDA

View Full Version : [Question(s)] Using the Serializer with Xbee WiFi



ROBOTMAN
10-24-2009, 04:46 PM
I am currently working on a robot butler as a part time project during school. I want to use the serializer board for controlling my robot. I thought it would be easier to not physically attach the robot to the computer but to instead have a more powerful desktop computer in another room controlling it. How hard would this be to do with the Xbee WiFi attachment? The computer would need to do all the thinking such as interpreting sonar values and moving the motors. Could this be done reliably with the Xbee? I don't plan on using python anymore because I think it would make things more complex. I hope to use a program with Microsoft .NET framework. What program would be best for a beginner to programing that has the Microsoft .NET framework?

lnxfergy
10-24-2009, 05:13 PM
I am currently working on a robot butler as a part time project during school. I want to use the serializer board for controlling my robot. I thought it would be easier to not physically attach the robot to the computer but to instead have a more powerful desktop computer in another room controlling it. How hard would this be to do with the Xbee WiFi attachment? The computer would need to do all the thinking such as interpreting sonar values and moving the motors. Could this be done reliably with the Xbee? I don't plan on using python anymore because I think it would make things more complex. I hope to use a program with Microsoft .NET framework. What program would be best for a beginner to programing that has the Microsoft .NET framework?

Connecting with the XBEE rather than a hard serial cable should be no different (that's the whole design of the interchangeable modules). However, and I realize that the serializer has a DotNET library, I don't think DotNET is going to be any "easier" than Python (the serial protocol for the Serializer is really quite straight forward). Python is about the easiest language out there (that is a real language). I'd suggest rather than jumping around from platform to platform, sitting down and really learning how to use what you have.

-Fergs

Adrenalynn
10-24-2009, 05:31 PM
I'm going to agree with Fergs here, but I'm going to expand a bit...

If you _really_ believe you need dotNet, maybe Visual BASIC. BUT - dotNet is a gihugic rat-hole. There are so many levels of inheritance buried so deep in overrides that its rather impenetrable. I find myself gravitating more and more back to the "pure" languages. Python is still relatively pure but powerful. ANSI C with the appropriate libraries. Python with the appropriate libraries. PHP with the appropriate libraries. Easier to learn, easier to move around in, easier to do source and version control in a meaningfully maintainable sort of way.

You need to do some soul-searching and ask why you _really_ feel you need the dotNet framework. You're asking to lock yourself into a structure that is going to be _very_ hard to break away from later. And later you're going to discover all the reasons why you want to, and you're "going to hate yourself in the morning"

Yes, driving the Serializer over its serial control from any modern language on any modern operating system with any modern hardware is the ultimate trival programming endeavor. All the hard work is already done within the embedded system. I think you'll find that you bump your head when you start getting into fast wheel encoders and trying to do advanced SLAM, but for today, it should address what you're trying to learn, be it over a hard wire, BlueTooth, or the XBee.

ROBOTMAN
10-24-2009, 06:05 PM
You mentioned running into problems with fast wheel encoders? Wheel encoding is why I plan on using this kit. My home made solution with the arduino didn't work because encoder data was getting to my python code to slow. I now plan on using this kit for the base of my robot butler. http://www.trossenrobotics.com/stinger-robot-kit.aspx. Would I run into problems trying to keep the robot from drifting left or right with encoders using serializer. The big problem with my last bot was that it would slowly turn to the left or to the right. My real fear with the serializer is getting encoder or sensor data too slow and either drifting or hitting something; also not being able to send commands back quickly and efficiently.

Adrenalynn
10-24-2009, 06:40 PM
You need to look at your architecture and code. Thousands of people are effectively using the Arduino and encoders. If your architecture is messed up with such a simple system, trying to move to a non-deterministic PC-based system is going to be a nightmare for you.

Adrenalynn
10-24-2009, 06:48 PM
My concern for you is that you are just transferring the problem of a noisy algorithm off one onboard core to an inherently noisier and far less manageable remote core. You're going to amplify the problem instead of resolving it. Have you done any reading into process control, like Kalman Filtering?

lnxfergy
10-24-2009, 06:49 PM
You mentioned running into problems with fast wheel encoders? Wheel encoding is why I plan on using this kit. My home made solution with the arduino didn't work because encoder data was getting to my python code to slow..

We discussed this is the last thread I thought. If you want to do closed-loop speed control, it really has to be done entirely on the micro. Sending encoder counts up to a PC, and then adjusting the motor output from that PC is likely going to generate way too much lag -- frankly, I'm amazed that you just had gradual drift, rather than the robot breaking into oscillation.

Maybe you should post up a bit more about your current version, it's almost certainly less work (and definitely less cost) to debug the current implementation, than to jump ship and start from scratch.

-Fergs

ROBOTMAN
10-24-2009, 07:02 PM
The reason for the drift was bad serial communication due to crappy coding on my part and your right it was more like oscillation. Also my encoders where just modified line sensors. Basically the whole setup was bad. I'm looking for a more professional look and feel that a wooden platform, arduino, and phidgets motor controller couldn't give me. Condensing the robot into a smaller factory made platform and getting real encoders seems like a good idea. I have no way of controlling my size and torque motors form an arduino otherwise I would. Also my computer needs to be able to control the motors fully to use the robots full potential something that seems difficult to do with the arduino. Also changing the boards needed to control this robot from four to one makes more sense in my opinion.

lnxfergy
10-24-2009, 07:13 PM
The reason for the drift was bad serial communication due to crappy coding on my part and your right it was more like oscillation. Also my encoders where just modified line sensors. Basically the whole setup was bad. I'm looking for a more professional look and feel that a wooden platform, arduino, and phidgets motor controller couldn't give me. Condensing the robot into a smaller factory made platform and getting real encoders seems like a good idea.

I definitely can see reliability being a reason to jump ship (based on the breadboarded pictures I've seen of your bot), but I think a few of your other reasons aren't such a good motivation for jumping ship.


I have no way of controlling my size and torque motors form an arduino otherwise I would.

Huh? You're using banebots motors and wheels combo, right? You could get a motor driver that interfaces with the Arduino, such as one of the Sabertooth models.


Also my computer needs to be able to control the motors fully to use the robots full potential something that seems difficult to do with the arduino. Also changing the boards needed to control this robot from four to one makes more sense in my opinion.

Your computer could control the motors -- the PC sends a desired speed to the Arduino, and the Arduino drives the motors and uses the encoders to adjust the motors, trying to keep the desired speed.

-Fergs

Adrenalynn
10-24-2009, 07:15 PM
An Arduino could control motors large enough to float the Enterprise aircraft carrier, or small enough to brush your teeth. And it has less latency inherently, with an easier to use interface, and is designed and intended to talk to a PC.

The Serializer is just a PIC 18F452 with a small motor controller and a friendly output to TTL serial (friendly being a couple 2mm headers).

I hate to say it, because I don't think the Serializer is a bad board used for the right reasons [I'm playing with one on Dora in fact], but the arbotiX does everything it does and a whole lot more - you can't really run code natively ON the Serializer, but you can on the arbotiX. And the arbotiX has two serial ports instead of one. And the arbotiX is a grown-up version of the Arduino intended for robotics. The Arduino could do about everything the arbotiX does, and a Sanguino certainly could, it's just the arbotiX is packaged nicely.

Adrenalynn
10-24-2009, 07:23 PM
It's your project, and you're absolutely going to do what you think is best for it and you. You asked for advice, so I'm just offering up the advice that you identify and shoot the little problems rather than move them around and making them harder to see and harder to shoot through more layers of abstraction and complication.

ROBOTMAN
10-24-2009, 07:41 PM
Being a beginner the less coding I have to do the better not having to touch the serializer programing wise is a big plus for me. Also I really want to use the base and I'm not sure how well this controller would interface with that? How well dose this board interface with I2C? Serializer made it sound like interfacing with all external devices through I2C would be easy. I'm just worried about ending back up where I am right now with a serial program that wont work with python "you probably remember my long thread about serial problems with python" I think that might still be an issue. Knowing that the problem cant possibly be with the controller will make future serial development easier.

Adrenalynn
10-24-2009, 07:44 PM
Without programming, on any platform, it's going to sit there like a bump on a log.

The problem can't possibly be with the controller. That's a given for either one. I sincerely wish you the best of luck with either though!

Adrenalynn
10-24-2009, 08:16 PM
Given that you don't want to do any programming, maybe this is a better platform for you to start with (http://www.wowwee.com/en/products/toys/robots/robotics/tri-bot)?

ROBOTMAN
10-24-2009, 11:33 PM
Its not that I don't want to do programing I'm certainly passed that stage in learning robotics. :) But being a beginner every line of code I have to type seems to make the program less reliable. I agree now that I need some sort of micro controller with a wireless interface to efficiently run my robot. However the one you recommended has far too few inputs and outputs and the serial lines are dedicated to the Xbee and a biloid controller. I need something with many I2C ports and analog in and outs.

Adrenalynn
10-25-2009, 12:30 AM
"Many I2C ports" - you mean one i2c bus, right? Like the Serializer, the arbotiX, the Arduino, the Sanguino, or any other controller that has i2c?

And no, the serial lines aren't _dedicated_ to the bioloid bus. The pins are right there.

And if you need more than 8 analog, you're really going to be disappointed with the Serializer's 5 analog in, 0 analog out...

MikeG
10-25-2009, 09:00 AM
@ROBOTMAN
Generally, having a lot of IO is a good thing and programming is large part (very large part) of DIY robotics.

ROBOTMAN
10-25-2009, 01:28 PM
I understand now that I need to program some sort of microcontroller in order to control my efficiently the way that I want to. My new question would be what microcontrollers have a simple language, can easily control servos, have lots of inputs and outputs, and at least one i2c port? Also could you use threading with a microcontroller?

ROBOTMAN
10-25-2009, 01:31 PM
What about this controller based on the ATMega1280? http://www.robotshop.us/dfrobot-atmega1280-mega-usb-microcontroller.html

jes1510
10-25-2009, 02:35 PM
No you cannot use threading. A poor little micro can only do one thing at a time. The closest thing would be a Propellor chip that has mulitple cores in one die. I think the XMos is similar but have never messed with either.

I'll also second the Arbotix. What does the Arduino Mega give you that you need that the Arbotix board doesn't have?

Adrenalynn
10-25-2009, 02:54 PM
The XMOS does multithreading and multicore. But it is entirely inappropriate for this application. It has lots of pins, but no ADC or I2C or serial or anything else. It needs an engineer to make it do what it wants to do. Sometimes it makes my brain hurt. It's not a toy... Incredibly powerful mind you - but not a toy...

I'm thinking that you may just not know the right questions to ask. What are you trying to accomplish, specifically?

ROBOTMAN
10-25-2009, 03:05 PM
It give 4 serial ports instead of two, 56 digital in/out, 16 of witch can be used as pmw, and 16 analog inputs.

Adrenalynn
10-25-2009, 03:11 PM
Well heck, if you just go with a large FPGA, you could get say 32 serial ports, 128 digital I/O, all of which can be PWM, and then hang a bunch of 10 bit DtoA's off the remaining pins, say another 72 analog inputs.

ROBOTMAN
10-25-2009, 03:43 PM
Is that what you would recommend? It looks slightly more complicated than I would need. The controller I mentioned is also cheaper.

Adrenalynn
10-25-2009, 03:57 PM
With infinite power comes infinite programming responsibility. The take-away point here: the more advanced the controller the more programming expertise required. When you can make an FPGA sing, you'll be one of the top handful of programmers here. When you can make it sound angelic, you'll be one of the top programmers on the planet...

ROBOTMAN
10-25-2009, 04:02 PM
:). I wish I was that good at programing, maybe I'll work on that some time. Dose anyone know if you can combine the Xbee shield and the motor shield on one board?

Adrenalynn
10-25-2009, 04:06 PM
which motor shield and which xbee shield? As long as they have through-pins, yes. I'm running an xbee shield, motor shield, and custom terminal block header shield on a genuine Arduino.

Of course, the arbotiX has a motor controller, an xbee interface, and an extra serial port all on one board, as well as more pins for analog input, and more memory... So my Arduino's aren't getting any love these days.

MikeG
10-25-2009, 08:33 PM
I'm a big fan of the Parallax propeller. It's like an empty slate when it comes to hardware interfacing. [Big BUT]... knowing a few bytes of assembler and SPIN (a propriety language for the prop) is handy. 8 parallel 20 MIPs COGs (micros) let you do some cool stuff ;) I have a rig that controls an AX-12 network, receive commands from another serial port, while displaying sensor (and ax-12 data) on a TV, LCD, or monitor through other port(s).

Like Adrenalynn mentioned "With infinite power comes infinite programming responsibility."

My only complaint with the prop is the 7-22 cycle hub (shared) memory read. Others might say the propriety language. [Exhale] programming languages are like the soup de jour. I fancy split C.

Adrenalynn
10-25-2009, 10:40 PM
I fancy split C.

#ifndef vegetarian
#include "bacon.h"
#endif


Sorry - needed to add some portability to that statement. ;)

ooops
10-26-2009, 09:23 AM
Mmmmmmmm soup (said in my Homer Simpson voice):)

ROBOTMAN
10-28-2009, 09:59 PM
I'm thinking that you may just not know the right questions to ask. What are you trying to accomplish, specifically?

My goal is to have a microcontroler that can control 12 servos, read 12 analog sensors, communicate with one i2c device, read 20 digital sensors, and relay all that information back to the PC. I might word this next part wrong so don't go to hard on me; I want it to be able to do all of this at the same time as in not have to unplug a servo to attach my 12th analog sensor.

My concerns are that I wont be able to control all these in a timely order. Mostly I'm concerned that managing my speed and measuring the encoders will take up so much time my servos will be jumpy and my analog sensors will rarely get read "The motors I'm using have 850 counts per revolution!". In order to map properly I would need to total the counts for each motor witch would mean counting each individual tick! I have never really tested the speed of my arduino's processor but I doubt it can count the 1700 ticks per revolution that both my encoder will create and still have time to smoothly pan a servo. What happens if two encoders tick at the same time? Will I only be able to count one? I have been working with interrupts and it seems like they work better when very little is going on in the other part of the program. :confused:

Adrenalynn
10-28-2009, 10:06 PM
Define "same time" and define "revolution.

16 Million Cycles, nearly 16 Million Instructions per second. If you're only doing 1RPS, well, that kinda puts that 1700 ticks into perspective. You've got almost 16 million instructions, whatcha gonna do with the other 15,996,600* ?

Of course, if your wheels are rotating at 16 million RPS, well, then no, it's not.

Like anything else on any processor: Bad architecture begets bad performance.

But no, you're not going to get 12 analog sensors and 12 servos on an Arduino. Depending upon how we define "at the same time" - are we talking milliseconds or microseconds or femtoseconds, the Axon may work out well.
*Note: Assuming true RISC, 1 cycle per instruction is not guaranteed. But for illustration purposes...

ROBOTMAN
10-28-2009, 10:27 PM
Actually I meant being able to attach all those devices at once I just forgot how to say it. I want my robot to look like everything is happening at once with the interrupt code being run 1700 times a second it seems like things would slow down. At least form the tests I have done so far "My servo noticeably pauses every time the code gets interrupted". From looking at my tests it appears that I might miss ticks while the interrupt code is running and my servos might jerk around.

lnxfergy
10-28-2009, 10:52 PM
Whoa.. 12 servos, 12 analog sensors, 20 digital sensors. That's a lot going on. Before even further evaluating what a particular controller can/cannot do, you might want to ask yourself, do you really need that many sensors? Often times, less actually is more (active sensors like IR/sonar can actually hurt each other).

For instance, my early fire bots used an average of 6 IR sensors + sonar + tons of fire detection gear. Guess what, latest bots use a single IR and single sonar on a panning head. No need for lots of sensors, intelligent code makes up for it, and actually can make it better.

-Fergs

Adrenalynn
10-28-2009, 11:02 PM
Generally digital pins aren't really tied to a bunch of sensors anyway. Digital I/O is good for devices that need a lot of parallel bits. LCDs, cameras, flash, eeproms, ram, ...

ROBOTMAN
10-29-2009, 06:59 PM
You are right about not needing that many digital sensors. I will need three ultrasonic sensors for my panning servo. I plan on having 4 fixed digital IR sensors in case my panning servo misses something. Also random sensors like downward facing IR to not fall down stairs and force sensors in the gripper maybe a motion sensor too. Then I plan to run the rest of the things off an i2c bus. For sure I will need the capability to use the 12 servos because at some point I may want to pan other sensors and I will have a six servo arm maybe even two six servo arms. Another concern I have is not being able to pan all my servos so they appear to be working at the same time.