Need help with 255 Variable

I know never to allow a pwm to reach or exceed 255 due to the serout command. However can I create a variable and allow that variable to exceed 255? Also do i need to assign it as a word instead of a byte to allow it to work?

The reason i need this is for the pump delay I created. It currently uses 2 variables which both max out at around 240. The way its set up it gives me 11 seconds between times the pump cycles. The problem is I only lose 3psi in 11seconds from full (115 psi). I want to increase the delay without adding a 3rd variable.

Another question… With my current code the pump doesn’t turn on until 11 seconds into the match (due to the variables counting up). Is there a way to start the variables at a certain value other than zero so that the pump turns on right away and then returns to its normal delay cycle?

You don’t need to create a variable that’s a word. If all you need is a counter, you can simulate a word with 2 bytes. You’ll be able to count up to 65536.

pseudocode:

byte i, j

i = 0
j = 0

main loop:

if (i < 255)
{
i++
}
else
{
i = 0
j++
}

Mike

*Originally posted by Joseph F *
I know never to allow a pwm to reach or exceed 255 due to the serout command. However can I create a variable and allow that variable to exceed 255? Also do i need to assign it as a word instead of a byte to allow it to work?

  1. If you’re exceeding 255 in any variable and don’t want loss of data to occur, it needs to be a word variable.

  2. The RC itself can handle any PBasic supported type of variable in your code. Where you run into the problem is if you try to put that variable in Serin or Serout. So, if the variable in question is in neither of these lines, you can do whatever you want with it.

>…can I create a variable and allow that variable to exceed 255? Also do i need to assign it as a word instead of a byte to allow it to work?

Never increment a byte variable past 255. If you do it will wrap around, i.e. 255+1=0. If you need to hold a larger number, declare it as a word. This lets you count up to 65535 before wrapping around to zero. One variable declared as a word takes up exactly the same amount of variable space as two variables declared as bytes.

If this still isn’t enough, you can add a bit or two from another variable that you’re not using all of. For example if you’re using a byte variable for something that never gets higher than 15, declare it as a nibble instead (4 bits) and then use the other half of the byte to extend your count. Each added bit doubles how high you can count, but you’ll have to increment it manually when you detect that your word variable is going to roll over.

>The reason i need this is for the pump delay I created.

Isn’t there a pressure switch in the kit that you can feed back into one of the digital or analog inputs? Maybe someone else can add more details on this approach.

>Is there a way to start the variables at a certain value other than zero so that the pump turns on right away and then returns to its normal delay cycle?

Yes. Before your main loop you can initialize the variable to one less than the max number, that way the next time it gets incremented you’ll turn on your pump and reset the count back to zero. Just make sure that the initialization statement is BEFORE “MainLoop:”.

Thanks everyone for your speedy replies. I’ll post what I did so that anyone else with a similar question or whoever is curious can see the program.

After posting I went into the stamp editor and created a test program. I checked back today for the answers and then double checked my program. I finally ended with…

in the Declare Variables Section
longpump Var word 'pneumatic pump delay

in the Initialize Inputs & Outputs Section
longpump = 870

Below the PWM Output Section I created a new Pnuematic Pump Delay Section In it read:

longpump = longpump + 1
if rc_sw1 = 0 then nopump
if p4_sw_aux1 = 1 then pumpon 'pump turns on when pneumatics fired
if p4_sw_aux2 = 1 then pumpon 'pump turns on when pneumatics fired
if longpump < 900 then waitpump
if longpump > 799 then pumpon
nopump:
longpump = 0
waitpump:
relay6_fwd = 0
relay6_rev = 0
goto pumpdone
pumpon:
longpump = 810
relay6_fwd = 1
relay6_rev = 0
pumpdone:

Since the delay was so long I added a feature that would automatically turn the pump on whenever I fired the cylinders. FYI our system only leaks about 3psi every 20-30 seconds which is why I needed such a large delay… I may make it even larger.

My old code for anyone interested used variable coun and pump (both bytes) and read

'coun = coun + 1
'if rc_sw1 = 0 then pump_off
'if coun < 220 then pump_off2
'if coun < 250 then pump_on
'pump_off:
'coun = 0
'pump = 0
'pump_off2:
'relay6_fwd = 0
'relay6_rev = 0
'goto nextstep
'pump_on:
'pump = pump + 1
'if coun < 235 then extr1
'coun = coun - 1
'extr1:
'if pump < 220 then nextstep
'relay6_fwd = 1
'relay6_rev = 0
'coun = coun - 1
'pump = pump - 1
'nextstep:

