Putting robotics at your service™

Free shipping on orders over $200

Starting an RC Receiver control for Botboarduino and others.

Print view Share :
Previous topicNext topic

Page 1 of 2 [ 20 posts ]

1, 2
User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-12 15:59 
As an interruption to my other interrupts... I had a Botboarduino and my Hitec Laser 6 receiver sitting out and wondered how hard it would be to make them talk with each other... Assuming it works OK, may create a simple IO control class for my Phoenix port...

Wanted to try out the Pin Change interrupts. Saw a couple cases of it being done before, but several only work with Arduinos, not megas. So I updated it to use the Arduino 1.0 pin mapping macros, so should work on others (only on those pins with Pin Change interrupts). My code is currently using the system function micros() for timing, which only gives us a resolution of 4us. Will see if that is good enough.

So far just have a simple test app, that prints things out as they change. Appears to be working... I uploaded my test app including the header file with the Pin Change stuff in it, so others can play along...

Will soon, hack up a control class and try it out on one of my hexs...

Kurt


Attachment:
RCReceiverTest-120512a.zip [2.72 KiB]
Downloaded 60 times
User avatar
Guru ( offline )
Posts: 4104
Posted: 2012-05-12 18:10 
Well I don't think I've seen that file extension before! Interrupt?
Does it get compiled the same way?

Looking forward to the Botboarduino, and An R/C interface. I've temporarily got a Hitec Laser 6 in addition to my Futaba T7C.

Are you decoding separate channels or the PPM signal?

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-12 19:42 
KM6VV wrote:
Well I don't think I've seen that file extension before! Interrupt?
Does it get compiled the same way?

Which extension? the .INO? That is the new standard file extension for Arduino 1.0. Ardu"ino" Trying to make sure everything is 1.0 compatible... The code is currently not specific to BotBoarduino or Arduino 168/328, like several other Pin Change interrupts are... On this class of Atmega chips, all IO pins have Pin Change Interrupts, whereas the chips like Atmega 1280/2560 only have it on some IO pins, which in Arduino land is pins: 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69. The left the pins associated with the USARTS off of this list. I have not done any testing on the Mega yet...

KM6VV wrote:
Looking forward to the Botboarduino, and An R/C interface. I've temporarily got a Hitec Laser 6 in addition to my Futaba T7C.

Are you decoding separate channels or the PPM signal?
I am decoding all channels separately. I have the 6 channels plugged into IO pins 6-11 and currently it is pretty simple code. I set the pin change interrupt for both transitions on all of the IO pins that my RC receiver is connected to. When it gets the RISING transition, it remembers the time, when it gets the FALLING it subtracts the current time to get the deltas... Code makes no assumptions about what order they come in, or that they overlap or not... Will be interesting to see how well it performs. Personally I am much more interested in the XBees, but the subject keeps coming up, so I thought I would give it a few hours work and then let others have some fun with it.

Kurt


User avatar
Guru ( offline )
Posts: 3298
Posted: 2012-05-12 21:22 
Great work. Im glad to see you are continuing to brake into the boards using rc control. Something Im very interested in playing with. If we can establish a working hexapod code, lynxmotion will be selling another botboarduino. ;)

_________________
Jonny Poole,
Freelance Concept Art & Animatronics, 3D Art and 3D Modelling, as well as Physical Modelling, Mechanical design, and illustration.
http://www.innerbreed.co.uk
Create, Innovate, Inspire.


User avatar
Guru ( offline )
Posts: 4104
Posted: 2012-05-13 00:15 
Waiting for my Botboarduino to get here!

I noticed the R3 UNO boards have extra pins, four I think, and I had to get a new driver from the 1.0 Arduino release. I'm still compiling with pre 1.0. Not a good time to change the compiler for a project at work.

I could see it was C/C++ code, why don't they just call it CPP.

Didn't have time to try it yet, but I just stripped down a "Stadium truck" R/C stripped out the electronics, and spun the motors. Not differentially steered, a drive motor and a steering motor. A little different to control it with the Botboarduino and a dual H-bridge board. We'll see.

Initially we need R/C, but plan is to run it autonomous for Robomagellan.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-13 09:58 
As for .ino versus .cpp... Thats the wonder of Arduino... There are a bunch of minor things that get per-processed by Arduino before going to the compiler, like merging all of the files (tabs) without extensions, plus automatic including of headers, forward references... Yes there are some issues converting to Arduino 1.0, things like, the changes to the Serial class, that all like objects now derived from a stream class and the functionality of flush changed...

I have done about 80% of the work to building an RC input control class, but ran into an issue that I am not sure which way I am going to go to resolve. That is when I am using the Arduino non-megas like the BotBoarDuino, I usually put the SSC-32 on non-usart IO pins and use the SoftwareSerial class. The problem is that the SoftwareSerial library defines interrupt handlers for all of the PinChange Interrupts (on these 3 of them). So does my current code. I can easily change my code to configure it to only define the ones I wish to use...

