Our ArduStation MEGA boards arrived today and I am truly excited to see how they work. Now starts small assembly job for them and then we can start doing testing for those.
Big thanks for Colin for his original ASM work, it's great to see what great minds can create.
New boards looks just awesome. Few connectors are missing but those are quickly soldered. These boards are from the first batch and we have them now small qty in stock. If there are any changes that needs to be made, we will do it and then first production batch will come.
Technical specs:
- MCU: Atmel 2560 with Atmel 8u2 USB "adapter"
- XBee footprint for telemetry with external pins
- IO: Buzzer, Analog, I2C, GPS
- SDCard holder for storage needs
- 128 x 64 pixel Graphics LCD
- 3 x TTL Serial output pins
- 2 x Servo outputs with internal/external power feed
- Encoder port for menus etc use
- Connection for I2C Keyboard
- 4 x LEDs for showing different statues
Jani / jDrones
Comments
@Colin, yeah we noticed that it's a bit beta. My guys are working on it and current mirroring scheme is a bit nono. We need to catch all mavlink packets and then use mavlink send/receive functions to send those forward. As if we just do byte mirroring between ports we will miss timeslots etc and that seems to break all packets.
Ahh, nice one Jani. I missed your tracker post- should be good :)
Yes, I have had mavlink passed through in the past, it's a bit experimental at the moment. I see it as a key feature that we need to have sorted by version 1.0
Once the pass through is sorted properly, it should also be possible to connect a bluetooth modem to one of the serial outputs for pass through to droidplanner
@Colin, have you been using gcs_passtrough?? By antenna box I mean that HeavyDuty antenna tracker unit that we have been working here.
At least on 0.4 version there were some extra chars printed out to USB port along with MAVLink and naturally Mission Planner does not like those as it breaks protocol.
You should have easy way to stop those extra texts coming out from USB.
All I've coded for the SD card so far is the display the contents in the top folder. But I imagine really small will be fine as we'll pretty much just be dealing with text files for logs, parameters and missions. 256mb would be plenty... don't know if they still make them that small anyway...
Paul, I've got similar keys in my PC keyboard- cherry blue. They're really nice. I guess you can buy the up down left right and escape keycaps to go with them, which would look quite nice :)
Knocked together a plotting page, will be in the next version
- the Cherry keys are just nice keyswitches with space for an led ( http://www.digikey.ca/product-search/en?vendor=0&keywords=MX1A-... ) very tactile, simple and clear which is what the ASM is all about for me
- +1 for LEDs on pin headers
- I like the key layout for navigation, push button for ok on the encoder
- if you standardise on an enclousure put a tripod mount on it
- +1 on a zoom servo, I fly solo mainly (not anti-social but young family/not much hobby time/ unsocial hours) and I love the idea of using the tracker function for a 'follow it' camera/video
Paul
Tom, do you mean bearing or heading? The bearing to the uav from the ASM is based upon the assumption that the ASM is facing north. Could it be that you're facing south? When we get compass support this won't be an issue. But also not everyone is going to buy a compass, so we'll have a parameter we can play with to take this into account.
What screen are you seeing a minus sign before the bearing/heading?
Thanks for the pointers Robert. I thought there was something like that, I'll check out those packets. Maybe I'll see if I can get it to recognise the packets and get you to see if the values that come out look reasonable? (probably not til next week)
Thanks,
Colin
Jani, what do you mean by your "main antenna tracker box"? Also, not sure what you mean about finding the pins.. I discovered which pin the voltage sense was on if that's what you mean.
I did have some ideas for hardware changes, I'll probably post back as I remember some more of them...
I think a third servo out should be easy, and probably useful. I'm not sure how we can control zoom on a camera, but I'd like to control bearing, elevation and zoom on a video camera from the ASM. This should enable some pretty good filming capability without a cameraman.
I certainly agree that the keypad could use with having a rotary encoder built in as it makes the world of difference as you say Paul. The exception to this is if someone has plans on designing a 3D printed enclosure for example, where the rotary encoder is mounted separately.
If you have no plans for enclosures Jani, a nice addition would be a cutting template in the kit for us to mark around when making our own.
I agree, the buttons feel a little cheap- I don't know if that's because they're the extra long versions, but they don't register quite as cleanly as other tactile buttons I've used. What cherry keys were you looking at Paul?
One of the reasons I made the keypad i2c in the first place was because at that point I hadn't written the software and didn't know whether I'd want to change the keypad layout. Now might be the ideal time for us to critically review the buttons. Do we need as many as we have? If we assume the use of an encoder should we get rid of a couple? Personally, I find the unit easy to use as it is, but it might look more professional with fewer buttons. Also, my rotary encoder has a button press, which I just map to the centre ok button at the moment.
Also, for the button pad, if we don't have a standardised enclosure, pin headers for external LEDs might be the way to go rather than surface mount. I haven't made use of the LEDs yet, but I imagine they could be useful for something like link status (as with the original ardustation).
-
2
-
3
-
4
-
5
-
6
of 18 Next