I'll design it purely as a mental exercise, also maybe for personal use.
As this is a custom programmed Tz-85A with an Arduino generating servo pulses all bets are off.
I'll design it purely as a mental exercise, also maybe for personal use.
As this is a custom programmed Tz-85A with an Arduino generating servo pulses all bets are off.
Why are you using an arduino to control the machine? You won't be able to use it at any events if thats the case.
EDIT: I remembered the custom control systems rules being more stringent than simply:
4.9 Home Built
If you are using a home built control system you must first clear it with the event organiser and declare it during ‘Tech Check’.
I also know from experience that despite spending hours coding and trying to make sure there are no exceptions to any rules you code in, things still go wrong. Nevermind.
Last edited by Eventorizon; 14th February 2015 at 09:04.
Why on earth wouldn't be allowed to use it at an event? I believe Alex (Shakey) was using one to control his axe.
One thing I would say is that I would switch to an arduino mini for the real thing as it is smaller, lighter and much more rugged.
Due to my reprogramming I wanted a repeatable way of sending servo pulses, both valid and invalid, to the modified Tz85A for testing purposes.
Why would an Arduino be banned from events? After all the Tz-85A has an ATMega8 (aka the original Arduino chip) doing the pulse receiving.
So long as a machine passes the tech-check and behaves in a predictable manner I can't see any difference - although it does sound a little like overkill if I'm honest. There are plenty of machines that run a custom-programmed PIC alongside the PIC that might exist on their speed controller for example, in fact it's something we're looking into at the moment.
Having said that, I wouldn't advocate making anything more complex than it needs to be, and there are plenty of off-the-shelf controllers that will do positional feedback and/or end stops. Never a fan of re-inventing the wheel when a cheap, reliable, off the shelf commodity product is out there that does the job
You're quite within your rights to build automation but you might want to look at adding some code to shut off the output on a switch or second input to switch the output off under your control so if it goes wrong you can quickly turn it off, for example if the pot becomes dislodged.
Finally got it working, hopefully some get some videos tomorrow/later on 'today'!
Turns out it just wasn't handling a function call inside an interrupt service routine correctly and that problem was masked by my custom calibrations in EEPROM getting wiped. But its all fixed now.
All I've done is turn one of the pins from the unused channel, which is an analogue input, into a way of sensing the position of the lifting arm which then stops it if it gets too close to the end of travel in either direction. It doesn't do any fancy major error detection yet but should work okay. The external Arduino is just a handy source of pre-calibrated servo signals on demand, I'm not adding it into the final robot.
I couldn't find any that were ~£30 for 85Amps, the Tz-85A is cheap, plentiful and the controller is nice and powerful due to original purpose of sensor-less brushless motor controlling.
The next tasks are to:
- Get the robot fully armoured and driving around to test handling
- Test the lifter arm mechanism with all the bits attached
- Test the lifter arm mechanism against various test objects
Much further on down the line I need to actually put the battery in an armoured section with padding and see if I can't get some tensioners on the belts or buy tighter belts.
Yay, progress!
Soooooooooooooooo about that video...
I got everything connected back up, plugged in, ordered the samples from TI for a new voltage regulator for the Tz-85A that I've re-programmed, went to put the piston back inside the linear actuator and:
Well bugger.
Looks like I'll be ordering some (more) spares from Gimson! But aside from that I've got it all working well together, one of my motors is still acting funny so I'm gonna replace it with the spare I bought and think about getting another spare for when I kill the other motor.
The fuse/removeable link is sparking due to the high inrush current (~100A) of the 2 220uF capacitors in each of my 3 Tz-85As (1320uF total). Its working for now but I may need to change to XT90-S spark eliminator connectors and bulkhead fuses.
But I have made some progress, right?
Just saw the arduino debate. There's absolutely nothing wrong with using an arduino in a robot, they are fantastic pieces of kit. It's fairly well known by the tech checkers that my axe is arduino controlled and I've never had issue.
As Max pointed out I control the axe in my robot with an arduino nano. The arduino let me input time restrictions, double failsafes and stall prevention (With an option of limit switches on top). Frankly my bot would be more dangerous without it (And even more fire prone :P ). All my arduino is doing is acting as an interface between the receiver and the TZ85 watching the throttle and gear channels turning that into a throttle signal to a (home hacked) TZ85. I intend on doing the same as PINSKI is here with an arduino turning a lifter into a big overpowered servo. I could use tiny ATMEL or PIC chips (and infact have a small tube of ATTINY84's on my desk right now) but I find it easier to just shove a nano in, and the reprogramming on the fly is easier. Plus afterall the chip in an arduino is the same as a TZ85 and after hacking what's really the difference?
Sorry for the hijack. The robot is looking excellent and I look forward to seeing it done, 4 bars are a favourite of mine!
To echo Kane, a switch to turn everything off is a great idea, it's easy enough to have the system look at the gear channel as a can/can't move signal.
Just received my spare Tz-85A and *BAM* immediately modded! It takes me about 5 or so minutes now, and that's mostly trying to find the right hex key and de-soldering the spare ESC wire. The switch removal and shorting and programming is almost instant comparatively! So here's my spare:
I've made a minor modification to my endstop/servo ESC code to fix a problem with the deadband, namely if requestedVelocity > -10 and requestedVelocity < 10 it would clamp it to 0 aka brake however that would mean it would then just jump from 0 to +/-10 the second you were out of the deadband. That's changed now and it ramps up from 0 to 1 to 2 to, well, you get the idea. I've not been able to test it yet but sooooooon.
Bookmarks