Recent Posts

Pages: 1 2 3 4 5 6 ... 10
Mechanics and Construction / Re: Making an impossible to juggle juggling club
« Last post by MrPrezident on December 11, 2014, 01:37:09 PM »
So I finally got the magnets.  These things are strong!  I had one of them on my desk and accidentally got one of the other magnets too close.  The one on my desk flew off and smashed into the one I was holding and chip a piece off of it.  Anyway, I made a prototype with some magnets, and PVC pipe, and some duct tape.  When I try to throw the thing, the center magnet ends up hovering near one of the end magnets and stays there.  I was kind of expecting that.  The whole throwing and catching process jostles the magnet a little bit, but it really wants to stay in that spot.  It seems to be especially stable while it's spinning.  I was wondering if electromagnets could force it to move around more??  Maybe that would require a lot of power though.
Software / Re: ATMega RAM management
« Last post by Webbot on December 11, 2014, 01:19:05 PM »
Big subject !

If you define a variable outside of any function it is called a 'global' variable - ie it exists, in the same memory slot, forever. The compiler will allocate a permanent location of it (and all others) starting from memory address 0 and growing upwards towards the end of memory. But there is one subtlety -   global variables come in two flavours: initialised and un-initiailised.

An initialised variable looks like this - ie you give it an initial value:
Code: [Select]
int x = 6;

whereas an unitialised variable looks like this:
Code: [Select]
int x;
In order to give 'initialised' variables their starting value then the compiler groups all of these variables together ie they stored one after the other starting from address 0 of the RAM. It then stores their initial values into a 'same size' block of flash/code memory. The compiler adds code that is executed when you boot up that copies these initial values from flash/code into RAM. Hence giving global variables an initial value will mean that not only do you need to  have RAM to store the changing value but it will also make your flash/code size bigger as it needs to store the initial values.

Unitialised variables on the other hand only require RAM and don't make your flash/code size any bigger. The compiler will group all global uninitialised variables together - starting after all of the initialised ones.

The compiler always adds magic variables to the flash/code saying how big the total size of all the initilised varbles is and also all the unitialised variables.

Hence when you turn on your board it will:
  • Copy x bytes from flash to RAM - starting at RAM address 0 - to give initialised variables their start value
  • Set the next y bytes - ie starting at RAM address x for the next y bytes - to zero. ie uninitialised variables are set to zero
  • The total size of your global variables is therefore x+y and marks the start of the 'heap'
  • If you dynamically allocate stuff using 'new' then it will start at the current value of 'heap' and 'heap' will be increased by the size of the thing you have created. NB to discuss the real workings of the heap would require a book sized reply!

Ok that's it for Global variables.

The next is 'Local' variables. ie variables defined  within a block (normally identified by matching open/close curly braces). This could be a function but could also be a for loop, while loop, etc or just braes with the code. The variable is only visible/referable within the block (else you get a compiler error). The variable therefore only really exists for the duration of the execution of the block.
Consider the following code:
Code: [Select]
void myFunction(void)
{ // Start block  level 1
    int x;
   {  // Start block level 2
       int y;
      // do something with 'y'
   } // End block level 2

  {  // Start block level 2
       int z;
      // do something with 'z'
   } // End block level 2

} // End block level 1

Whilst the variable 'x' is accessible everywhere in the function (block level 1) the variables y and z can never exist at the same time so they could use the same location in memory - ie by the time you get to using 'z' then 'y' is no longer required.