(of course without the ’ marks). It took the same amount of variable space but gave a much smaller maximum pump delay (only 11 seconds as set up, max of roughly 15-20 seconds)

i forgot to add. both these programs are tested and work as they are written in the manner in which they were intended. I have yet to find errors in either. (although there may be better ways of doing it).

OOC, Why are you using the delay method? We’re given TWO sensors in this year’s kit. You use both, and tie them to a pair of input bits. Simply set one to the high shutoff value you wish, and the other to the low turn on value.

Now your code is a couple line hysteresis routine, and you’re done!

The code for this was given both in several threads here, as well as in one of the team updates.

  • Keith McClary, Advisor, Huron High 830 Rat Pack

One team near mine only got one pressure switch, so I helped them with a timer.

It sounds like the thread was started by some one using the pressure switch to turn off the compressor. What happens if you have a little leak and never get that high a pressure ?

Perhaps you should readjust the switch to turn on the compressor at some user-selected lower pressure, and use the software timer to turn it back off. That way, if your pump can get the pressure above the low set point, the pump will turn off sometime, and you’ll still have some pressure.

It sounds like the thread was started by some one using the pressure switch to turn off the compressor. What happens if you have a little leak and never get that high a pressure ?

Yes. I am using the switch to turn off the compressor. We don’t have any trouble with leaks in our system currently, in fact it takes us roughly 20-30 seconds to lose 3 psi due to leaks. The compressor can easily overcome that to fill the system. Plus if we do use the pressure switch to turn on the compressor and a timer to turn it off, what happens if we misjudge the timer? The system will go above 120psi and the safety valve will pop (and i believe the valve is a one-use valve). I may be wrong about the valve, but thats my current understanding.

OOC, Why are you using the delay method? We’re given TWO sensors in this year’s kit. You use both, and tie them to a pair of input bits. Simply set one to the high shutoff value you wish, and the other to the low turn on value.

Sodder breaks, programs don’t. I am worried with 2 switches that its twice as much sodder that can come lose and cause a wire to slip out messing up the system. In a 2 switch system if the high switch loses connection the system will cycle at the low pressure. If the low switch loses connection the pump will cycle at the high pressure. This can overheat the pump and kill the battery very quickly. In a single switch system if the switch loses connection the pump shuts off. While this does lose all our pneumatics for that round, we aren’t totally dependent on them and can do quite a bit without them.

If you exceed 120 psi, the valve starts leaking. When you drop back under 120, the valve closes again.

If you exceed 120 psi, the valve starts leaking. When you drop back under 120, the valve closes again.

thanks for the clarification.

*Originally posted by Lloyd Burns *
**One team near mine only got one pressure switch, so I helped them with a timer. …] What happens if you have a little leak and never get that high a pressure? **
If the leakage is THAT bad, you’ve got OTHER problems! :slight_smile: But to answer your question, the compressor keeps running, and the overpressure valve keeps you limited to 120psi. In any case, two minutes of the compressor running and popping the safety valve isn’t going to kill you, nor your battery.

** Perhaps you should readjust the switch to turn on the compressor at some user-selected lower pressure, and use the software timer to turn it back off. That way, if your pump can get the pressure above the low set point, the pump will turn off sometime, and you’ll still have some pressure. **
Now it DOES makes sense to use a timer as a failsafe, but it is really not necessary for normal operation. You can simply limit the maximum on time of the pump for any one “air request” and lock it off until either a pressure switch toggles, or a driver “manually override resets it” by some action on the OI such as running an unused thumbwheel up and down once.

Originally posted by Joseph F**
[Solder] breaks, programs don’t.**
LOL! You never heard of a program breaking under “unexpected conditions”??? It’s called a “bug”. :wink: (Maybe he’s never programmed, nor tried to run a Microsoft product before…:wink: ). Seriously though, in industry we more often use HARDWARE to protect us from SOFTWARE bugs than the other way around! Most of the time for cost savings Consumer software only does “sanity checks” to keep an eye on the hardware, and simply alerts the user to problems. In military and automotive programming though we do often spend the extra time, money, and effort to try to “program around failed hardware”.

** {I’m worried about [solder] joints failing, and here are the failure modes} …]**
Actually, a good solder joint is VERY reliable, as long as you have a good mechanical initial connection before soldering, and strain relief on the harness. In fact, they’ll normally far outlast the rest of the system (including the computer) by decades! :slight_smile:

BTW… That’s not how a two switch system works, nor how it would fail.

