To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / *4063 (-5)
Subject: 
Re: Kernel freeze when attempting to use rotation sensor
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Thu, 24 Jun 2010 15:04:33 GMT
Viewed: 
31841 times
  
I don't normally bump things, but this has been unanswered for over two weeks,
so I think it deserves it. I really can't believe that rotation sensors would be
this broken, and yet, I can't see anything wrong with my code. It really is
odd...


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 15 Jun 2010 10:21:39 GMT
Viewed: 
32529 times
  
Hello Yann,

2010/6/15 Yann Vernier <yann@algonet.se>:

I've recently mucked about with the Power Functions protocol, and got a proof of
concept running on the RCX using brickOS. The main problem is that it's quite
timing sensitive, so this code only worked reliably with interrupts disabled
(looking at the oscilloscope).

The sample code is at http://www.algonet.se/~yann/powerfunctions.c

The timing requirements are probably more lax in reality (PF protocol spec cites
ranges like 316-526us for a 0 bit), but my code was thrown off by whole periods
(of the 38kHz modulation signal) as other interrupts occurred.

I really would prefer to see the interrupt code running to disabling
all interrupts for several milliseconds, loosing several ticks and
disabling all sensors during this time.

Did you apply one of my performance patches to brickOS?  IIRC, the
current release of brickOS still has a busy waiting loop in the sensor
interrupt, which explains why you get corrupt timings.  The patches
are at
http://hoenicke.ath.cx/rcx/brickOS.html

You can also use my simulator brickemu to get some statistics about
maximal run-time of interrupts.  It shouldn't be too difficult to add
debugging output to the 8-bit timer to get cycle exact information of
when the registers are set.  You can also debug your code with
brickemu by adding printf in your code.

It looks hard to get the interrupts fast enough, though. According to
my statistics, the timer interrupt in bibo can take up to 1031 cycles,
i.e 65 us, which is still more than the period of your timer. On
average it runs in only half the time, so you should not loose so many
cycles that your signal is distorted beyond recognition.

Regards,
  Jochen


Subject: 
Re: BrickOS Patches and Development
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 15 Jun 2010 07:35:44 GMT
Viewed: 
32230 times
  
In lugnet.robotics.rcx.legos, Carl Troein wrote:
Another thing: We should have a good asm implementation of the Power
Functions protocol. I've ordered the Emerald Night collection so soon
I'll have some power functions parts and a reason to control them
with BrickOS. Hopefully that will lead to something.

I've recently mucked about with the Power Functions protocol, and got a proof of
concept running on the RCX using brickOS. The main problem is that it's quite
timing sensitive, so this code only worked reliably with interrupts disabled
(looking at the oscilloscope).

The sample code is at http://www.algonet.se/~yann/powerfunctions.c

The timing requirements are probably more lax in reality (PF protocol spec cites
ranges like 316-526us for a 0 bit), but my code was thrown off by whole periods
(of the 38kHz modulation signal) as other interrupts occurred.


Subject: 
Kernel freeze when attempting to use rotation sensor
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sat, 12 Jun 2010 10:18:28 GMT
Viewed: 
31236 times
  
Hi,

