Starting an RC Receiver control for Botboarduino and others

Lynxmotion Electronics & Software
1

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
RCReceiverTest-120512a.zip (2.72 KB)

2

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

3

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…

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

4

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. :wink:

5

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

6

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

7

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

8

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: 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

9

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

10

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
LimitedSoftwareSerial.zip (6.43 KB)
THR4_RC-120515a.zip (31.3 KB)

11

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

12

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: 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

// 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

13

Oh, OK, nothing unfamiliar. All I have to do is compile, I’ll see the needed include files.

Thanks!

Alan

14

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 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

15

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

16

Hi Aaron,

T7C here as well. I did get the DIYDrones PPM module, and will connect it up to either the new Botboarduino or my Arduino UNO. I got two receivers with it, one for my heli, and one for a 'bot. Yeah, the receivers are expensive! I could use a couple more!

But even if you use the PPM module, you still have to painstakenly measure each pulse width, even if done in the background by an interrupt process. Maybe better then pulse in one channel at a time, 'tho.

What is needed is a uP system, with an external bus. Then the data could be transferred a byte at a time. Converting to a RS232 (ttl) transmission received by an interrupt would probably be fast, and with hardware could be done in the background.

I’m going to be using a slave processor for sensors; it might work to read the channels or PPM with it, and send ASCII strings as I do for sonar data.

Next, add relative bearing and target/obsticle recognition with a Blackfin Camera. Read it’s message as well. (Humm, Windoz Exploder doesn’t have spelling check?)

Alan KM6VV

17

Maybe this is my ignorance, or just not understanding what I wanted to do, however within the last week or two I realized that Uart is able to receive serial data without interrupting the main code… which is why Uarts are not plentiful on micro controllers…

So that DIY drones module isn’t all that great! you could just use a teensy 2.0 to do the same work… if not reprogram the drones module with my code I wrote… I can post it later although its dreadfully simply… I was about 1-2 weeks into poking around with an arduino before I got it to do what I wanted… I wanted a blinking light so I used the on-board led to blink every other pass.

The Basic Micro only has one Uart so you have to use the last couple pins on your botboard before it will work… 14-15 I think it was?

I plan on having something worked on by this week on my phoenix… I’ll post pictures of the mess.

By the way Alan,
If you want to order one of those turnigy9X’s, I have some spare parts!.. In fact I have two stock TX modules and 3x receivers and some DIY PPM transmitters … I’ll have to take pictures of the leftover stuff I have… I think you could actually build a DIY transmitter like the ubertransmitter2000 that Kurt/xan/zenta built with 40,000 buttons… and it also blends.

I still want to unload my T7C on someone, these ebay cheepies are fun to hack around with.

Once I have some more time to poke around with this “hopefully this week” I’ll show you exactly what I’m trying to do , although that diydrones PPM module is small enough, but then again a teensy at 16 bucks each isnt hard to beat since it has quite a bit more pins… only gripe I have with it are no mounting holes.

–Aaron

18

Hi Aaron,

We USE interrupts on USARTS, so they don’t “BLOCK” the executing code. They are not plentiful because they take up considerable resources of the uC.

It was cheap, I paid for it with PayPal from selling some of my drawings, got it fast!

Yeah, I’ll go with the Arduino Mega or a 32 bit PIC.

I’ll let you know. I’m more interested in a trade for T7C and/or Receivers!

Good if you’ve got the time…

Alan KM6VV

19

Split off the T7C stuff to trading post. Kurt’s original thread has nothing to do with any of that stuff.

20

No worries Jim,

Thanks.

–Aaron