You have a one bit variable as a “memory”, that decides if the pump should run or not. It will be sent to the pump control at the end of each main loop. For system insurance in case everything fails, you initially set it to ON in the initialization routine so in the absence of any other signal it tries to start up.

During the loop, the High switch turns the pump bit OFF when pressure EXCEEDS it’s setpoint. The Low switch turns it ON when it drops BELOW its set point. Between it the “memory” keeps the same condition. This gives you your hysteresis. The Low and High switches are set at something like 110 and 120 PSI respectively, so if you have a failure mode that causes an oscillation around EITHER ONE, you’re still fine.

Seriously though, you’re talking only TWO solder joints per switch. That’s EASY to inspect. You can use input bits on opposite ends of the connector if you’re nervous. If you’re uncomfortable soldering, just let someone who is used to doing it make the joints. Now for the switch, just make sure you add some lock washers under the switch screws, and that will be secure.

If I remember correctly, these are normally closed switches that open when you exceed the pressure on a diaphragm. Switches CAN fail open or closed mechanically, but the most likely failure mode will be open from a loss of a connection, with a failed closed condition from a diaphragm break in the switch running a FAR second place. These switches are designed for millions of operations, and the mechanics in them don’t break often.
Shorted electrical connections would normally be obvious during testing.

Let’s look at the failure modes:

CASE 1 - HIGH switch disconnects or fails OPEN: depending on which switch is checked first in your logic, the pump either never starts up, or the pressure oscillates around the low pressure switch’s pressure. Assuming you’ve set the low switch to something like 110 PSI (10 PSI hysteresis), if it is oscillating around that value you’ve still got FULL pressure to do things because the rules say your pneumatics must run at 60 PSI max. However you ARE allowed to start with full pressure, so if you set the logic so that this mode causes full failure and this happened before the start of the round, you’d notice your pump wasn’t running then and have a chance to fix it. If it happens DURING the round and your pneumatics are only used for deployment and not motion, then given enough air storage you may not even NOTICE things stopping! Either way, no robot damage.

CASE 2 - HIGH Switch shorts or fails CLOSED: The pump keeps running, and the safety valve keeps popping, limiting the pressure limited to 120 PSI. That is noticeable, but your robot keeps running just fine. This won’t damage the pump. For two minutes, since it won’t even stall the pump from overpressure, it probably won’t even impact your battery significantly. No robot damage, and you keep running just fine.

CASE 3 - LOW Switch disconnects or fails OPEN: Depending on the logic, either the pump never starts up, or else you go up ONCE, but never turn back on again after the first fillup when the pressure comes down. Similar situation to Case 1.
No robot damage, and you may not even notice it at first.

CASE 4 - LOW Switch connection shorts or fails CLOSED: The pump will run up to the high pressure once, then oscillate around the high pressure switch. This case DOES use up more battery, but again you’ve got full pressure so the robot runs fine. As before, no damage, and this would be noticeable on the Tether so you can correct it for the next round.

NONE of these situations are destructive to the robot, and you can operate just fine in several of them. You can INSTANTLY tell which switch failed by the pressure it oscillates around, if it doesn’t restart, or it doesn’t shut off and pops the valve.

If you’ve added enough air storage, and only use the pneumatics for “deployment” instead of something cyclical like “walking”, there’s a good chance you may not even run out of air before the round ends.

I still feel two switches is MUCH simpler. However, I do like your concept of using timers to limit effects as a backup.

Of course if you wish (and are REALLY bored), you can always review each case, and create the logic to test and handle error cases. For example, if you see the LOW switch thinks the pressure is too low AND the HIGH switch thinks it is too high, something is not right. Watching which one the pressure toggles around tells you the OTHER switch failed, and you fall back to a timer method using the good switch. The two switches now gives you REDUNDANCY.

But that makes the whole simple thing complicated again! The point here is that using two switches is SIMPLE, and it won’t damage anything in ANY of the failure cases.

If you are REALLY worried about an automatic pressure control failing, then simply give your driver an “override switch”. You run a “monitor” timer in the RC, and have it turn on a driver’s LED if the program thinks the pump “has run too long”. The driver then has an ON/OFF/ON SPDT Override Switch for manual pump control. Run the center to ground, and each of the two ends to to an input bit on the OI. Center = “Automatic”, up = Manual On, and down = Manual Off. You can also do this with an unused thumbwheel as well by dividing its possible position value into thirds.

  • Keith McClary, Advisor Huron High 830 Rat Pack

