SMALL - espritmodel.com SMALL - Telemetry SMALL - Radio
Reply
Thread Tools
Old Jul 10, 2012, 04:25 PM
Wannabe flyer
Croatia, City of Zagreb, Zagreb
Joined Dec 2009
5 Posts
It compiles!

With Alan's help managed to compile the 5139 tree under Eclipse. First thing after you download the last svn source is to download Jennic's "JN-RD-6004 Wireless" example and extract the Audiolib_JN5139R1.a file and copy it into ./rc24/rx24/source/
After that just import project & compile & download & solder & fly.

Thanks Alan
zlotvor is offline Find More Posts by zlotvor
Reply With Quote
Sign up now
to remove ads between posts
Old Jan 22, 2013, 10:49 AM
Registered User
UK
Joined Mar 2007
343 Posts
New Jennic Modules
I just noticed that Jennic have announced a new wireless processor JN5168 and modules. The modules are slightly smaller and will require pcb redesign I haven't found any for sale yet but when I do I'll give them a go. The processor is interesting as it is smaller and has built in flash so a much smaller rx should be possible if a custom board were made. There are also 5 hardware pwm outputs which has got me thinking about a board with 4 brushed motor outputs and gyro/accelerometer for a micro quadcopter
Alan Hopper is offline Find More Posts by Alan Hopper
Reply With Quote
Old Jan 22, 2013, 11:04 AM
Registered User
Texy's Avatar
Newbury, UK
Joined Aug 2002
671 Posts
I never did finish this project, so I STILL have the bits left over including 3 modules, some pcbs and other sm parts.
Make me an offer to purchase ;-)

Texy
Texy is offline Find More Posts by Texy
Reply With Quote
Old Mar 03, 2013, 02:38 PM
Registered User
UK
Joined Mar 2007
343 Posts
Scripting

I have finally uploaded code to allow scripts to be run on either the receiver or the pc. On the receiver the script is run just before the servo outputs are sent, it could be used for all sorts of things. The script has access to any variables marked as 'routed' i.e. anything you can see from the pc interface can be scripted. Script on the pc can access the tx, rx and any sensors connected.

This video shows crude script running on the pc making the bottom half of a robot walk.

http://www.youtube.com/watch?feature...&v=oiiNwSm9mbY

I have also added code to access a mpu6050 gyro over i2c on the receiver.

Alan
Alan Hopper is offline Find More Posts by Alan Hopper
Last edited by Alan Hopper; Mar 03, 2013 at 03:24 PM.
Reply With Quote
Old Mar 05, 2013, 08:09 AM
Fidler & twidler
empeabee's Avatar
Cranfield U.K.
Joined Mar 2004
3,996 Posts
Interesting - thanks
Mike
empeabee is offline Find More Posts by empeabee
Reply With Quote
Old Mar 10, 2013, 07:30 AM
Registered User
UK
Joined Mar 2007
343 Posts
Some notes on rc24 scripting in lieu of proper documentation

The same script can be run on the pc or receiver and eventually the transmitter.
On the rx it can be used for things like flight stabilization or turning a speed command from the tx into synchronised moves of a robots leg joints.
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
// limit servo output of channel 1

RX.setMixedDemands(1,limit(RX.getDemands(1),1000,3 000))
}


On the tx it will be used for mixing and doing stuff with telemetry data, e.g. making a variometer sound.
On the pc ( and hopefully,eventually, smart phone or raspberry pi ) It can do things like control the movement of a connected model or log sensor data.

The scripting language is compiled to byte code which then runs on a simple virtual machine.
It was done this way because on the tx or rx the script will be run repeatedly with limited resources so it makes sense to parse the script just once.

The script can be downloaded over the radio link or through a serial link, so in flight updating is possible if you are mad enough.

The virtual machine is designed to be small and fast and could be implemented easily on pretty much any 32bit c platform and probably on lower bit width devices with some effort.
I guess it would run easily on a DEVO tx.

The parser and compiler are small enough that compilation on the rx or tx should be possible if ported to c, they currently only exist in c# and java.
I'm not sure how useful this would be, but there is some attraction in storing source code where it is used so you could always edit whatever you left on the tx or rx 3 years before.

The basic syntax is rather like c,c#,java or javascript but with no semicolons at the end of statements.

I've tried to make a simple clean syntax whilst keeping the basics familiar.
Variables don't need to be pre declared and their type is inferred from their first use.

There are no control structures such as for loops or if statements, these are all replaced by allowing functions to accept blocks of code as parameters e.g.

int a=20;
while(a>1)
{
print(a);
a=a-1;
}

is achieved by

a=20
while(a>1,
print(a)
a=a-1
)


parameters are optionally named, so if you prefer you can write

while(test: a>10,
do:
print(a)
a=a-1
)

