I will eventually add GPS to WALTER. I am aiming for something that can navigate a random obstacle course. I’l like to experiement with IK as it applies to arms such as what I plan for WALTER. I need to find out how big to make the cutout for a servo in the bottom deck. I already go dimensions for the holes from the new ASB-04 model I made. Now maybe I can make a proper servo model, based on real dimensions. I’ll pick data for an HS-645MG and use that for the new servo model, unless there are suggestions for something else to use.
Can Tech class access that experimental band range also? I know, I need to go start reading all the regulations again.
I have to admit, I am having a totally fun time with WALTER. Once I get his new body made (11 1/2" diameter octagonal shaped), I will have more places to put stuff. I may end up having to convert him to 12V to keep up with Lynxmotion though, but might wait for that until I build my hexrover.
I very much want to see The BiPod walk one day, and have the assembled brackets sitting on top of my computer hutch.
Here’s a link] to a big, pretty PDF chart showing which license classes have access to what parts of what bands, and another link] to a text-based breakdown of the bandplan within those allocations.
Techs can now access parts of the 80-, 40-, 15-, and 10-meter bands, as well as all allocations VHF (50MHz) and above. This includes the 2-meter band (where that 145 allocation sits), as well as the ATV segments on 70cm and higher bands.
I’ve been talking with the ham that runs BeeLine, and he has a Packet GPS transmitter that would work to send short NEMA #0813 style strings, which can be modified to be the telemetry data I want to send.
It’ll probably start out
$GPGGA
, but it will be a standard AX.25 packet after that.
Looks like $79 for this modified packet transmitter (No GPS).
For my rover project, I plan to use the ATV transmitter’s audio channel for packet data, rather than a separate transmitter, but I like the compact BeeLine transmitter - very slick. It looks like a good option for a walker, for which weight and space will always be an issue. I also like the fact that it puts it up on 70cm. Byonics sells a few models of miniature tracking transmitters for APRS purposes, which operate on 2 meters, but only one of them includes a transmitter that can be tuned away from the usual APRS frequencies.
You mention that the output of the modified BeeLine transmitter would start out $GPGGA and then proceed as a normal AX.25 packet. Do you mean that it would contain the complete GGA NMEA sentence data and tack an AX.25 packet onto the end, or that it would essentially be a normal AX.25 burst, just with the $GPGGA tag at the head of it?
I’ve been tinkering with the TNC-X unit (though not much recently, thanks to other projects), and I’ll have to recheck the docs, but I believe that it will packetize and transmit any serial data that it receives that is bracketed between start bytes C0 00 and end byte 00. These are normally the “bookends” for a KISS packet - which is what it’s designed to handle in the first place - but as long as the data contained between them follows a few simple rules (to avoid the TNC from seeing either C0 or 00 within the data set that it’s supposed to be transmitting), it doesn’t really care what else it’s handed - it just converts it to audio and passes it to the radio.
So long as I include a callsign in each packet - or include code to toss in a periodic ID packet - it should meet FCC identification and transmission format requirements. Although I won’t be sending true AX.25 packets, I’ll still be sending readable data, including my callsign, using a publicly-available coding method. IDing on the audio will be redundant for my application anyway, since it will be riding the audio subcarrier of a video transmission, which will have my call superimposed on the video in the first place. On the other hand, including my call in the header both allows me to verify the validity of the received data, as well as keeping me from having to rewrite things whenever I decide to reuse the code for other projects, which may not include the video portion.
Well, you’ve certainly got your rig figured out. I started looking at cameras, but then I realized the weight involved! Probably too much for a walker. I’ll be doing good just to get some sensors and this packet link on board.
The BeeLine IS slick! And it looks like we’re good to go on it. I was thinking of them, but this works out better. 70cm is a good choice.
I should have said A normal AX.25 packet “wrapper”, with my message starting out with $GPGGA (and possibly a few others) an ending in the checksum *55.
Yeah, that sounds right, and very useable! This time, when I get back to my wheeled 'bot, I’ll just hang an HT and a TNC like the TNC-X on it, and not worry about the weight! That 'bot can actually haul ME around on it (quite fast, too)!
I think that compiles with the FCC regs, I’d have to check. Not to worry! Having the video would be a nice addition; although I was thinking about it more for image recognition an navigation, if I ever get there. Adding the packet to the audio subcarrier in interesting. I like it.
Since I’ll just be using data bursts consisting of straight unencrypted ASCII, per part 97.309(a)(3), the transmission mode should be legally acceptable. Anyone with a TNC capable of displaying the raw received data without trying to unwrap it - in other words: a KISS-compatible TNC - will be able to read the data as plain, unencrypted text. In order to save space and time in the packets, I probably won’t be using text tags to identify the significance of each field, but…
I’ll just be sending positional and telemetry information over the return path, so I should be good to go.
I figure that the onboard mic will mostly be picking up the whirring of the drive motors anyway, so I may as well put that extra audio channel to some practical use. Since the receiving TNC will automatically trigger whenever it hears a data packet, I can switch the audio source between an onboard TNC for data, and a mic for audio, in case there’s something that I want to listen to when it’s stopped, and it won’t try to decode anything until it next encounters a real data burst on the line.
On hand, I have a bunch of 380-line CMOS video cameras, and one 420-line CCD unit. I’ll probably use the CCD for the rover, since that’s the better one of the bunch, as well as being a bit too bulky for my other big amateur TV project.
Since ATV is just analog video anyway, I’ll get all the resolution that I can feed to the transmitter, up to the frequency limits of the transmitting and receiving electronics, minus any multipath, etc. The video overlay unit has a number of font sizes available, plus graphics, but I’ll need to experiment with those in order to determine a good size to fit as much data on the screen as practical without everything running together and obscuring too much of the visual field. Of course, there’s always the option of turning the overlay on and off, as well as having multiple display modes, depending on how much of what I want to see at any time.
That’s all still on the other side of the calendar, as I still have to hammer out control systems and the mobility base. It’s good to have plans to work to though, and working on another ATV project is helping to familiarize me with the ins and outs of the equipment, and letting me experiment as I go.
Thanks for the fill in! I don’t have any small cameras to put on a 'bot yet. Last good video camera I had was a SONY that weighs more then my 'Bot! A 320 would be nice, and not that expensive. The ATV xmitter might be a be a little more!
I suppose you could put up info text for a pre-determined length of time, and then just revert back to your call letters.
I am aiming for something that can navigate a random obstacle course. I’l like to experiement with IK as it applies to arms such as what I plan for WALTER. I need to find out how big to make the cutout for a servo in the bottom deck. I already go dimensions for the holes from the new ASB-04 model I made. Now maybe I can make a proper servo model, based on real dimensions. I’ll pick data for an HS-645MG and use that for the new servo model, unless there are suggestions for something else to use.