LOL! You never heard of a program breaking under “unexpected conditions”??? It’s called a “bug”. (Maybe he’s never programmed, nor tried to run a Microsoft product before… ). Seriously though, in industry we more often use HARDWARE to protect us from SOFTWARE bugs than the other way around! Most of the time for cost savings Consumer software only does “sanity checks” to keep an eye on the hardware, and simply alerts the user to problems. In military and automotive programming though we do often spend the extra time, money, and effort to try to “program around failed hardware”.

I wasn’t talking about all programming. I’m talking specifically about the robot program. The conditions of the match shouldn’t be far enough outside the realm of normal capabilities that it would cause the program to crash.

Actually, a good solder joint is VERY reliable, as long as you have a good mechanical initial connection before soldering, and strain relief on the harness.

Given the specifics of the competition odds are a wire will be ripped off long before the program gets confused enough to crash. Plus we dont have anyone who actually ‘knows’ how to sodder propperly, so our joints are probably sub-standard.

If you are REALLY worried about an automatic pressure control failing, then simply give your driver an “override switch”.

I did program in an ovverride that turns the pump on whenever the pneumatics are fired. As for a manual on/off/auto switch its a good idea I hadn’t concidered. I’ll probably set up as much of it as I can until I actually get the robot back.

You can also do this with an unused thumbwheel as well by dividing its possible position value into thirds.

A good idea, unfortunately our control board has all but 1 switch in use currently. I programmed in a turn corrector controlled by our last availible wheel (our robot turns right for some odd reason).

Of course if you wish (and are REALLY bored), you can always review each case, and create the logic to test and handle error cases. For example, if you see the LOW switch thinks the pressure is too low AND the HIGH switch thinks it is too high, something is not right. Watching which one the pressure toggles around tells you the OTHER switch failed, and you fall back to a timer method using the good switch. The two switches now gives you REDUNDANCY.

wow. um. I am going through robot withdrawal currently but I havn’t achieved that level of desperation just yet… Actually its probably not as bad as it sounds, but of course this would assume I put in and soddered up the second switch. I might write the program for this eventually anyway, just for future refrence.

Thanks for all the help. I’ll be printing out this thread eventually to keep all this usefull information.

*Originally posted by Joseph F *
** The conditions of the match shouldn’t be far enough outside the realm of normal capabilities that it would cause the program to crash. **
I’ve never seen the robot program actually CRASH before. Stuck in infinite loops maybe, run out of time and miss a packet maybe, but have you actually had the computer CRASH on you?

What I’m talking protecting against in a program are LOGICAL errors. For example, if a timer variable is not checked correctly, it wraps around (overflow/underflow) forever and therefore never switches things to the next state.

** Given the specifics of the competition odds are a wire will be ripped off long before the program gets confused enough to crash. **
Hmmm… Well, that may or may not be true, because boy oh boy, have I seen some real doozies that passes for “software” in my day… :)… But, you’ve got a very good point that this IS a physical event and wiring COULD get ripped out. That’s why we tried to run things where any Battle Bots present couldn’t get at them. :wink: You’d have to break the chassis apart (or go at it with diagonal cutters in the cranny of some L-channel from the INSIDE of the robot) to get at some of our wiring. :slight_smile:

** Plus we dont have anyone who actually ‘knows’ how to sodder propperly, so our joints are probably sub-standard. **
Have your Electronics teacher check your work. If HE (or SHE) can’t tell a good from a bad soldering joint, you’ve got OTHER problems at your school… :wink:

(BTW… it is “soldering”, not “soddering”… )

Here are a few links for you on soldering to get you started:
http://www.circuittechctr.com/guides/7-1-1.htm
http://www.epemag.wimborne.co.uk/solderfaq.htm
http://www.aaroncake.net/electronics/solder.htm
There are lots more good references on the web. BTW, for practice, I’d recommend simply taking an old PCB and some wire out of some dead home electronics appliance or toy, and solder wires onto it anywhere until you’re comfortable that you can attach and detach a wire cleanly to a board or a connector.

** I did program in an ovverride that turns the pump on whenever the pneumatics are fired. **
What turns it off? Only time, or does it go back across the high pressure setting then run the clock again? BTW, watch out for the logical possibility of the pump trying to switch on from your override, then off because the high pressure switch has not responded yet due to lags and thinks it is still “at pressure now”, then back on again once the pressure switch responds a fraction of a second later. That quick “ON/OFF/ON” cycling COULD stall the compressor if the back pressure is too great from the first short “on” burst.