curly brackets {} are only used to define the body of a function.

functions can be defined to accept blocks of code, so new control structures ( closures ) can easily be created.

while, if,ifelse and for are just functions defined by default.

currently the only variable types supported are:-
num - a 32bit integer ( will probably rename to 'int')
code - a block of code with access to the variables of the function that it is defined in.
external routed objects - eg RX TX IMU Pilot

Priorities on the type wish list are a fast float library and strings and then some sort of local object or struct type.

External objects are currently passed to the script through the main function
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
}
The properties of each of these objects are discovered at compile time by interrogating whatever is connected to the serial port.
This means that if you add extra exposed variables to the rx or tx bin files, they will be available in the script.

The compiler knows nothing special about the tx and rx, if you connect something else that uses the same protocol, it can be controlled from script.

Passing these external objects to the main function as parameters is a bit of a fix and means the have to be passed on to other sub functions that need them, the plan is to make them either global to the script or treat them as fields of the script object.

external object fields can be accessed with a dot and a get or set function
eg rx.setRXDemands(0,2000) sets the first element of the RXDemands array to 2000.

High on the todo list is to add array notation and remove the get set stuff so this will become

rx.RXDemands[0]=2000

On the receiver the script is called every 20ms just before the servo outputs are set. At some point I want to add an option for faster servo frame rates.
The c virtual machine is fairly well optimised but a faster one is in the pipeline. If speed becomes an issue, calls to native c functions are easily added for complex operations.

On the PC the code is just run on demand. The virtual machine on the pc was originally written just to make testing easier, the fact that it can be used to control connected stuff was an unplanned bonus! It was written to mimic the c code, so it looks a bit odd in c#.
It could be made far faster but the coms is so slow in comparison that speed is not a issue, this might change if I add access to pc features such as graphics and sound.

It is proving to be a good learning tool as my 7 year old son seems ok with the syntax and the results of code changes can be seen almost instantaneously on hitting the go button. I do need to improve the error reporting from the compiler though.

Alan
Alan Hopper is offline Find More Posts by Alan Hopper
Reply With Quote
Old Mar 10, 2013, 09:09 AM
Fidler & twidler
empeabee's Avatar
Cranfield U.K.
Joined Mar 2004
3,996 Posts
You have been a busy boy
Memories of a long ago Q&D script I wrote for debugging, which became a feature of the laser once I'd got it working,
It was written to allow detailed checks of asm code by simulating the hardware while running the code in a propriety PC based MPU simulator, in pseudo real time, Then more uses appeared !
Congratulations.

Mike
(Q&D == Quick and Dirty)

Quote:
Originally Posted by Alan Hopper View Post
Some notes on rc24 scripting in lieu of proper documentation

The same script can be run on the pc or receiver and eventually the transmitter.
On the rx it can be used for things like flight stabilization or turning a speed command from the tx into synchronised moves of a robots leg joints.
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
// limit servo output of channel 1

RX.setMixedDemands(1,limit(RX.getDemands(1),1000,3 000))
}


On the tx it will be used for mixing and doing stuff with telemetry data, e.g. making a variometer sound.
On the pc ( and hopefully,eventually, smart phone or raspberry pi ) It can do things like control the movement of a connected model or log sensor data.

The scripting language is compiled to byte code which then runs on a simple virtual machine.
It was done this way because on the tx or rx the script will be run repeatedly with limited resources so it makes sense to parse the script just once.

The script can be downloaded over the radio link or through a serial link, so in flight updating is possible if you are mad enough.

The virtual machine is designed to be small and fast and could be implemented easily on pretty much any 32bit c platform and probably on lower bit width devices with some effort.
I guess it would run easily on a DEVO tx.

The parser and compiler are small enough that compilation on the rx or tx should be possible if ported to c, they currently only exist in c# and java.
I'm not sure how useful this would be, but there is some attraction in storing source code where it is used so you could always edit whatever you left on the tx or rx 3 years before.

The basic syntax is rather like c,c#,java or javascript but with no semicolons at the end of statements.

I've tried to make a simple clean syntax whilst keeping the basics familiar.
Variables don't need to be pre declared and their type is inferred from their first use.

There are no control structures such as for loops or if statements, these are all replaced by allowing functions to accept blocks of code as parameters e.g.

int a=20;
while(a>1)
{
print(a);
a=a-1;
}

is achieved by

a=20
while(a>1,
print(a)
a=a-1
)


parameters are optionally named, so if you prefer you can write

while(test: a>10,
do:
print(a)
a=a-1
)

curly brackets {} are only used to define the body of a function.

functions can be defined to accept blocks of code, so new control structures ( closures ) can easily be created.

while, if,ifelse and for are just functions defined by default.

currently the only variable types supported are:-
num - a 32bit integer ( will probably rename to 'int')
code - a block of code with access to the variables of the function that it is defined in.
external routed objects - eg RX TX IMU Pilot

Priorities on the type wish list are a fast float library and strings and then some sort of local object or struct type.

External objects are currently passed to the script through the main function
e.g.
num main(TX tx, RX rx,IMU imu,Pilot pilot)
{
}
The properties of each of these objects are discovered at compile time by interrogating whatever is connected to the serial port.
This means that if you add extra exposed variables to the rx or tx bin files, they will be available in the script.

The compiler knows nothing special about the tx and rx, if you connect something else that uses the same protocol, it can be controlled from script.

Passing these external objects to the main function as parameters is a bit of a fix and means the have to be passed on to other sub functions that need them, the plan is to make them either global to the script or treat them as fields of the script object.

external object fields can be accessed with a dot and a get or set function
eg rx.setRXDemands(0,2000) sets the first element of the RXDemands array to 2000.

High on the todo list is to add array notation and remove the get set stuff so this will become

rx.RXDemands[0]=2000

On the receiver the script is called every 20ms just before the servo outputs are set. At some point I want to add an option for faster servo frame rates.
The c virtual machine is fairly well optimised but a faster one is in the pipeline. If speed becomes an issue, calls to native c functions are easily added for complex operations.

On the PC the code is just run on demand. The virtual machine on the pc was originally written just to make testing easier, the fact that it can be used to control connected stuff was an unplanned bonus! It was written to mimic the c code, so it looks a bit odd in c#.
It could be made far faster but the coms is so slow in comparison that speed is not a issue, this might change if I add access to pc features such as graphics and sound.

It is proving to be a good learning tool as my 7 year old son seems ok with the syntax and the results of code changes can be seen almost instantaneously on hitting the go button. I do need to improve the error reporting from the compiler though.

Alan
empeabee is offline Find More Posts by empeabee
Reply With Quote
Old May 07, 2013, 09:39 AM
Registered User
UK
Joined Mar 2007
343 Posts
I've just uploaded some improvements to the scripting.

Array and property syntax now works so setting a channel value is now cleaner

tx.TXInputs[2]=2000

string constants can be used and function overloading now works so
print(23) and print("hello") now works

I've added speech output on the pc ( at the demand of the project director, my son)

say("speed is")
say(123)

The rx now has some extra properties

rx.frameCounter - can be used as a clock
eg. rx.RXMixedDemands[5]=abs(rx.frameCounter%80-40)*40
will scan a servo from side to side

rx.missedFrames contains how many frames ago data was received so can be used to do clever failsafe code

pilot.vars[0..39] is a array that can be used to store stuff between frames

Quote:
Originally Posted by empeabee View Post
You have been a busy boy
Memories of a long ago Q&D script I wrote for debugging, which became a feature of the laser once I'd got it working,
It was written to allow detailed checks of asm code by simulating the hardware while running the code in a propriety PC based MPU simulator, in pseudo real time, Then more uses appeared !
Congratulations.

Mike
(Q&D == Quick and Dirty)
Thanks Mike, I find it very addictive and keep having to remind myself to keep it small and simple and not try and grow it into lua or python!

Alan
Alan Hopper is offline Find More Posts by Alan Hopper
Reply With Quote
Old May 07, 2013, 10:01 PM
Fidler & twidler
empeabee's Avatar
Cranfield U.K.
Joined Mar 2004
3,996 Posts
Aaaha - WIBNI rules ok
When someone says Wouldn't It Be Nice If it did this that and/or t'other, think about the minimum system requirements of Windows, which grew out of a DIY dos for an little known cludge up on a failed pocket calculator chip ((((two 4040's glued together --> 8080)*2 -> 8086)*2 -> 486)*2 -> pentium ) ad nausium onwards and upwards but don't look down, it will make you dizzy.
Mike
empeabee is offline Find More Posts by empeabee
Reply With Quote
Old Apr 03, 2014, 07:51 AM
Registered User
UK
Joined Mar 2007
343 Posts
Quadcopter

Hi all,
I've finally got around to writing some quadcopter code to run on my receiver and it flies! I have used one of the six channel receivers with a jn5148 module and a mpu-6050 gyro/accelerometer breakout board plugged into the i2c bus which luckily is available on two of the servo connectors. I've modified the servo output code so it will work up to 400hz. The ability to set and view rx variables over the air from a pc connected to the tx has proved very useful for testing and tweaking.

I've not flown a quadcopter before so don't really know how well it works compared to others but it seems very easy to fly.

I've just ordered a mpu9150 and altimeter and intend to add gps. with the intention of making it fully autonomous.

Does anyone have one of Graham's 8 channel pcbs as that should allow me to connect a serial gps, my six channel board has run out of connectors!

Alan
Alan Hopper is offline Find More Posts by Alan Hopper
Reply With Quote
Old Jun 27, 2014, 03:43 AM
Registered User
Joined Jun 2012
2 Posts
Google Code repository?

Hi Alan,
I have with excitement been following this project for about four years, but actually just recently tried putting it together! I made new PCB designs in KiCAD, based on some of the contributors drawings, and I am very happy to say that I got it working pretty painlessly.
Looking forward to playing with the modules trough the summer.

I read your most recent post, and the update sounds great, but when I checked the change history over at Google Code there is no changes made to the source since May 19, 2013.., my SVN client tells me the same thing.
Have I misunderstood something, or has your recent updates not gone through to the repository?

Also, do you think 400hz pwm would be fast enough to drive a DC motor smoothly trough a mosfet (by changeing the code so that it does not send servo signals, of course)? I made 10 boards with mosfets on dio06 and dio07 before I discovered that it was only on two dedicated pwm pins (10 and 13 I think it was?) that you originaly could do that. I guess I will have to give it a try when I get my hands on the new source code!

I did not make any 8ch boards, so I can not help you out with that, unfortunately.

Cheers
Kristoffer
pendel is offline Find More Posts by pendel
Reply With Quote
Old Jul 01, 2014, 02:54 AM
Registered User
UK
Joined Mar 2007
343 Posts
Hi Kristoffer,
it's good to hear from people working on this. What features do your pcbs have?

You are right, I have been bad about putting up updates on the code project recently, in getting the faster servo pwm and quadcopter stuff going I have stopped the standard speed stuff working, I wanted to fix that before posting it, I'll try and get something posted soon.

The 5148 modules have 3 hardware pwm out puts and the 5168 has 4. The faster servo code might work for rough motor control but at minimum output the signal is still on for about 50% of the time. In the past I did have a plan to try and do faster software pwm for motor control but the 5168 hardware option killed the motivation. In someways fast motor pwm is easier than servo pwm as jitter does not matter as much i.e. the duty cycle can change cycle to cycle as long as on average it is stable. As long as you can measure the jitter you can correct it on the next cycle.
Cheers
Alan
Alan Hopper is offline Find More Posts by Alan Hopper
Reply With Quote
Old Jul 02, 2014, 07:44 AM
Registered User
Joined Jun 2012
2 Posts
Thanks for your answer,
I realised that it would be too difficult for me to integrate a full 0-100% pwm for the motors into the servo control code (I am not very experienced).
What I now have (with the 50hz servos system still working) is another motor pwm routine using timer0 and software interrupt and a counter to do some pwm magic. I have only tested with two motors so far, but since I made the function similar to the servo function, it can control as many motors as you like (well, MAX_MOTORS = 12 at the moment).
I have not tested it extensively yet, so I can not say for certain if the function I made will introduce servo jitter. I can imagine that if it controls a lot of motors, the interrupt routine takes longer to finish, and that can f something up(or does the servo interrupt have higher priority [can you interrupt an interrupt routine with a higher priority one?])...

I think a separate and scalable software pwm for motors makes sense, as two(or four) pins is not really enough for advanced ground based stuff, like a small tank that has many bi-directional motors. I can send you the code, it will probably give you a good laugh!

The pcb i made is basically a two mosfet and four servo set-up, but I did not really study the datasheet much before I made it, so one of the servo outputs does not work.

Also I made a breakout with reset/prog.mode switches and power regulator.
pendel is offline Find More Posts by pendel
Reply With Quote
Old Aug 05, 2014, 02:12 PM
Registered User
UK
Joined Mar 2007
343 Posts
Hi All,
I have just posted a new version of the code on the google code project. It is rather in a state of flux, but I had set myself a dead line to put something up before my summer hols. It has better support for the jn5168 as a receiver. The servo frame rate can be set to 20,10,5 or 2.5ms, basic quadcopter control is there and can be enabled by editing pilot.c(use at your own risk!)
Now I have unbroken the non quadracopter mode I shall try and get back in the habit of posting code more often. I'm tempted to move the code to Github.
Alan
Alan Hopper is offline Find More Posts by Alan Hopper
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Idea Spektrum DX6 DIY Transmitter antenna replacement using 2.4GHz Wireless network parts? jaskew Radios 18 Jun 17, 2009 12:28 PM
Discussion Sort of DIY 2.4Ghz Spectrum Analyzer village_idiot DIY Electronics 11 Feb 23, 2008 11:55 AM
Discussion DIY +12dBi, increase the range of your rubber ducky 2.4Ghz antenna dalbert02 Aerial Photography 1 Jan 01, 2006 11:58 AM
Antenna for 2.4GHz video transmitter Wile E Power Systems 7 Sep 25, 2001 04:42 PM
2.4Ghz xmit system for a small fortune jas_Qfix Electric Plane Talk 28 Jul 02, 2001 08:37 AM