Background: On the Atmega 328s and the like: There are 3 interrupts associated with Pin Changes, each of which have up to 8 pins associated with it.
digital pins 0-7 are on interrupt 2 (actually interrupt vector 11...).
digital pins 8-13 on Interrupt 1
Analog pins 0-5 on Interrupt 0

On Mega (Atmega 640/1280/2560): Not all pins have them, mentioned in prevous post...). On Sanguino like boards including Arbotix, my DIY board... (Atmega644p), I think all of the pins have them again, they also defined a 4th IO vector. Also found that their pins_arduino.h file does not have them defined correctly... Now back on subject

So my options are:
a) Punt - The easy solution as I am not a big RC guy...
b) On these Robots move the SSC-32 over to the hardware USART. However issues are, that you don't have any place to output debug information and you may have to remove a wire when you wish to download new programs to the board...
c) Muck up the Software Serial library - Example to say that you can only use the Analog pins as a receive pin for software serial... That would be the first interrupt vector... Already updated my code to allow it to be configured...

Not sure which way I will go yet...

Kurt


User avatar
Guru ( offline )
Posts: 4104
Posted: 2012-05-13 18:15 
That's quite a situation! I just went to megas to solve mine.

This use of R/C on the Botboarduino for me will be simpler. I won't need to talk to an SSC-32! The R/C is probably only temporary, although I might consider it for a "dead man" switch.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-15 08:59 
Quick update here:

I did a little more hacking on it yesterday. I changed the code (profile to run on my TH4-R), Still have some configuration issues with it, plus my code detecting good and bad data is hiccuping, so I need to work on it...

Working on 2 solutions for Pin Change Interrupt being wanted by my code and SoftwareSerial...

1) Allow the SSC-32 code to use Serial object... Don't like, but can do...

2) Have my own version of SoftwareSerial, that allows me to define which of the interrupts I will use or not use. I did this. If you google around that is the solution that others have done. Example: http://code.google.com/p/arduino-pincha ... etail?id=7

Thinking about this some more, I think I can undo some of my PinChange turn on/off interrupts code as SoftwareSerial disables interrupts, so I don't need to do that here... Still need to make the data more robust, like throw away the data when out of range... But don't trigger the Bad Data code unless maybe we get lots of it...

Kurt


User avatar
Guru ( offline )
Posts: 4104
Posted: 2012-05-15 13:19 
If you are experiencing bad data, then it might be wise to incorporate a fail-safe of some sort. Not as bad as for aircraft, but a RoboMagellan might need one. The RoboMagellan rules require some sort of dead-man, that might be a reason to keep an R/C link on board for me.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-15 16:04 
Yes, my code is set up to detect that all of the signals have a pulse width between a minimum and a maximum. Getting reasonably good data, but when you have things like Softwareserial, disabling interrupts and the like, it will cause one or more pulses to be corrupted. Code is in place now that when it does not detect a full set of valid data (valid RC pulses for each channel) it triggers the code to act like you hit the start button on the PS2 and turns the robot off...

That is working pretty well now at least for walking. Finding I am timing out with rotations and translations. Probably some other bug... In case anyone wants to play along, here is a zip file with the stuff set up for my 4DOF Hex, with the SSC-32 connected to A4-A5... The Header file pcint.h that is part of this sketch is my Pin Change Interrupt code. If anyone is interested, I can also upload my hacked up SoftwareSerial code...

This RC code is currently setup using my Laser 6, with the 2 joysticks where left up/down is the elevation... I use the Knob to switch modes and the gear switch to toggle through different gaits, or in single leg mode, which leg... Again can be improved on and adapted to other RC receivers.

Kurt


Attachment:
LimitedSoftwareSerial.zip [6.43 KiB]
Downloaded 43 times
Attachment:
THR4_RC-120515a.zip [31.26 KiB]
Downloaded 45 times
User avatar
Guru ( offline )
Posts: 4104
Posted: 2012-05-15 19:12 
Kurt,

Thanks for the updated code. Don't know when I'm going to be able to try it out.

Is that all, or do I have to change a library as well?

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-15 19:47 
Take a look at the header file pcint.h I mentioned. It is based on some other libraries that are out there like: PinChangeInt which you can get up on the Arduino Playground: http://arduino.cc/playground/Main/PinChangeInt which is also based on a previous library. The one up on the playground said it did not support Megas... So I played around with the PinChange definitions that are in the pins_arduino.h which is setup per board type for Arduino 1.0. So in theory should work with most boards, if they have their macros defined properly.

As for needing changes to other libraries, it depends on what you use. If you use SoftwareSerial, it defines a hardware Interrupt handler for all PinChange Interrupts, so it conflicts.
I did a copy of the library and made the code that created the ISR functions conditional on some defines, and renamed the library to LimitedSoftwareSerial. You can then change a few lines at the start of the file
Code:
// Currently defined to allow the read on the Analog pins on standard Arduinos...
#define NO_PCINT0_VECT
//#define NO_PCINT1_VECT
#define NO_PCINT2_VECT
#define NO_PCINT3_VECT