** As for a manual on/off/auto switch its a good idea I hadn’t concidered. I’ll probably set up as much of it as I can until I actually get the robot back. **
If we’re allowed to do it NOW (are we?), I’d just recommend making a switch with a connector on it to plug in to an unused OI port (or if you don’t have an unused one make a male & female “feed through” connector to stick in series with one of the current joystick connectors to tap off the AUX1 and AUX2 pins you need for the switch). I’m not sure if that is legal now that the six weeks is over. Someone please comment on that.

BTW, we planned ahead JUST for THIS kind of problem. Our auxilary control box brought out a LOT of extra signals “just in case”. We’re only using three of the ports, so we fanned out an ENTIRE port connector (4 pots and 5 bits) onto a terminal strip in our Aux box, so in case of emergencies like this one we already have extra controls available and wired at our panel, ready to instrument program fixes. If we need a new control at the contest site, we drop another pot or switch of the right type with short wires hanging off the back into the box panel, connect the wires to some unused bits on the terminal strip, label it in magic marker, and just USE it… NO soldering required. All of the rest of the current controls (other than Flightsticks) are also taken to lugs and a terminal strip inside the Aux box, with spare wire length, so we can move things around to reassign them to ANY aux channel, if necessary, in only seconds. Theoretically, other than punching the new hole for the control in the box, ANY control mods OR ADDITIONS should only take minutes on site.

** A good idea, unfortunately our control board has all but 1 switch in use currently. I programmed in a turn corrector controlled by our last availible wheel (our robot turns right for some odd reason). **
You’ve used up ALL FOUR PORTS??? WOW! You must be controlling an OCTOPUS! :slight_smile:

Does that include fanning out the extra pot and the two aux bits for the CH Flightsticks as well??? (A port has four pots and four digital bits, but a CH Flightstick only uses three pots and two of the bits). If so, that’s a LOT of controls!!! (SIXTEEN pots and SIXTEEN bits!) If not though, you’ve got two extra bits and an extra pot available on EACH joystick that you can tap. Add an “inline feedthrough” connector (male/female pair) to a port which just brings each wire across to its counterpart for the original device plugged into it, and tap off whatever signal you need. FRCtech2002 ruled we can secure wiring with hot melt glue, so encase the entire thing in hot melt to form an insulator and make a “brick” out of it. Now you can tap into ANY unused signal pin without disturbing the thing orignally plugged into it. :slight_smile:

**wow. um. I am going through robot withdrawal currently but I havn’t achieved that level of desperation just yet… **

<chuckle>… :slight_smile:

** Actually its probably not as bad as it sounds, but of course this would assume I put in and soddered up the second switch. I might write the program for this eventually anyway, just for future refrence. **
As I said, the program is already written for you in Team Update #5. It is only a TWO LINE program! (Plus a couple of aliases…) Just drop it in now, assign the right input bits for it, and comment it out for the time being so it’s ready to roll if other things don’t work out.

**Thanks for all the help. I’ll be printing out this thread eventually to keep all this usefull information. **

Hey, no problem! Although this is our team’s first FIRST contest, I’ve been a professional programmer and a robotics hobbyist for a LOT of years. If there is anything else I can do to help, please feel free to drop me a line.

Later!

  • Keith McClary, Advisor Huron High 830 Rat Pack

The auto/off/on option is a very good one. We have used it the past two years and it is very useful. I did it this year by using a two-position rotary switch for the Auto/Off selection. (The rotary switch was solely for looks. A toggle switch works fine.) Use a momentary pushbutton for the On function. This is useful if you lose a pressure switch (which I have never had happen) and also for testing things in the pits. If you are testing out the drive train and don’t want your pump coming on every 20 seconds you can switch it to off. You will also want to use a momentary switch for the On function so you do not inadvertantly run the pump all the time. Check out our control system here. This is the code I use for the OI pump control:

if sw_pump_auto = 0 then end_override: 'OI Pump Switch set to Automatic (UP position)
if sw_pump_on = 1 then run_pump: 'OI Pump ON Override Switch is pressed

pump_on = 0 				'OI Pump Switch is Off
goto end_override:

run_pump:
pump_on = 1
goto end_override:

end_override:

As far as one pressure switch or two we started this year with two and decided to go with one for weight. (Hey, 15 lbs over with cause desperate measures.) Regardless, we have noticed no change in performance. Here is the code we use for the one pressure switch control:

'Pressure Switch Program adapted from David Mittelman
'This program will allow us to bring the pressure up to 120psig
'and at the same time not overwork the pump
'For this program to work to variables need to be declared and have the following values:
'lastpressure = 1
'pneum_counter = 0

relay1_rev = 0

if pressure_115=0 then switchopen: 'Is the switch closed right now?
pump_on = 1 'compressor on
goto endroute: 'goto A
switchopen:

if lastpressure=0 then nochange: 'Was the switch closed before?
pneum_counter = 0 'reset counter
goto endroute: 'goto A
nochange:

if pump_on=0 then endroute: 'Is the compressor even on?
if pneum_counter < 220 then pumpitup: 'Is the counter equal to the time?
pump_on=0 'compressor off
goto endroute: 'goto A

pumpitup:
pneum_counter = pneum_counter + 1 'increments counter

endroute: 'A
lastpressure = pressure_115 'lastpressure = Switch value

I hope this helps. Any questions, post them here.

*Originally posted by CaptainPlaid *
The auto/off/on option is a very good one. We have used it the past two years and it is very useful. …] Use a momentary pushbutton for the On function. This is the code I use for the OI pump control: …]
Using a momentary switch is an excellent point, and probably a good idea. It would be good to point out that the “override code” goes AFTER the normal pump handling code in the program (and before the SEROUT command), so it IS an override… :slight_smile:

**Check out our control system here. **
VERY pretty! BTW… What is the “glasses” jack all about on your control panel??? Do you have some VR thing going??? :slight_smile:

We made our case out of painted, sanded 1/2" plywood, with a replaceable top panel of aluminum. VERY quick to make. This allows us to swap out the top panel quickly if a revision is made.

The footprint is identical to the footprint of a pair of CH Joysticks. Our top panel is EXACTLY 11" long, and less than 8.5" wide. This allows us to use DTP (Desk Top Publishing) to print a NICE paper legend sheet with any printer (in landscape mode) that also can be changed quickly. It is sandwiched in a standard plastic single sheet protector available in any office supply, and is held in alignment on the top panel with the same screws that hold the panel onto to the box.

I see you’re using push/pull pop-latch connectors to open your panel. The bottom of ours is simply open, with L-brackets facing inwards. It is held to our main “shelf” control board via Velcro. This allows us to simply “grab and pull” the box open in less than a second for access without hauling out a screwdriver.

BTW, this year, our custom Aux Box is our “Weapons Officer’s” Station, and is intended to contain all “exotic” controls and monitor LEDs. For simplicity, our Driver’s Station is just the pair of CH Flightsticks, with all auxilary functions and adjustments mapped onto the various buttons and thumbwheels. However, since the Aux box’s VELCRO footprint matches the joystick pair’s Velco EXACTLY, if we ever desire to do something strange for the Driver’s Station, we simply replicate another Aux Box, and instrument it differently.

This creates our Standard OI Board, that won’t change from year to year. Although one Station has room for 3 joystick equivalents, we also have a “Mini-Aux” box designed with the footprint of ONE joystick, in case we ever want to do a “mixed” control station of one joystick and one Mini-Aux box, or a Mini-Aux box sandwiched between a pair of CH joysticks.

  • Keith McClary, Advisor, Huron High 830 Rat Pack

Have your Electronics teacher check your work. If HE (or SHE) can’t tell a good from a bad soldering joint, you’ve got OTHER problems at your school…

electronics teacher? I wish we had one of those! A tech teacher would be nice to… maybe even a shop class. Closest we have is physics classes.

What I’m talking protecting against in a program are LOGICAL errors. For example, if a timer variable is not checked correctly, it wraps around (overflow/underflow) forever and therefore never switches things to the next state.

That is something I took into concideration. I posted my program earlier in the thread if you care to look at it. Notice it uses a word, but doesn’t even pass 1000. When the counter starts running once it passes 900 (i think thats what i have it at currently) the compressor turns on and as long as the compressor is on it resets the value to 910 every time it goes through the program. That way if for some odd reason the timer jumped unless it jumped above 65536 from below 900 everything should run fine.

You’d have to break the chassis apart (or go at it with diagonal cutters in the cranny of some L-channel from the INSIDE of the robot) to get at some of our wiring

Given the shape of our robot our wires aren’t as protected as we would like. Most of them are fairly safe and would take quite a stretch to get at, but a few (like the one for the airtanks) are a bit closer to danger than we would like. If we are underweight we may add some sort of protection at the competition.

What turns it off? Only time, or does it go back across the high pressure setting then run the clock again? BTW, watch out for the logical possibility of the pump trying to switch on from your override, then off because the high pressure switch has not responded yet due to lags and thinks it is still “at pressure now”, then back on again once the pressure switch responds a fraction of a second later

