Some updates & questions on my project (wheelchair robot)

Projects General Guidance
1

Hello,
It's been a while (few months) since my last update on my robot.
I've recently purchased a few more goodies for my wheelchair robot.
*I will be adding updates to this thread, stuff I forgot to add or additional info.
Just for a reference, this is an old video I did a while back, some things have changed:

**I'll have an updated video up soon.

***Here's an updated simple diagram of what I'm aiming for:

1024×1004 122 KB

I've also looked at various methods for communication between the Arduino and PC:
http://www.arduino.cc/playground/Main/InterfacingWithSoftware
Using, for example, Firmata, GoBetwino, and many more...

I'll try and run down the setup that I would like to use:
The Intel mini ITX motherboard, dual core Atom 2.13GHz cpu will be the 'main' brains and information transfer.

The Arduino Uno has the code to run the robot using Duane's multi-channel RC code found here:

There is also an 'Aux' channel which will switch from Autonomous to manual control.

The Arduino Mega2560 will be connected to all the sensors (Ping sensors, PIR motion sensors, Compass, GPS, etc..). Will process some of the sensor info then send to the Intel mainboard

MS Kinect (another sensor w/microphones) will also send it's data to the Intel mainboard.

The information gathered is processed then 'tells' the Arduino Uno what to do (Speed, foward, reverse, left and right).

I guess I was wondering from the link above (with PC interfacing software to the Arduinos) what would be the best way to communicate and how it would communicate with the 2 Arduinos.

I hope I made some sense...I will update the thread as I go along...

thomas

2

Thomas, cool project!

About communications: What data rates do you need? RS485 might be fast enough, low-cost, usb-485 modules exist etc..

Some examples: http://goo.gl/S1lFR

DISCLAIMER: Mentioned stuff from my own shop... which is what I know about....

3

Thanks Terry,
I was actually looking at those modules.
Looking up the data speeds for RS485, appears to be 10Mb/s-100Kb/s?
I'm sure this is plenty fast to transfer data from the Arduino Mega2560 to the PC motherboard and also to the Arduino Uno.
One thing I didn't understand about the RS485 was the '32 drivers and 32 receivers on a single (2-wire) bus'.

Information that will be sent from the Arduino Mega2560 to the PC are:
-PIR motion sensor data will be High or Low (or on and off) or 0 and 1. There are 2 PIR sensors.
-Ping sensor data will be numbers in inches (2-3 digit numbers) updated <= 1 second(?). There are 3 Ping sensors.
-Compass sensor data will either be N, S, E, W, NE, SE... or degrees 0-360...(not sure on this yet).
-GPS sensor data will be Lat & Long numbers, possibly updated every few seconds seconds.

Information that will be sent from the PC to the Arduino Uno are:
-Numbers ranging from 1000 to 2000 (these numbers correspond to the pulse duration in of the RC signal). These numbers will be sent for the throttle and steering.

t

4

Just a few more things that came to mind.

Regarding the data going from the PC to the Arduino Uno (numbers from 1000 to 2000).
These numbers are µS (micro seconds), but the Arduino Uno does this conversion/calculations.
Neutral (throttle or steering) would be around 1500.
Lets say I'm sending a value of 1760 to the Arduino Uno. This value has to be a constant stream (it can't be sent just once). Or possibly many times a second?

Also, one reason I'm using 2 Arduinos is that the Arduino Uno has the RC code to drive the motor controller. This uses the 'PinChangeInt' and doesn't use 'PulseIn' command. I really like this and already works well manually with the RC transmitter & receiver.

Going back to the RS485 modules Terry posted. I know the USB connection (from the Arduino) is actually a UART or USART Serial connection. Would it be possible to just use the USB connections to the PC to transfer data?

And a question on the MS Kinect. This may be better asked at the Kinect forums but I'd thought I'd post it here as well.
Should I mount the Kinect permanently facing foward or could I use the Kinect as the head of my bot. When using it as the head of the robot, the head turns left, right, up and down.
I was wondering what would be the best way to mount the Kinect. Not sure if all the head movement will have it re-calibrating itself all the time...?

I'll have a quick update video up by this evening.

I welcome any suggestions or ideas on anything from the above posts :slight_smile:

t

5

Hi,
If you are not using the servo library and have no plans to use it, you can use a faster version of the RC Code here -

If you need servos, the library includes a fast servo library, the whole idea is to reduce the time that the Arduino is spending inside interrupt service routines. This gives more accurate input and outputs, its visibly smoother.

The Interrupt part of the code should be easy enough for you to implement in whatever sketches you have at the moment, but if you want to use the servos let me know and I will mock up a test sketch for your configuration.

Duane B

rcarduino.blogspot.com

6

DuaneB:
Hi,
If you are not using the servo library and have no plans to use it, you can use a faster version of the RC Code here -

RCArduino: How to read RC Channels - The RCArduinoFastLib

If you need servos, the library includes a fast servo library, the whole idea is to reduce the time that the Arduino is spending inside interrupt service routines. This gives more accurate input and outputs, its visibly smoother.

The Interrupt part of the code should be easy enough for you to implement in whatever sketches you have at the moment, but if you want to use the servos let me know and I will mock up a test sketch for your configuration.

Duane B
rcarduino.blogspot.com

