## Connecting to PC - Can it handle it ?

Expand Messages
• Hi, I want to use Intellibrain to sample sensor data and send it over to the PC. The PC will be used for kalman filtering and fuzzy logic control. The PC will
Message 1 of 4 , Apr 8, 2009
• 0 Attachment
Hi,

I want to use Intellibrain to sample sensor data and send it over to the PC. The PC will be used for kalman filtering and fuzzy logic control. The PC will then issue PWM commands to the robot to move the motors accordingly.

I have heard of latency issues and bandwidth problems faced by others. Will the bandwidth be sufficient enough for this process?

Here's the my math to calculate the data transfer required:

1) Encoder Ticks - (from Intellibrain to PC)
Robot Speed: 30cm/sec (roughly)
Wheel Circumfrence : 2* 3.14 * 2.5 = 15.714 cm
Revolutions / sec = 30 / 15.714 = 1.909
Encoder Counts per revolution per encoder: 450
Reading sent for every 2 ticks, so readings sent per revolution per encoder = 225
Readings per second per encoder = 1.909 * 225 = 429.54
Total readings for two encoders per second = 429.54 * 2 = 859.09 (roughly)

This is for one channel of the quadrature encoder. So, for both the channels, it will be 429.54*2 = 1718.18 ticks/sec

2) Sonars x6 (from Intellibrain to PC)
These will fire every 40ms one after the other

3) I2C Digital Compass (from Intellibrain to PC)
It will fire every 40ms

4) PWM Commands (from PC to intellibrain)
Assuming the PID loop runs one iteration for every reading input from the encoder. i.e. the PID generates a new PWM command for every 2 ticks from the encoder, then

Total PID commands for both the motors = 859.09 PWM commands = about 860 PWM commands.

5) TOTAL BAUD RATE REQUIRED:

Bytes per PWM command (-64 to 64 speeds) = 7 bytes
Total bytes for PWM /sec = 7 * 860 = 6020

Bytes per encoder = 3 bytes
Total bytes for Encoders /sec = 3 * 1718 = 5154 bytes

Bytes per sonar block transfer = 3 byte
Total bytes for Sonars /sec = 75

Bytes per compass block transfer = 3 byte
Total bytes for Sonars /sec = 75

Total Bytes / sec = 11324 Bytes/sec = 90592 bits/sec

Q1) So does it mean that the intellibrain would not have a problem with such data transfers?

Q2) Would it be able to process sending and receiving of data at this rate.

(fyi, the excel worksheet is attached in the files section titled "Baud Rate Calculations by Pranav Trehun" to make your own calculationas)
• I have done some experimenting with PC data communication to the IntelliBrain, including doing this over Bluetooth. While the serial port can handle the speed
Message 2 of 4 , Apr 9, 2009
• 0 Attachment

I have done some experimenting with PC data communication to the IntelliBrain, including doing this over Bluetooth.

While the serial port can handle the speed you describe, it has been my experience that the speed of Java execution on the CPU is just not fast enough to keep up.  (after all, it's a Java interpreter running on top of a battery operated embedded microcontroller).

Does the PC really need to be getting updates this frequently?  Does it needed to be notified of every single quadrature encoder event?  Could you get away with 100 updates per second to the PC?

When I was testing the ability of the Intellibran to process PC-initiated commands, my recollection is that 9600 baud was about the maximum I could achieve for sending commands from the PC to the IntelliBrain.  The limiting factor was not the PC, but the Intellibrain's ability to process commands, which I think was about 100 commands per second for 8 character commands.  The I think the "CPU speed" of the Java interpreter is about 10,000 instructions per second -- that is, a for loop with nothing inside will go about this fast.  But these numbers are all guesses from memory.  I would need to go find my notes.

Outputting information from the Intellibrain to the PC should be faster than parsing, but still I think the speed of the Java interpreter is going to be the limiting factor, not bandwidth.

Paul

----- Original Message -----
From: Pranav
Sent: Wednesday, April 08, 2009 1:41 PM
Subject: [intellibrain] Connecting to PC - Can it handle it ?

Hi,

I want to use Intellibrain to sample sensor data and send it over to the PC. The PC will be used for kalman filtering and fuzzy logic control. The PC will then issue PWM commands to the robot to move the motors accordingly.

I have heard of latency issues and bandwidth problems faced by others. Will the bandwidth be sufficient enough for this process?

Here's the my math to calculate the data transfer required:

1) Encoder Ticks - (from Intellibrain to PC)
Robot Speed: 30cm/sec (roughly)
Wheel Circumfrence : 2* 3.14 * 2.5 = 15.714 cm
Revolutions / sec = 30 / 15.714 = 1.909
Encoder Counts per revolution per encoder: 450
Reading sent for every 2 ticks, so readings sent per revolution per encoder = 225
Readings per second per encoder = 1.909 * 225 = 429.54
Total readings for two encoders per second = 429.54 * 2 = 859.09 (roughly)

This is for one channel of the quadrature encoder. So, for both the channels, it will be 429.54*2 = 1718.18 ticks/sec

2) Sonars x6 (from Intellibrain to PC)
These will fire every 40ms one after the other

3) I2C Digital Compass (from Intellibrain to PC)
It will fire every 40ms

4) PWM Commands (from PC to intellibrain)
Assuming the PID loop runs one iteration for every reading input from the encoder. i.e. the PID generates a new PWM command for every 2 ticks from the encoder, then

Total PID commands for both the motors = 859.09 PWM commands = about 860 PWM commands.

5) TOTAL BAUD RATE REQUIRED:

Bytes per PWM command (-64 to 64 speeds) = 7 bytes
Total bytes for PWM /sec = 7 * 860 = 6020

Bytes per encoder = 3 bytes
Total bytes for Encoders /sec = 3 * 1718 = 5154 bytes

Bytes per sonar block transfer = 3 byte
Total bytes for Sonars /sec = 75

Bytes per compass block transfer = 3 byte
Total bytes for Sonars /sec = 75

Total Bytes / sec = 11324 Bytes/sec = 90592 bits/sec

Q1) So does it mean that the intellibrain would not have a problem with such data transfers?

Q2) Would it be able to process sending and receiving of data at this rate.

(fyi, the excel worksheet is attached in the files section titled "Baud Rate Calculations by Pranav Trehun" to make your own calculationas)

• Thank you Paul for such a detailed answer. It was very helpful and informative. I wasn t aware that processing was the bottleneck here. So this is what i
Message 3 of 4 , Apr 10, 2009
• 0 Attachment
Thank you Paul for such a detailed answer. It was very helpful and informative. I wasn't aware that processing was the bottleneck here.

So this is what i think:
If I take 100 encoder readings per second, then for a 600 ticks encoder running the robot at 30cm/sec with a wheel raduis of 2.5cm. Then, i would have to report to the computer every 11.4545 ticks.

If i input this in my excel calculations sheet, i get a bandwidth of 16.015 Kbps and this is higher than 9600 baud. However, if i update every 50 ticks, then i would need a bandwidth of 4.572Kbps.

So, at an update rate of 50 ticks, "Total ticks for two encoders per second for one channel of Quadrature Encoder" = 45.8181. I can run one PID loop only if i use both left and right ticks. Thus PID loop commands issued per second will be half*** = 45.8181/2 = 22.909

The problem is that at 50 ticks, i would get 12 loops per revolution. or 22.909 loops per second or move (30cm/sec) / (22.909) = 1.3cm every PID loop.

I am not an expert in PID, but one loop every 1.3cm seems slow. even if i half the robot speed, ill get one loop every .654cm of travel. and this is assuming that there is no processing load due to encoders and other sensors.

so, is it safe to say it wont work in this case?

***PID loop commands issued per second will be half. This division by 2 was not accounted for in my previous excel sheet. Its been updated now. All calculation in this message are as per my new updated excel sheet.

--- In intellibrain@yahoogroups.com, "Paul King" <email@...> wrote:
>
>
> I have done some experimenting with PC data communication to the IntelliBrain, including doing this over Bluetooth.
>
> While the serial port can handle the speed you describe, it has been my experience that the speed of Java execution on the CPU is just not fast enough to keep up. (after all, it's a Java interpreter running on top of a battery operated embedded microcontroller).
>
> Does the PC really need to be getting updates this frequently? Does it needed to be notified of every single quadrature encoder event? Could you get away with 100 updates per second to the PC?
>
> When I was testing the ability of the Intellibran to process PC-initiated commands, my recollection is that 9600 baud was about the maximum I could achieve for sending commands from the PC to the IntelliBrain. The limiting factor was not the PC, but the Intellibrain's ability to process commands, which I think was about 100 commands per second for 8 character commands. The I think the "CPU speed" of the Java interpreter is about 10,000 instructions per second -- that is, a for loop with nothing inside will go about this fast. But these numbers are all guesses from memory. I would need to go find my notes.
>
> Outputting information from the Intellibrain to the PC should be faster than parsing, but still I think the speed of the Java interpreter is going to be the limiting factor, not bandwidth.
>
> Paul
>
>
>
> ----- Original Message -----
> From: Pranav
> To: intellibrain@yahoogroups.com
> Sent: Wednesday, April 08, 2009 1:41 PM
> Subject: [intellibrain] Connecting to PC - Can it handle it ?
>
>
>
>
>
> Hi,
>
> I want to use Intellibrain to sample sensor data and send it over to the PC. The PC will be used for kalman filtering and fuzzy logic control. The PC will then issue PWM commands to the robot to move the motors accordingly.
>
> I have heard of latency issues and bandwidth problems faced by others. Will the bandwidth be sufficient enough for this process?
>
> Here's the my math to calculate the data transfer required:
>
>
> 1) Encoder Ticks - (from Intellibrain to PC)
> Robot Speed: 30cm/sec (roughly)
> Wheel Circumfrence : 2* 3.14 * 2.5 = 15.714 cm
> Revolutions / sec = 30 / 15.714 = 1.909
> Encoder Counts per revolution per encoder: 450
> Reading sent for every 2 ticks, so readings sent per revolution per encoder = 225
> Readings per second per encoder = 1.909 * 225 = 429.54
> Total readings for two encoders per second = 429.54 * 2 = 859.09 (roughly)
>
> This is for one channel of the quadrature encoder. So, for both the channels, it will be 429.54*2 = 1718.18 ticks/sec
>
> 2) Sonars x6 (from Intellibrain to PC)
> These will fire every 40ms one after the other
> Sonar Readings per second = 1000ms /40ms = 25 distance readings
>
> 3) I2C Digital Compass (from Intellibrain to PC)
> It will fire every 40ms
>
> 4) PWM Commands (from PC to intellibrain)
> Assuming the PID loop runs one iteration for every reading input from the encoder. i.e. the PID generates a new PWM command for every 2 ticks from the encoder, then
>
> Total PID commands for both the motors = 859.09 PWM commands = about 860 PWM commands.
>
> 5) TOTAL BAUD RATE REQUIRED:
>
> Bytes per PWM command (-64 to 64 speeds) = 7 bytes
> Total bytes for PWM /sec = 7 * 860 = 6020
>
> Bytes per encoder = 3 bytes
> Total bytes for Encoders /sec = 3 * 1718 = 5154 bytes
>
> Bytes per sonar block transfer = 3 byte
> Total bytes for Sonars /sec = 75
>
> Bytes per compass block transfer = 3 byte
> Total bytes for Sonars /sec = 75
>
> Total Bytes / sec = 11324 Bytes/sec = 90592 bits/sec
>
> Q1) So does it mean that the intellibrain would not have a problem with such data transfers?
>
> Q2) Would it be able to process sending and receiving of data at this rate.
>
> (fyi, the excel worksheet is attached in the files section titled "Baud Rate Calculations by Pranav Trehun" to make your own calculationas)
>
• Pranav, 9600 baud was what I thought was the maximum practical rate that the JVM could process input from the PC. THis is because input has to be parsed
Message 4 of 4 , Apr 11, 2009
• 0 Attachment
Pranav,

"9600 baud" was what I thought was the maximum practical rate that the JVM could process input from the PC.  THis is because input has to be parsed character-by-character, so the CPU time required is proportional to baud-rate.

In the case of the PC processing input from the JVM (the reverse direction), the PC will not be CPU-bound, so the same considerations are not a factor.

In this case, the limiting factor is the number of Intellibrain JVM instructions required to read the wheel encoder and generate the output.  Generating 100 print statements to the serial port is easy (you can probably generate 1000 per second), even if each print statement contains 10+ characters.  The actual handling of print output generation happens in built-in functions, which are probably written in C anyway.

In your scenario, the limiting factor is going to be the inner loop that reads the wheel encoders, especially if they need to be read at every tick (hopefully it does not).

Here are some thoughts:

* Can you set your reporting loop (the one that communicates the number of ticks to the PC) to be at a certain frequency rather than a certain number of ticks?  That is, report to the PC 100 times per second (or 50 times, if it can't keep up), however many ticks happened since the last update.  This will give you high precision at low wheel speeds, and lower precision as wheel speed increases.

* On the PC side, you could time the milliseconds (or microseconds) elapsed since the last report received from the robot.  This will allow you to compute instantaneous wheel speed accurately regardless of the update frequency, and even if the update frequency slows down due to additional processing on the JVM, e.g. by a different thread.  In Kalman filter style, you oculd even "guess" instantaneous wheel position in the absence of reports, and correct the guess model when a new report comes in.  This might allow you to lower reporting frequency even to 10/second if you wanted to.

* You could use a query-response scheme, where the PC queries the robot for a wheel encoder read-out.  This would ensure that the serial port buffer never fills up with unprocessed wheel reports.  (although this shouldn't happen anyway, since the PC has more than enough CPU cycles)

Paul

----- Original Message -----
From: Pranav
Sent: Friday, April 10, 2009 7:22 AM
Subject: [intellibrain] Re: Connecting to PC - Can it handle it ?

Thank you Paul for such a detailed answer. It was very helpful and informative. I wasn't aware that processing was the bottleneck here.

So this is what i think:
If I take 100 encoder readings per second, then for a 600 ticks encoder running the robot at 30cm/sec with a wheel raduis of 2.5cm. Then, i would have to report to the computer every 11.4545 ticks.

If i input this in my excel calculations sheet, i get a bandwidth of 16.015 Kbps and this is higher than 9600 baud. However, if i update every 50 ticks, then i would need a bandwidth of 4.572Kbps.

So, at an update rate of 50 ticks, "Total ticks for two encoders per second for one channel of Quadrature Encoder" = 45.8181. I can run one PID loop only if i use both left and right ticks. Thus PID loop commands issued per second will be half*** = 45.8181/2 = 22.909

The problem is that at 50 ticks, i would get 12 loops per revolution. or 22.909 loops per second or move (30cm/sec) / (22.909) = 1.3cm every PID loop.

I am not an expert in PID, but one loop every 1.3cm seems slow. even if i half the robot speed, ill get one loop every .654cm of travel. and this is assuming that there is no processing load due to encoders and other sensors.

so, is it safe to say it wont work in this case?

***PID loop commands issued per second will be half. This division by 2 was not accounted for in my previous excel sheet. Its been updated now. All calculation in this message are as per my new updated excel sheet.

--- In intellibrain@ yahoogroups. com, "Paul King" <email@...> wrote:
>
>
> I have done some experimenting with PC data communication to the IntelliBrain, including doing this over Bluetooth.
>
> While the serial port can handle the speed you describe, it has been my experience that the speed of Java execution on the CPU is just not fast enough to keep up. (after all, it's a Java interpreter running on top of a battery operated embedded microcontroller) .
>
> Does the PC really need to be getting updates this frequently? Does it needed to be notified of every single quadrature encoder event? Could you get away with 100 updates per second to the PC?
>
> When I was testing the ability of the Intellibran to process PC-initiated commands, my recollection is that 9600 baud was about the maximum I could achieve for sending commands from the PC to the IntelliBrain. The limiting factor was not the PC, but the Intellibrain' s ability to process commands, which I think was about 100 commands per second for 8 character commands. The I think the "CPU speed" of the Java interpreter is about 10,000 instructions per second -- that is, a for loop with nothing inside will go about this fast. But these numbers are all guesses from memory. I would need to go find my notes.
>
> Outputting information from the Intellibrain to the PC should be faster than parsing, but still I think the speed of the Java interpreter is going to be the limiting factor, not bandwidth.
>
> Paul
>
>
>
> ----- Original Message -----
> From: Pranav
> To: intellibrain@ yahoogroups. com
> Sent: Wednesday, April 08, 2009 1:41 PM
> Subject: [intellibrain] Connecting to PC - Can it handle it ?
>
>
>
>
>
> Hi,
>
> I want to use Intellibrain to sample sensor data and send it over to the PC. The PC will be used for kalman filtering and fuzzy logic control. The PC will then issue PWM commands to the robot to move the motors accordingly.
>
> I have heard of latency issues and bandwidth problems faced by others. Will the bandwidth be sufficient enough for this process?
>
> Here's the my math to calculate the data transfer required:
>
>
> 1) Encoder Ticks - (from Intellibrain to PC)
> Robot Speed: 30cm/sec (roughly)
> Wheel Circumfrence : 2* 3.14 * 2.5 = 15.714 cm
> Revolutions / sec = 30 / 15.714 = 1.909
> Encoder Counts per revolution per encoder: 450
> Reading sent for every 2 ticks, so readings sent per revolution per encoder = 225
> Readings per second per encoder = 1.909 * 225 = 429.54
> Total readings for two encoders per second = 429.54 * 2 = 859.09 (roughly)
>
> This is for one channel of the quadrature encoder. So, for both the channels, it will be 429.54*2 = 1718.18 ticks/sec
>
> 2) Sonars x6 (from Intellibrain to PC)
> These will fire every 40ms one after the other
> Sonar Readings per second = 1000ms /40ms = 25 distance readings
>
> 3) I2C Digital Compass (from Intellibrain to PC)
> It will fire every 40ms
>
> 4) PWM Commands (from PC to intellibrain)
> Assuming the PID loop runs one iteration for every reading input from the encoder. i.e. the PID generates a new PWM command for every 2 ticks from the encoder, then
>
> Total PID commands for both the motors = 859.09 PWM commands = about 860 PWM commands.
>
> 5) TOTAL BAUD RATE REQUIRED:
>
> Bytes per PWM command (-64 to 64 speeds) = 7 bytes
> Total bytes for PWM /sec = 7 * 860 = 6020
>
> Bytes per encoder = 3 bytes
> Total bytes for Encoders /sec = 3 * 1718 = 5154 bytes
>
> Bytes per sonar block transfer = 3 byte
> Total bytes for Sonars /sec = 75
>
> Bytes per compass block transfer = 3 byte
> Total bytes for Sonars /sec = 75
>
> Total Bytes / sec = 11324 Bytes/sec = 90592 bits/sec
>
> Q1) So does it mean that the intellibrain would not have a problem with such data transfers?
>
> Q2) Would it be able to process sending and receiving of data at this rate.
>
> (fyi, the excel worksheet is attached in the files section titled "Baud Rate Calculations by Pranav Trehun" to make your own calculationas)
>

Your message has been successfully submitted and would be delivered to recipients shortly.