It’s turned off when the pressure switch is tripped, however unless I fire the pneumatics a second time it wont turn on again until the timer triggers it. The timer turns the pump on. The pressure switch turns it off. So at worst it should go on, then off right away and stay in the off state for a short period of time. Also in your previous post… Didn’t cases 1 and 3 have this on, off, on problem? The “oscillating” around either the high or low switch.

If we’re allowed to do it NOW (are we?),

I didn’t mean have a switch wired up ready to be tossed on. I meant set up the switch controls in a copy of the program I have saved so that i’ll know exactly what I need to do when at the competition.

You’ve used up ALL FOUR PORTS??? WOW! You must be controlling an OCTOPUS

What I meant was we’ve used up all the switches we currently have, and soldering wires in the pit is not something i’m looking forward to. We used the joysticks on ports 1 and 3. The tank drive takes away some of port 2’s controls and our port 4 controls also take over the aux on port 1. We could add stuff to port 2 if we really needed… It just doesn’t seem quite neccessary yet.

As I said, the program is already written for you in Team Update #5. It is only a TWO LINE program! (Plus a couple of aliases…) Just drop it in now, assign the right input bits for it, and comment it out for the time being so it’s ready to roll if other things don’t work out.

Good tip. I’ll be sure to do that.

What is the “glasses” jack all about on your control panel??? Do you have some VR thing going??? :slight_smile:

Well, we all know that you have to wear safety glasses while you are driving (although personally I don’t think saftey glasses would help if something made it through the plexiglass of the driver station). You might as well have somewhere to plug them in right? Come see Big MO at Cleveland, GLR, or Nats.

Your control system sounds nice but the description is quite confusing. Any pics? I like the modular idea. We have decided to keep all of our robots together though so we can make a new controller every year. Takes time but also allows for creativity.

*Originally posted by CaptainPlaid *
** Well, we all know that you have to wear safety glasses while you are driving (although personally I don’t think saftey glasses would help if something made it through the plexiglass of the driver station). You might as well have somewhere to plug them in right? Come see Big MO at Cleveland, GLR, or Nats. **
What, is that just a mechanical “retaining wire” while operating, a “storage clip” for between rounds, or are you actually putting blinking LEDs on your glasses or some other active, wired thing? :slight_smile: (IMO “blinky glasses” would be interesting, but I think that violates the “no special clothing” rule, and could even become an entanglement hazard around the Operators Station!)

BTW… What is your team NUMBER, and your True Name, “CaptainPlaid”??? :slight_smile: The Big Mo page cited doesn’t have your team number, nor a link to your main site, and you haven’t mentioned your real name in this thread.

Your control system sounds nice but the description is quite confusing. Any pics? I like the modular idea.
We’ll be at Buckeye (Cleveland OH) and GLR (Ypsilanti MI). I don’t have any pics yet, but some other members do. However, I don’t think they’ll be up before Cleveland, so just stop by and see 830 (Rat Pack) at the contest.

Let me take one more crack at describing the box… If this doesn’t suffice, I’ll have to work on a REAL document, with pictures.

First, our main board is simply a 4’ x 12" piece of 1/2" wooden shelving, used in bar and hook shelves. Layout is VERY similar to the boards used in the CDI contest, with the OI in the middle, and two “user stations”, one on either side:

We were in the CDI, and liked the layout, so we did something similar for this, our first contest. The joysticks are held down with 1"x1" velcro squares, to allow for quick R&R or something else to be placed there. We used the velcro cable ties from the kit, not wiring channel, but the LAYOUT is similar.

We set up a Driver’s station with a pair of joysticks, as is shown in the picture, but replace the OTHER station with an Aux Box that drops into the same space.