I don't do any verification that you properly disabled the right ones...

My PinChange library is slightly different then the others in that my call back function passes data back. In particular I had my Attach function allow you to pass it a byte identifier that is passed back to you on the callback, likewise the callback gives you the state of the pin...

Kurt


User avatar
Guru ( offline )
Posts: 4104
Posted: 2012-05-16 00:07 
Oh, OK, nothing unfamiliar. All I have to do is compile, I'll see the needed include files.

Thanks!

Alan

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


Expert ( offline )
Posts: 447
Posted: 2012-05-21 22:46 
Ahh cool test application kurt, I will have to try it when I get my hands on another Teensy board.

Personally I know you love the Xbee's as much MUCH more data can be transmitted to the device on the end, however for the average person who wants to have an inexpensive RC solution Xbee's are kinda spendy.

I mean take a look at the Turnigy 9X receiver/transmitter.. the thing is fully hackable and has open source code for your TX its completely fantastic... OK back onto the idea.

When the 1.3 phoenix code came out originally, someone made a comment that the CPU was quite saturated and not much excess CPU was available for any other processing, such as myself adding in 7 pulsin() commands to use my T7C. Caused all sorts of wobbles and affected the gait when it walked... looked bad... however it worked.

the 2.0 code came out that used lookup tables which I have yet to use RC control on using the simple Pulsin() commands... you think it will just work?

I think what needs to be made is something like this https://store.diydrones.com/product_p/br-ppme.htm however rather then outputting PPM signal outputting something like formatted serial strings
1500,1500,1500,1500,1500,1500,1500 .... which is what my first piece of code did for the arduino... not actually knowing C++ I was quite impressed on how easy it was to make... It does not use ... Ill just call them FANCY Interrupts! due to the fact that I do not know how to code them, even from looking at your example code....


I have had the idea in this topic for a couple years now as RC control really wasn't something that a lot of people did... and I really couldn't figure out why..maybe it was too difficult? or hard to use?

I want to expand on the idea for something possibly better... this is the basic theory...

Separate processor such as the diydrone,teensy something small and simple code like pulsin() however, I want to see about adding an eeprom into the mix. I want this device to read the channels as fast as it can possible run which is around 50hz or 60hz?... then when you connect this to your other CPU on your bot, that when it polls the control board it can instantly retrieve its value and continue one, rather then waiting until the cpu thats reading the RC channels is done with a complete pass.


I believe Kurt can fill me in on this, but if you just use pulsin() in an arduino, the command exits once the pulse has made a complete pass.. If you read the channels in order there shouldn't be a need to use inturupts right?

On a side note,

what about creating an environment that allows you to take sensors of all kinds and output data like an RC reciever outputs 1000-2000 value.. such as a ping sensor, or a gyro, or an accelerometer.

One Idea that I have had floating around a while was to attach a gyro to the top of the pheonix and as I walked it up a hill the body would self level.. I think thats tessellation mode..
By the way, that maple board is pretty slick.

--Aaron

_________________
Is the warranty voided yet? ... and why not?


User avatar
Guru ( offline )
Posts: 4868
Posted: 2012-05-21 23:19 
Hi Aaron,

As I mentioned before, the Maple boards look like nice boards. I probably won't be getting any of these as I already have a few of the Pic32 boards that run probably even faster. I am also waiting for the new official Arduino 32 bit boards before I go much more in any of those directions...

As for RC versus XBee. It is sometimes hard to quantify what is spendy... For me having an RC solution could be considered Spendy (or at lest time consuming). That is I may wish to control any of my robots, so I would need a separate unit for each one, which from HobyKing is about $54, plus about $25 for the board you mentioned... With this I still get only one directional communications... So yes I still prefer XBees and potentially BT and/or Wifi...

If I were going with an external board, I probably would not use PPM as my output to the Microcontroller, as again either you have to wait for the signals or use interrupts and the like. I would more likely use either I2C or SPI as they are clocked and less likely to be corrupted than a serial stream. Although Serial streams can have advantage of only needing one IO pin...

But if you have a lot of RC equipment and wish to use it as the Joysticks are more responsive than the PS2, then it would be nice to come up with a simple solution for it... It would be nice if the solution could be done in the background as to allow the processor to do other stuff while receiving the data. So the approach I took with this experiment was to use the Pin Change Interrupt. The interrupts happen in the background, so the main code is free to do other things instead of simply sitting in a loop waiting for the pulsin or equivalent to complete. Hopefully it works well enough without additional hardware or it may defeat the usefulness. So far I have only played with my Hitec 6 receiver and hacked up an Input class that can work with it. Obviously this will need to change depending on which Receivers one wishes to use as they all have different data they send. Once I get back to building my Arduino DIY remote control I may as an option try to reintegrate the Spectrum transmitter from the original DIY remote... Not sure yet, but may play with it.

Hope this makes sense.

Kurt


1, 2

All times are UTC - 5 hours [ DST ]. It is currently 2014-07-23 12:02
Feedback Form
Feedback Form