Ambitious telescope project
The back story...
A few years ago I came across the bs2 and the boebot while doing some research for something else. When I saw this I thought it might be a way of fulfilling a childhood dream of building a robot that actually did something. After about a year of agony I had a little beast that would wander around and do silly things. I eventually ended up using 2 processors for it, a bs2 and another whose name escapes me at the moment. Then along came the propeller boe with it's 8 cogs. "Hey", i thought, "I can convert my beast with 2 brains to a beast with 8 brains". I was proceeding down that path until I got distracted by something shiny and the project fell by the wayside. Now here I am a couple of years later and wanting to rebuild my telescope. As part of this rebuild I decided I wanted to add "computer" control to it. Instead of buying something off the shelf, I wanted to "roll my own" control system using the propeller as the processor.
Why I'm here...
For the same reason everyone else is I guess, knowledge. I'll have much to learn as this project progresses and it is here I hope to learn it.
I've already found info regarding xbee communication that will be useful when I get to the wireless handset piece of the project. I was fortunate to stumble upon it while searching for something else. But because it's easier to ask than stumble, I'll probably be asking a lot of "Where can I find.." or "How do I .." types of questions. Once pointed in the right direction I can usually find my way.
Off to the first step...
To learn spin.
Thanks in advance for allowing me to pick your brains.
Rick Versace.
A few years ago I came across the bs2 and the boebot while doing some research for something else. When I saw this I thought it might be a way of fulfilling a childhood dream of building a robot that actually did something. After about a year of agony I had a little beast that would wander around and do silly things. I eventually ended up using 2 processors for it, a bs2 and another whose name escapes me at the moment. Then along came the propeller boe with it's 8 cogs. "Hey", i thought, "I can convert my beast with 2 brains to a beast with 8 brains". I was proceeding down that path until I got distracted by something shiny and the project fell by the wayside. Now here I am a couple of years later and wanting to rebuild my telescope. As part of this rebuild I decided I wanted to add "computer" control to it. Instead of buying something off the shelf, I wanted to "roll my own" control system using the propeller as the processor.
Why I'm here...
For the same reason everyone else is I guess, knowledge. I'll have much to learn as this project progresses and it is here I hope to learn it.
I've already found info regarding xbee communication that will be useful when I get to the wireless handset piece of the project. I was fortunate to stumble upon it while searching for something else. But because it's easier to ask than stumble, I'll probably be asking a lot of "Where can I find.." or "How do I .." types of questions. Once pointed in the right direction I can usually find my way.
Off to the first step...
To learn spin.
Thanks in advance for allowing me to pick your brains.
Rick Versace.
Comments
I have a bunch of links to Propeller tutorials in post #3 of my index (see signature).
I like Spin. I used to do a lot of Programming in C but I now much prefer to program in Spin. I disagree that Spin has a problem with floating point math. Spin doesn't have native floating point support but there is a nice object which runs in assembly to do floating point math for you. It call "F32" and works great. I'm pretty sure it's faster than trying to use a math co-processor unless you can program the co-processor to perform complex calculations with multiple floating point operations. For single floating point calculations the time required to send and receive the data would take longer than just performing the calculation in the Propeller.
I use F32 to compute the inverse kinematics for my hexapod. Spin and F32 can run the floating point calculations from each of the 18 servo positions faster than the servo refresh rate of 50Hz.
If you need 64-bit floating point math then the coprocessor would make more sense. I know there's an object in the OBEX for communication with the 64-bit coprocessor. I've used the 32-bit coprocessor myself and I'd like to get one of the 64-bit versions. I just haven't figured out why I need 64-bit floating point math yet.
While you're looking at post #3 of my index for Spin tutorials, I hope you check out some of my Propeller projects listed in post #2.
I was looking at the C compiler because I programmed in C long ago. After doing a little reading I became concerned about code size. Should I be?
I'm using a propeller boe I bought a couple of years ago.
The math co-processor is an option I'll look into. If I start coding objects using F32 and decide to use a co-processor later on, will I need coding changes or will it be transparent?
This project is in the I'm-figuring-out-what-i-need-to-know stage so I'll consider almost anything.
Thanks again.
I guess I should read all the replies before responding to one.
Thanks for answering my question before I asked it.
So no co-processor.
I don't think I'm going to need the prop to do too much.
Read 2 encoders and convert the readings to alt/az coordinates ( RA/dec too)
Direct 2 servos to point the telescope
Point to a coordinate in the sky and track if requested.
Wireless operation using xbee.
Also to operate as a dew control system. Monitor temperature and activate heaters as needed.
Anyway. I'll go take a look at the posts.
Thanks.
First, welcome the the forum.
There is also support for hardware co-processors from micromegacorp. Both 32 and 64 bit.
This is the search in the obex for the drivers.
[FONT=Calibri, Helvetica, Tahoma, Segoe, Segoe UI, Arial, Verdana, sans-serif]I.K
Is it possible to execute a piece of spin code from assembler?
Why I ask.
I am using Quadrature Encoder.spin to read encoders that will tell my scope where it is pointing.
What I would like to do is get the code that converts ticks to degrees to execute ...
Pub ReadDegrees | aLast
aLast := altRead
altRead := long[Pos][altCnt] // 5000
long[Deg][altDir] := whichDir(altRead, aLast, long[deg][altDir])
long[Deg][altDeg] := ticks2Degrees(altRead)
aLast := azRead
azRead := long[Pos][azCnt] // 5000
long[Deg][azDir] := whichDir(altRead, aLast, long[deg][azDir])
long[Deg][altDeg] := ticks2Degrees(altRead)
After the assembler routine updates the encoder counts rather than having to call a function to return the values, or eating up a cog by runnuing it in a loop
I did some stuff with z80 assembler long ago and far away so I'm not totally ignorant to the mysteries of assembler, but close.
So if there is a way to do what I am considering or if there is someone who could explain to me what I need to do to make the assembler code do what I want it to...Please help
If not...then I'll figure something out.
Thanks,
Rick.
Not directly. Cogs can not communicate directly with each other. A cog can write data to a hub memory location in order to communicate with a spin program, and the spin program can monitor that location and execute some code based on the data written there.
I was thinking basically the same concept, except use tilt sensors instead of encoders, but don't know if they are sensitive enough.
Phase 2 would involve adding a guide scope onto the project, and a light sensor to do guidance for photography.
Interesting project! Please keep us up to date on your progress.
I have an 8 inch SCT on a motorized equatorial mount. It's nice, but I'd love to add go-to capability.
Good luck and clear skies!
Amanda