The basic Aux Box is made with 5 pieces of 1/2" plywood, held together with drywall screws, not glue, to allow disassembly if needed. It has four sides and a top, with the bottom open. OUTSIDE dimensions are around 13"w x 6"d x 4"h, (hack off ~.5-1" for INSIDE dimensions) which by design turns out to be EXACTLY the footprint of two CH Joysticks side by side. By picking these dimensions, the velcro mounting squares are in the same place, and we can switch the main board’s configuration to and from combinations of boxes and sticks at will.

The bottom of the box has two 5" sections of 1" L-channel, attached on the inside edges of the sides, with the bottom edges facing INWARDS. This provides a smooth surface underneath the box to place Velcro squares to hold it down to our main board, without marring the appearance of the box.

Wiring: The box has a hole drilled in the side for the cable with the DB connector on it. It is long enough to plug into ANY of the four port connectors when placed on either side of the OI, and has enough conductors in it to COMPLETELY wire the connector. On the inside of the box, an overhand knot in the cable acts as a strain relief, then the cable runs through cable tiedowns to a set of labeled barrier strips screwed on one of the long inside surfaces. This gives us a FULL set of SCREW terminals, with ALL of the signals available (4 pots, 5 switches), along with two grounds, and +5V. If we ever wish to, this design also allows us to add in and power a “custom box” from the barrier strip.

The top of the box has a cutout in it of about 10" x 4.75". Onto this, we drop a 11" x 5.25" aluminum “main panel”. That size gives us 1/2" around on all edges to screw it on with 3 sheet metal screws on each long edge. By picking a panel size within 11" x 8.5", it allows us to use any DTP software to make up a custom label on standard paper. One copy is sacrificed as a Drill Guide, then a fresh one is sandwiched inside a standard Page Protector sheet, trimmed, and held on with the same screws that hold the panel down.

THIS is where the design stops before a specific contest.

NOW your control panel is simply a “DROP IN”! For a specific contest, Electrical builds the generic board and box RIGHT AWAY during week ONE, and a few blank, FLAT panels. When you’re ready a couple of weeks later, punch the panel for whatever controls you’ve decided upon. No complex sheet metal work required, and NO soldering. If you screw up, grab another blank panel. Square holes for rocker switches are easily made with a Dremel and a 409 or 420 cutter disk. Your “switch bag” contains an assortment of switches, 100K pots, and LEDs with premade pigtails with ring tongue lugs on them. Edit and print your new label, punch your holes, sandwich a label sheet to it and screw it onto the box, drop in the controls, screw them onto whatever signals you wish, and you’re done with customizing the hardware within a day or so!

BTW… Even if you decide to “wear” some of your controls (i.e. a backpack “marionette” controller), the Aux Box provides you a place for your monitor LEDs, the OTHER switches and pots, and a custom “breakaway” jack for the backpack so you won’t have to worry about strain relief damage of the OI from an overexcited operator that moves around too much. :slight_smile:

If you need to change something later at the contest, pull out your drill or Dremel, punch the new hole, drop in the new control or LED, screw it onto an unused analog or digital bit, use a magic marker on your top panel, and go tweak the program to use it.

The prewired barrier strip means NO soldering is required at the contest site for control system hardware changes!

We do also have a Mini-Box designed, that replaces the footprint of ONE joystick, with a Piggyback Feedthrough harness that doesn’t take up a port connector. (However, that wasn’t needed for THIS contest.) Each station COULD contain two joysticks and a FULL Aux Box, but we envision station configurations of 1-2 joysticks, and/or 1 full or mini Aux Box, with the most common being: 2 joysticks, 1 joy + 1 mini/full box, 2 joysticks + 1 mini BETWEEN them, or 1 full box.

For THIS contest, the Driver’s Station became simply a pair of CH Joysticks, with all auxilary controls mapped onto buttons and thumbwheels. The “Weapon’s Officer’s Station” has a single custom full sized Aux Box and all the strange control hardware.

I hope this explains things better. OOC, would there be any interest in a formal document on this modular OI board design, with images, for a white paper area somewhere?

**We have decided to keep all of our robots together though so we can make a new controller every year. Takes time but also allows for creativity. **

We felt that standardizing on a “generic modular control system design” of this style still keeps flexibility and creativity high, but eliminates a LOT of the unknowns in our build. NOW, we can get to work FASTER next time, and the electical group can have almost 90% of the board DONE before we have to know ANYTHING about our actual control needs.

For the same reason, we’re also starting design on a “standard RC control tray/board module” for next year. It’ll contain the RC, Spikes, and Victors, (and possibly the minibreaker panel as well), and simply bolt onto our frame. THIS year, IMHO wiring was a real nightmare. We were forced into SEVERAL reworks of frame components when we found what we hadn’t ENOUGH good space reserved for electrical stuff, and some people plumb forgot about connector clearances. <DOH!>

BTW, although we made an Electrical Simulator Board to test out things via umbilical, when we got to putting the RC onto its FINAL position on the machine, we found that the RC’s RADIO connector was damaged and wouldn’t work! With the shipping delays, we didn’t get a working RC back from Innovation First repair until a few HOURS before shipping on 2/19…

That is why NEXT time, we’re going to just allocate a suspension bolt-on point on the machine somewhere for a simple, prewired RC “module” board, to make sure it is functional and completed in its “robot form” MUCH sooner!

BTW… Our DRIVETRAIN this year is modular, too! Now THAT worked out well! :slight_smile:

  • Keith McClary, Advisor, Ann Arbor (MI) Huron High Team 830 “Rat Pack”