In C you could think of this as a struct/union (google is your friend) ie:
Code: [Select]
struct myFunctionData {
   int x; // always existss
   union {
      int y;
      int z;
Assuming an 'int' is 2 bytes then the size of the 'union' is the size of its largesst member. Given that y and z are both 2 bytes then the answer is 2.  The total size of the struct is the sum of the things it contains ie 'int x'=2 bytes and the 'union' is 2 bytes - so only 4 bytes are needed (rather than 6 - because y and z can overwrite each other).

So the compiler works all of this out based on blocks of code.  ie 'x' is at block+0 length = 2, 'y' is t block+2 length =2, 'z' is t block +2 length =2.

But where does it get stored?

All this transient stuf gets stored on the stack.  The stack begins at the end of RAM and grows downwards. The current stack position is called the stack pointer (or SP for short) and is a special AVR register(s). The C compiler adds magic code to the start up to set the stack pointer to the end of RAM ie if your chip has 8kb then it sets it to 8kb ie  RAM Location 0 + 8192 = 8192.

When compiling the above function we have already discussed that only 4 bytes are required for the local variables. So the compiler adds code to reduce the SP by 4 ie SP=SP-4. The local/temporary variable 'x' is therefore at SP+0 and both 'y' and 'z' are at SP+2. The compiler also adds magic code to the end of the function to throw these variables away. By doing SP=SP+4. ie when exiting the function the SP is the same as it was before it was called. This is important as it may be called from another function which is accessing its own variables via the SP.

Of course if you nest function calls to umpteen levels then the SP will get lower and lower in RAM towards the end of the global variables tht have grown up from the start of RAM.  If the two overlap then you will start to corrupt the global variables. On PC compilers, where you always have a screen/output device, you can make a function check if this has occurred and you get the dreaded 'Stack Overflow' error at runtime. On a microcontroller the compiler cannot assume you have any display device connected so it can't send this error message anywhere sensible and hence doesn't bother  it will just let you corrupt stuff. This also keeps the code smaller as the compiler doesn't even bother adding the code to check if a collision has happened.

Function parameters add a further twist. In effect they are similar to block level 0 temporary variables in that they are accessible throughout the function. The difference is that the calling code will push their values onto (and hence reduce) the SP. So they become initialised local variables to the function on entry. This begs the question as to who/what removes them from the SP and this can be compiler specific. In theory - if the parameters are of a fixed total size, lets say 12 bytes, then the compiler can add magic code to the called function so that it always sets SP=SP+12 before it exits to remove the parameters. This is more efficient as it only adds the overhead of this code once - whereas if the caller had to do it, and it was called from 100 different places, then code would be added 100 times.

Hopefully that makes some sort of sense. Feel free to ask some questions but if its all nonsense then you may need to research compiler design.

Software / 50 dollar robot code
« Last post by Zevoo on December 11, 2014, 12:56:09 PM »
Could someone give the code used in Atmel Studio 6 for the errors in the picture. The tutorial is quite old and written using the older versions of Atmel Studio and the new Studio doesn't understand some of the code used by the old Atmel studio. It is frustrating for me and for future people who decide to do this tutorial because they will rip their hair out not knowing what is going on.

I've been waiting long to program my robot but I cant get it working because of that problem.
Mechanics and Construction / Re: Need Help with a Rear Wheel Drive Car Style Robot
« Last post by Schlayer on December 11, 2014, 09:49:40 AM »
Other than worrying about vibrations within the chassis of my car, I realize winter is coming (get the reference?) in my area. I know that waterproofing isn't usually a concern for freshwater such as rainwater or melting snow (though pollutants might contribute to raised conductivity as I live near Philadelphia), but I fear for my receiver and ESC. Would simply building enclosures from Plexiglass suffice to protect my components from a little rainwater? Also, if I go through with my plan to add an Arduino to this bot, would it be worthwhile to buy a pre-manufactured enclosure?
Misc / Re: Anyone used the Lego Mindstorms EV3 System?
« Last post by Schlayer on December 11, 2014, 09:12:10 AM »
Personally, I have not used the EV3 revision of Mindstorms, but I can tell you from my experience with the Mindstorms NXT 2.0 (the previous version) that Mindstorms will likely be underwhelming. The EV3 brings little to the table that NXT 2.0 didn't offer aside from more sensors and a new motor which doesn't function exactly like the regular servos from the NXT 1 and 2, but probably has far less torque and more speed. More importantly, the hardware, though simple and easy to connect to ordinary LEGO structures, is not nearly as precise as one might expect. If you plan to build path following autonomy into your robots, expect multiple centimeters of inaccuracy in movements and distance readings from the ultrasonic sensor. However, for simple projects, this might not really matter.

Admittedly, my talking points above might turn out to be trivial matters for you as I am unsure exactly how advanced you plan to get with these bots. What I think would be most important for you to know is that you can't just 'program' a Mindstorms kit. You have to use an included software with a tile based system, which as I have known myself, coming from a scripted platform like Arduino to tile-based stuff is extremely limiting. Though it is possible to build considerable complexity into your programs, they will be processed slowly, and you will need to often program in delays or use other tricks to allow information to be processed accurately. When using the tile based system, trying to make a long program with large amounts of complexity will end up looking like a massive mess of connecting lines and wires on your screen, and anybody unfamiliar with the system will have no idea how the program works.
My advice is: if you have been okay using Arduino before, you may like to stick with it. You can use regular LEGOs as a platform to attach traditional hobbyist robotic parts like servos and motors if the ease of construction is all you require, as LEGO itself is a flexible building platform. I was able to construct a remote controlled car with a regular 550 can motor and a hobby servo for steering using LEGOs for the entire chassis and wheels. Just get creative, build a platform for an Arduino, and you have a fully programmable robot on the cheap!
P.S.: The total cost of parts for my car was around $50, though I had some electronics already lying around. Much cheaper than a whole Mindstorms kit to use $10-$20 servos and $5-$10 motors along with a $35 Arduino controller.
Software / Make your multi rotor easy to program and build real world applications
« Last post by RBRobotics on December 10, 2014, 04:31:28 PM »
Hello, my name is Rakshak and I wanted to share my project, the RAVN, which enables your multi rotor to be easy to program and build autonomous applications for.

The reason we're developing the RAVN is because I found programming multi rotors to be a far cry from the ease of programming computers. When you program a computer you have communities sharing plenty of existing code, support, and know-how.

If you program a multi rotor using a popular flight controller such as a Pixhawk you'll find yourself swamped trying to program at a low level, using new tools with minimal support, and scattered resources.

Our platform on the other hand is designed to leverage existing code by installing a mini computer directly on your multi rotor. This makes it easy for integrating existing computer vision scripts for environmental monitoring, easily adding any additional sensors, and continually upgrading the development experience.

If you are interested in building the future of multi rotors and unleashing their potential in personal missions, robotics competitions, etc. please reply below. Iím more than happy to answer any questions.

Thank You!
Misc / Anyone used the Lego Mindstorms EV3 System?
« Last post by swordmaster2k on December 10, 2014, 11:05:29 AM »
Has anyone here used the Lego Mindstorms EV3 System? I'm pondering buying a set. I'm looking for basic odometry (x, y displacement and rotation) capability for path planning and a WiFi/Bluetooth connectivity to expand the number of robots in my project I currently have 2 builds running around with Arduinos. Mindstorms seem to be pretty robust and extensively expandable. I've read the reviews/product spec extra input would be helpful.

I'll need to do some low level programming via a Linux Host I've found a few approaches LeJos, ev3dev, MonoBrick. Any advice from anyone?

Electronics / splitting power connection after ubec
« Last post by legit on December 10, 2014, 09:42:23 AM »
I bought a hexy the hexapod kit and I am planning on powering it with a 11.1v lipo but with a 5v ubec after the battery. The problem is that the control board (servotor) has 2 power inputs for logic and servo control.  I was planning on just soldering two dc jacks onto the ubec. Does anyone know if there is a "proper" way to split out connections from a single batter source? Or is soldering two DC jacks to the battery connector acceptable?
Electronics / Pressure Sensor
« Last post by sam-r-90 on December 10, 2014, 07:38:33 AM »
I want to use a pressure sensor to measure the depth of water, it will be attached to a ROV. Am i right in thinking i need an absolute pressure sensor? Also when i look at them they all come in different pressures so if i wanted one which would measure between 0-10m would i then look for a sensor that covers 14.6 psi to 29.3 psi?
Hello everyone,

For my project, I'm making a thermoelectric bracelet for body temperature regulation (essentially a personal air conditioner) and I've been having an issue with printed circuit board. Usually, its pretty easy for me to locate the shorts, but this one is perplexing.  As you can see in the schematic, this board is controlled by a Sparkfun Pro Micro. I'll consider that along with the RGBs section 1 of the circuit and that is working just fine. 

The problem is section 2 (or so I think) and that's the circuitry responsible for stepping up the voltage and applying the correct polarity (using H-bridges).

When I dont have the boost chip soldered in, power is applied to the microcontroller and section 1 works just fine.  However I do notice there is a short between power and ground on the boost converter chip's pads. So its like 1 part of the board is shorted and the other is working just fine.

When the chip is soldered in, both sections ceases to function and my multimeter shows there is continuity between + and - throughout the board.

If someone could shed some light on this problem, I would be very greatful. This one has truly stumped me so if one of you can locate this, then you have earned my highest respect and gratitutde
Pages: 1 2 3 4 5 6 ... 10

Get Your Ad Here