Thanks a lot for the reply Duane :slight_smile:
The Arduino Uno that I'm using will only have your code on it. Using the (Aux) channel toggle on receiver I should be able to change the RC signal input pins (input from the RC receiver and input from the PC). The output signal pins will be the same and go to the sabertooth motor driver.

I may be using some servos (like for the head tilt up/down) but I could do this through the Arduino Mega2560.

What are your thoughts on this. If this is doable, I'll use the updated faster code you provided.

t

7

Here's a small update video on some progress and parts I recently got for the robot:

t

8

thomas3120:
Going back to the RS485 modules Terry posted. I know the USB connection (from the Arduino) is actually a UART or USART Serial connection. Would it be possible to just use the USB connections to the PC to transfer data?

That would be what I'd do. Not sure why Terry mentioned RS485; it would be more immune to noise but you can worry about that later.

9

Hi
My only reservation about the RCArduinoFastLib servos is that the library applies a basic philosophy of -

'If your asking me to do something, you have a good reason for asking it'

So if you tell the library to drive 2 servos and do not tell it to apply a framespace it will pulse them at around 250Hz - great for quadcopter ESCs, probably not that good for servos.

I would like to keep it this way becuase it keeps the library fast and flexible, one example being the ability to run two sets of devices at different refresh rates i.e ESCs at 100Hz or more and Servos at 50Hz.

If I add more features it will reduce flexibility and slow the library down until it comes to a point where the library has no purpose - at the moments its pupose is to be faster and more flexible than the servo library.

Its one weakness - I need to document some use cases showing how to apply the library in typical applications.

It sounds like you have been using the original code for a while, so give the new code a try, you should see that its a lot smoother.

I write these things so that people will use them, if you need help or have any questions - ask away

Duane B

10

DuaneB:
Hi
My only reservation about the RCArduinoFastLib servos is that the library applies a basic philosophy of -

'If your asking me to do something, you have a good reason for asking it'

So if you tell the library to drive 2 servos and do not tell it to apply a framespace it will pulse them at around 250Hz - great for quadcopter ESCs, probably not that good for servos.

I would like to keep it this way becuase it keeps the library fast and flexible, one example being the ability to run two sets of devices at different refresh rates i.e ESCs at 100Hz or more and Servos at 50Hz.

If I add more features it will reduce flexibility and slow the library down until it comes to a point where the library has no purpose - at the moments its pupose is to be faster and more flexible than the servo library.

Its one weakness - I need to document some use cases showing how to apply the library in typical applications.

It sounds like you have been using the original code for a while, so give the new code a try, you should see that its a lot smoother.

I write these things so that people will use them, if you need help or have any questions - ask away

Duane B

Duane,
Was looking at your Read Multiple RC channel page here:

and reading some of the comments.
In particular this response you made:

"Hi,
Thanks for the feedback.

Your idea to test for AuxIn > 1800 is correct. I would add a new variable to track the current mode. I would set the mode to AUTO_PILOT if AuxIn > 1800 and to MANUAL_PILOT if AuxIn < 1200 - I assume that your auxiliary channel is a two position swicth like mine. You will then need to a new if condition which will only update the throttle and steering channel if mode = MANUAL_PILOT. As for what you do with the IMU, thats up to you.

Duane B."

Wondering where the best place to add a new variable for AUTO_PILOT if Aux_In > 1800 and MANUAL_PILOT if Aux_In < 1200
Would it be in this location:

void loop()
{
  // create local variables to hold a local copies of the channel inputs
  // these are declared static so that thier values will be retained 
  // between calls to loop.
  static uint16_t unThrottleIn;
  static uint16_t unSteeringIn;
  static uint16_t unAuxIn;
  // local copy of update flags
  static uint8_t bUpdateFlags;

Also to set up a new condition for only updating the thrott. & steer channel if mode = MANUAL_PILOT would go here:

// we are checking to see if the channel value has changed, this is indicated  
  // by the flags. For the simple pass through we don't really need this check,
  // but for a more complex project where a new signal requires significant processing
  // this allows us to only calculate new values when we have new inputs, rather than
  // on every cycle.
  if(bUpdateFlags & THROTTLE_FLAG)
  {
    if(servoThrottle.readMicroseconds() != unThrottleIn)
    {
      servoThrottle.writeMicroseconds(unThrottleIn);
    }
  }
  
  if(bUpdateFlags & STEERING_FLAG)
  {
    if(servoSteering.readMicroseconds() != unSteeringIn)
    {
      servoSteering.writeMicroseconds(unSteeringIn);
    }
  }
  
  if(bUpdateFlags & AUX_FLAG)
  {
    if(servoAux.readMicroseconds() != unAuxIn)
    {
      servoAux.writeMicroseconds(unAuxIn);
    }
  }
  
  bUpdateFlags = 0;
}
11

Hi,

I am guessing that your robot will be able to turn on the spot using counter rotation ?

If so you will find this post interesting for these reasons -

  1. It shows how to calibrate the transmitter so we know the full range which is rarely the assumed range of 1000 to 2000us
  2. It shows how to implement proportional counter rotation and steering from a two channel RC transmitter
  3. It implements two modes - program mode - and run mode

It might not be an exact match for what you want but its a good pointer in the right direction, there is also a lot in there that could be relevant to your current project.

Let me know if it helps -

Duane B

rcarduino.blogspot.com