I've tried using the latest BrickOS and the latest BIBO with patches (from here:
http://sourceforge.net/tracker/?func=detail&aid=2858992&group_id=58151&atid=486699
), both with the same result. I don't know if nobody's really used a rotation
sensor in 4 years (unlikely), or if my code just fails (likely), but every time
I run it, the kernel crashes when using the rotation sensor the SECOND TIME
AROUND (NOT THE FIRST TIME). The code in its entirety is posted below (it's for
a slightly modified version of the Plotter from the Ultimate Builders' Set):

#include <dmotor.h>
#include <dsensor.h>
#include <unistd.h>
#include <conio.h>
#include <lnp.h>

int charpos;
int line;

#define PAPER_WIDTH 10
#define PAPER_HEIGHT 13

void fosrotate(int drotations){ // Counts rotations using the Fibre Optic
System, which actually works rather well as a rotation sensor.
  unsigned int rotations = 0;
  while(rotations<drotations){
    while(SENSOR_2!=0xFFC0){
    }
    rotations += 1;
    while(SENSOR_2>0x9000){
    }
    rotations += 1;
  }
}

void up(int x){ // Paper down x/16 teeth (no typo - pen goes up paper)
  ds_rotation_on(&SENSOR_1);
  ds_rotation_set(&SENSOR_1,0);
  msleep(100);
  motor_b_speed(MAX_SPEED);
  motor_b_dir(rev);
  while(ROTATION_1>-x){
    msleep(100);
    lcd_number(ROTATION_1,sign,e0);
  }
  motor_b_dir(brake);
  ds_rotation_off(&SENSOR_1);
}

void down(int x){ // Paper up x/16 teeth (no typo - pen goes down paper)
  ds_rotation_on(&SENSOR_1);
  ds_rotation_set(&SENSOR_1,0);
  msleep(100);
  motor_b_speed(MAX_SPEED);
  motor_b_dir(fwd);
  while(ROTATION_1<x){
    msleep(100);
    lcd_number(ROTATION_1,sign,e0);
  }
  motor_b_dir(brake);
  ds_rotation_off(&SENSOR_1);
}

void left(int x){ // Pen left x/16
  motor_c_dir(rev);
  fosrotate(x);
  motor_c_dir(brake);
}

void right(int x){ // Pen right x/16 teeth
  motor_c_dir(fwd);
  fosrotate(x);
  motor_c_dir(brake);
}

void pup(){
  motor_a_dir(fwd);
  sleep(7);
  motor_a_dir(brake);
}

void pdown(){
  motor_a_dir(rev);
  sleep(12);
  motor_a_dir(brake);
}

void cr(){
  // Carriage to far left
  motor_c_speed(MAX_SPEED);
  motor_c_dir(rev);
  msleep(500);
  while(!TOUCH_3){
    msleep(100);
  }
  // Carriage to print position (2 teeth right)
//  motor_c_dir(fwd);
//  fosrotate(32);
//  motor_c_dir(brake);
  right(32);
  charpos = 0;
}

void lf(){
  // Feed paper for a whole rotation of the output axle (24 * 16)
//  ds_rotation_set(&SENSOR_1,0);
//  ds_rotation_on(&SENSOR_1);
//  motor_b_speed(MAX_SPEED);
//  motor_b_dir(fwd);
//  while(ROTATION_1<384){
//    msleep(100);
//  }
//  motor_b_dir(brake);
  down(100);
  line += 1;
  if(line > PAPER_HEIGHT){
    cputc_native_user(CHAR_P, CHAR_C, CHAR_L, CHAR_A);
    cputc_native_5(CHAR_4);
    while(getchar() != KEY_VIEW){
    }
    line = 0;
    lf();
  }
}

void draw_a_letter(char letter){
  if(letter == 10){ // LF
    lf();
    return;
  }
  if(letter == 13){ // CR
    cr();
    return;
  }
  if(letter == 'A'){
    pdown();
    down(80);
    up(80);
    right(40);
    down(40);
    left(50);
    right(50);
    down(40);
    pup();
    up(80);
    right(10);
    return;
  }
}

void addr_handler_1(const unsigned char *data, unsigned char length, unsigned
char src)
{
  int i;
  for(i=0;i<length;++i){ // Print
    draw_a_letter(data[i]);
  }
}

int main(){
  line = 0;
  ds_active(&SENSOR_1);
  ds_active(&SENSOR_2);
  ds_passive(&SENSOR_3);
  // Do initial Penup, CRLF
  pup();
  cr();
  lf();
  // Wait for message from PC
  lnp_addressing_set_handler (0, addr_handler_1);
  while(!shutdown_requested())
    msleep(1000);
  return 0;
}



I send the letter "A" from the computer and it receives fine. However, when
running the first down(80); instruction, the screen usually shows around 105
(note the lcd_number debug statements) and it completely freezes, with the motor
still running - only taking the battery out and redownloading the kernel will
get it back to normal. Note that this is the second time down(int x) has been
called - the initial CRLF (the LF in particular) calls down(100).

It seems to me that the code to set the rotation sensor's value to 0 doesn't
actually work, and instead freezes the kernel. Anyone else got any clues?



Thanks in advance for any help,

Muzer (Murray Colpman).


Subject: 
Developing a "button pressing" RCX system
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Fri, 29 Jan 2010 19:02:12 GMT
Viewed: 
21311 times
  
Hello,

I have inherited a hand-me-down RIS kit with a functional RCX unit that
I would like to learn to use and put to a purpose.

I would like to build a system whereas the RCX is setup to press buttons
on controllers (think remote control units) to operate other devices.

I am completely new to mindstorms programming (this RIS kit was my first
exposure).

Other than the mechanical considerations, I and not sure how to proceed
with development on the software side.

I basically would like to the RCX to be in standby until it receives a
signal via the IR tower to "push button 1" which would cause the RCX to
go through the motions then wait for another command. Think a piano
keyboard with a RCX "crane" to find and press the different keys as
directed.

For my development environment, I am using Debian Etch which provides
pre-built packages for BrickOS and LNP. I was able to load th BrickOS
firmware and try out a few of the sample programs (hello world, bumper
robot) etc. These were helpful to determine if the RCX and other parts
were still functional but they are very trivial examples compared to
what I would like to accomplish.

Are there any existing BrickOS examples out there (links) to something
similar to what I would like to do that I can work from?

Also, would it be better to create simple RCX programs to do a
load-and-run operation for each individual button press operation or to
create a single master program that always lives on the RCX and waits
for keyword instructions via the IR tower.

Any suggestions, help, and pointers would be greatly appreciated.  I
have found more dead web links than anything else trying to figure this
out on my own.  It seems that 10 years is "before recorded history" on
the Internet, given the copyright date on the Mindstorms RIS box is 1998...



Next Page:  5 more | 10 more | 20 more

Redisplay Messages:  Brief | Compact

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR