ADI

Tve ..... read your above 2 sentences again. Your 2nd sentence is absolutely correct. This is the only purpose for the code.... the timing of external events.
Your first sentence is absolutely wrong though.
Keeping track of the number of clock cycles that have passed, is the method used to time the external events. Take this away and you have no time keeping device.
What were YOU thinking of using to time the external events ???

PS: There are no interrupts used because their overhead reduces the timing resolution.
I wouldn't worry about being off topic. There's no-one here except a small handfull of friends anyway.

Cheers ADI

tve

OK, I understand what you are saying, but my point is that I could write some code to do this without actually counting clock cycles that a section of code takes to execute. I understand what you are saying though.... everything is relative to the system clock obviously.
tve

I just had a chance to test the castle creations controller I purchased.... my first impression is wow. A very nice controller. I think it will probably do the job. Now I have to order 3 more (ouch)

ADI

OK ... I understand. There's no need for an extra utility because the Atmel Studio4 simulator returns the number of clock cycles in the 'cycle counter' when I run the section of code in it. So I don't necessarily have to count by hand, so to speak.
But for this system to work you have to tweak all non branch destinations with a 'nop' instruction, as mentioned in earlier post.
So, if it were to be written in C, you would still have to go into the compiled code and tweak the ASM instructions. Now ... if you have to do this, then you might as well write it in ASM in the first place and therefore have complete control over the system.

Anyway, this whole PPM timing code is very small ... only about 50 ASM instructions

I create libraries.

Cheers ADI

kwaiweng

haha, watching both of you argueing here is quite a bit of fun.. Anyway, both of you are actually correct. C language and assembly language both have their own strength point. I still remember last time when I just started to write the program for my DF, I was using assembly language. At that time, I was also like ADI. I believe that there is nothing cannot be programmed in assembly language. But when I come to writting the PID part, I started to have some difficulty to program in assembly cause as you all know, the PIC16F do not has multiply and division instruction. This forced me to write my own library for the multipliction and division. However, after I have been introduced to C programming, I found that it was much much easier to program in C.

I admit that C has it limitation. For now, if I'm writting the program which timming or memory is critical and need to be precise, I will prefer assembly language. But if I'm writting a program where the algorithm is complex but the timming not so critical, then C language is my only choice. How about if both timming is critical and algorithm is complex? Then just write in C language and insert the in-line assembly language for the timming critical part...

ADI, I think you really should give a try on C language. I believe you will found its advantages. Believe me, for a very complicated algorithm like PID, fuzzy, and even more sophiscated algorithm like kalman filter, people are usually implement it using C language cause it involves complex math function like sin cos function, power and root function and also involve floating point. I'm not saying that kind of function can not be implemented in assembly, but it simply will take you much more development time to write the function alone.... So just give it a try...~!

ADI

Hi Kwaiweng,

Good to hear from you again. You should be using Atmel micros. There are 6 different multiply instructions available with the bigger Atmel micros. Also, I do floating Hex point rather than decimal point. Why use decimal with a machine (DF) that has no need to display decimal or return answers in decimal ? If you can think in binary or hex then you can calculate blazingly fast floating hex point in ASM. This is especially usefull for PID algorithm. We only use floating decimal point because that's the system we were all brainwashed with. Why translate back to English when I'm listening to a Frenchman speaking French ? Why not just remain in French thoughts ?
So, same reasoning with math programming: Why translate the binary math problem to decimal, calculate the answer in decimal, then translate back to binary ?
Anyway .... how's your DF coming along ?

Cheers ADI

kwaiweng

The main reason I use PIC instead of Atmel is because PIC offers free sample. Now I will change to the dsPIC30F6014 as suggested by anthrax. Maybe you all should also give it a try because it has many built in peripherals and the most important one is the instruction cycle is 30 MIPS. Currently I'm still on designing state for the PCB but I'm currently quite busy because I have to write a report for my DF ( I don't like paper work~!) and now is the final exam for my semester.....I will only be free to proceed my DF at december....but anyway, checking this thread is a 'must-do' for me everyday...

danvel

My first DF used a Motorola 68hc11 programmed in assembler; Then I moved to the Cypress PSOC chips programmed in C.
In the begining I just programmed the new PID algorithms using floating point arithmetic and the result was a huge and slow program, I then moved back to the kind of integer arithmetic that I used in my assembly program and I got a wonderful improvement.
So for me the leson to learn is: Writting code in C is definitely easier and faster but you can't just forget how things work underneath.
As an example: someone who always used C to program in PC's may think that n/2 is the same instruction as n/3 but someone used to work in assembler with time and memory constraints knows that there's a huge diference so he'll try to divide always by a power of 2 so the operation underneath will be implemented with a bit shift instead of a complex division.
So ADI: if you're a good assembler programmer you can make a better C programmer.

anthrax

kwaiweng,
You don't need to change to dsPIC30F6014 just try a smaller one dsPIC30F4013 with the same performances with lower pin count.Have a succesful final exam!
HI everyone,
Dont think i already quit this project for the reason i haven't posted to this board for long time.I'm just busy with another tasks and it's not easy to buy some parts to replace broken parts for my DF.However,you see,i always check this thread to find hot news and download some new vids everyday.I will come back to this project in future when have chance.
Good luck to everyone!
PS: i succesfully build my own brushless controller by using dsPIC with build in AD converter and not using external comparator.Very happy with it.
H

ADI

Ah ...... now instead of divide by 3, I would multiply by Hex 00000000 55555555 (space between digits is fractional boundary - hex point) using Atmel multiply instructions. Hex 00000000 55555555 is precisely .333333333 x 2 ^ 32

PS: Here's what I use for PI in Hex 00000003 243F6A87

ADI

tve

I guess the main tradeoff for 32 bit fixed point vs 32 bit floating point is range and accuracy.. For a PID, fixed point would work fine. For calculations with really small or really large numbers it wouldn't work wihtout using more than 32 bits for number representation. I'm not sure of the differences in speed, but I doubt there is much difference between IEEE 754 and fixed point that way. From what I understand an ATMega128 running at 14.7456 Mhz can do ~60KFlops using AVR libc. I was pretty impressed to find that I was able to convert lat/long to UTM in 11mS on the Mega128. The AVR libc floating point is really good. This brings up another point. As Danvel pointed out, dividing by 2,4,8 can be faster because it is a simple matter for a processor to shift the bits right by 1 to divide and left by 1 to multiply by a factor of 2. Any good compiler these days will take advantage of that. I seriously doubt I could write more efficient code than the compiler outputs most of the time.

Feel free to correct me
tve

ADI

This is all very interesting stuff, because the micros we're all working with are relatively slow.
As time goes by we're going to need more and more efficient ways of getting them to perform, with the limited time available. Tve's 11ms example above verifies this problem. 11ms is a very long time in DF terms.

My fixed point example above was just an example. This 'point' can be shifted anywhere you like and it can be 128 bit or 256 bit if you like. It's up to the ASM programmer and accuracy verses time. A point I made earlier on is: why are so many programmers obsessed with the neccessity for 'decimal' floating point, when the machine they are building has no decimal input or output requirement ? I just don't understand the logic. Perhaps it's just the human programmer has got it all wrong. For some reason he believes he must multiply by by 1.1 or 1.2 or 1.3 etc up to 1.9
In hex you have better resolution using just the 2 available digits: 1.1 1.2 ....etc......1.A 1.B ........etc....1.F
Base 10 is just one number system chosen for Christ knows what reason. 10 fingers and toes maybe.
PI for example is not a decimal number as we think it is. PI was here long before roman numerals.
PI is just a relative quantity which can be expressed in a billion different ways, so why do we have this need to force it in decimal form, down the throat of a micro that can only think in binary ?
Geez ...... I'm starting to ramble on here now and I'm stone cold sober too.

Cheers ADI

tve

ADI,
I guess I don't understand why you see fixed point as being so different than ieee 754 floating point? They are both used to represent our base 10 system in binary. The main difference with floating point is that you can represent very large numbers nE10^127 using only 32 bits. The reason everyone (almost) uses such a standard is because it covers almost every mathmatical need while only taking 32 bits. Sure you can make either of these concepts 128 bits or 256 bits, but then it will be slower than using 32 bit ieee 754. I agree about base 10.... base 12 would have been better. instead of 1,2,5,10 factors you would have 1,2,3,4,6,12. How about base PI? That would be fun....

As you already mentioned, the processors we are using now only see two states: 1,0 on/off regardless of what way we choose to represent a number system. One nice thing about fixed point, is that you don't need to take a lot of rom resources to do a few simple calculations. Once you start using the trig functions and log functions, then I really don't see much advantage.

I agree this is an interesting discussion. I'm definitely learning from it.

kwaiweng

ADI:

Regarding the method you used to make your PCB, did you print the pattern of the PCB on transparency? I try to print it on transparency but the track seems like not dark and opaque enough. I heard that some ppl print it on tracing paper and it works too. May I know how long you exposed your PCB to the UV light?

ADI

I print on inkjet coated white paper with inkjet printer. Coated paper gives much better printing resolution than plain paper. The pre-sensitised PCB is Kinsten brand which uses positive artwork.
UV exposure is about 24 minutes with 15 watt UV lamp and results are excellent every time.
I couldn't find a decent transparency inkjet clear film. This would have reduced the exposure time.

ADI

kwaiweng

now I'm trying to print it on the tracing paper....this could reduce the exposure time. But I'm using normal fluorecent light instead of UV light, I think I will need a longer exposure time...

ADI

What brand of pre-sensitised PCB are you using ?

ADI

kwaiweng

same as u...Kingsten.


BTW, how did u calculate the optimum exposure time? through experiment?

ADI

Yes .... this will depend on the wattage of your UV lamp and distance from PCB etc.

ADI

kwaiweng

Hi all,

I'm currently in the progress of building the new version of my DF. I will change the motor to GWS IPS motor (Ratio 5.9). Perhaps it will be a lot lighter and give me longer flight time.

Anybody know what is the optimum distance between the opposite rotors? (measure from center to center of the propeller). Or anybody know the dimension for DraganFlyer, X-UFO, Intellicopter or other commercialised Quad Rotor? I will be very appreciate if you all can tell me the dimension of your DF too...thanks~!!!

ADI

Hi Kwaiweng,

DraganFlyer dimensions are available at their website. Check out this page though: http://www.radiocontrolled.com.au/news_and_events.htm
Go down the page to 'Long arm upgrade kit' You might find it interesting.
My DF prop shaft center to center = 485mm

Cheers ADI

Spaceclam

maybe it would be easier to fly if i made my arms longer...
great thought, but that means buying all new motor mounts, since i will never get these out...
Damn,
-Clam

danvel

My DF prop shaft center to center = 465mm. Most part of the inertia of the DF comes from the mass of the motors; this inertia is proportional to the square of that distance so that the longer it is, the slower it will react so it's easier for the motors to control the motion. In general, for any control system the actuators need to be faster than the system they have to control; otherwise unwanted oscillations will appear. Another good way to increase inertia without making the DF too big is using 4 batteries close to the motors instead of a single one in the center (like TVE's big DF). Unfortunately this adds complexity and cost to the system.

kwaiweng

Since everybody is quiet here, then I would like to share that there are some new intellicopter videos at http://ovirc.free.fr/Tribelle.php

it really flies great~!

ADI

I'm having trouble finding some decent pics on the web of the intellicopter.
Anyone have any links ?

Cheers ADI

danvel

This may be interesting for those of you using the phoenix10 for your DF's. I've just discovered that you can reduce the response time of this ESC from 0,2sec to less than 0,1 sec!. Just disable the soft-start feature (I thought it was just for startup but it delays stick response in all the motor range).
I haven't tried it yet on my DF but I expect to be able to increase some control gains making it even tighter without getting oscilations.
TVE: Have you flown your DF yet?